Re: [saag] Additions to RFC 3631?

Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 21 May 2012 18:31 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2121F8687 for <saag@ietfa.amsl.com>; Mon, 21 May 2012 11:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.11
X-Spam-Level:
X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BUn+Bcuo5BP for <saag@ietfa.amsl.com>; Mon, 21 May 2012 11:31:14 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3F50921F8681 for <saag@ietf.org>; Mon, 21 May 2012 11:31:14 -0700 (PDT)
Received: from [192.168.33.124] (c-67-165-85-247.hsd1.pa.comcast.net [67.165.85.247]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q4LIVCTA027465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 14:31:12 -0400 (EDT)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Mouse <mouse@Rodents-Montreal.ORG>
In-Reply-To: <14199_1337398324_q4J3W3Uu015671_201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG>
References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <14199_1337398324_q4J3W3Uu015671_201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 21 May 2012 14:31:02 -0400
Message-ID: <1337625062.2813.60.camel@destiny.pc.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: saag@ietf.org, jhutz@cmu.edu
Subject: Re: [saag] Additions to RFC 3631?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 May 2012 18:31:14 -0000

On Fri, 2012-05-18 at 23:31 -0400, Mouse wrote:
> >    nor is it ever transmitted over the network.
> 
> Again, this depends on the OTP scheme; indeed, most OTP schemes I am
> aware of do indeed transmit the passwords used for authentication.

In fact, IMHO this has always been one of the main advantages of OTP
schemes -- passwords can be disclosed during authentication, because
they cannot be reused.


> > 3.3.  IPsec
> 
> >    The key management for IPsec can use either certificates or shared
> >    secrets.  For all the obvious reasons, certificates are preferred;
> >    however, they may present more of a headache for the system manager.
> 
> The statement that certificates "are preferred" is either false or
> incomplete, because certs are preferred only for certain classes of
> uses.  For others, a shared secret is better - different uses,
> different tradeoffs.

Agreed.  And in fact, the statement that certificates or preshared
secrets are the only available options is also false.  Last I checked,
it was also possible to use Kerberos (KINK, RFC4430) or any EAP method
(IKEv2, RFC5996).


-- Jeff