Re: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03
"Dan Harkins" <dharkins@lounge.org> Fri, 22 April 2011 00:12 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36EB7E074C; Thu, 21 Apr 2011 17:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbHNN35sGQH8; Thu, 21 Apr 2011 17:12:02 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 05044E06DD; Thu, 21 Apr 2011 17:12:01 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 006DC1022404E; Thu, 21 Apr 2011 17:12:00 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 21 Apr 2011 17:12:01 -0700 (PDT)
Message-ID: <0090e9b435a992eaf44a521642c5f513.squirrel@www.trepanning.net>
In-Reply-To: <1E5F005F-8CC3-41B9-B860-A36ABA95E708@bbn.com>
References: <1E5F005F-8CC3-41B9-B860-A36ABA95E708@bbn.com>
Date: Thu, 21 Apr 2011 17:12:01 -0700
From: Dan Harkins <dharkins@lounge.org>
To: "Richard L. Barnes" <rbarnes@bbn.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: draft-harkins-ipsecme-spsk-auth@tools.ietf.org, The IESG <iesg-secretary@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 00:12:03 -0000
Hi Richard, Thank you for reviewing my draft. Responses inline.... On Wed, April 20, 2011 11:55 am, Richard L. Barnes wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. > > This document defines a new mechanism for using pre-shared keys for IPsec > authentication in IKE, in a way that addresses some vulnerabilities of the > current mechanism. > > I am not a cryptographer, but the cryptographic protocol described in this > document seems basically sound, and its security properties are explained > well in the Security Considerations. > > A question and couple of minor comments follow. > --Richard > > > Question: I haven't thought deeply about it, but it's not clear to me what > the advantage is over this cryptographic protocol vs. the SRP protocol > that has been used for TLS [RFC5054], besides the fact that SRP requires a > user "identity" in addition to a password. SRP is a client-server protocol in which one side has salt and a verifier and the other has a password. Since IKE is not a client-server protocol, and either side can initiate to the other, each side needs access to the password. To implement SRP though, they would have to agree on some salt and produce a verifier to store along with the password. That sort of defeats the whole point of using a verifier protocol like SRP. And it seems like we'd be shoehorning in a protocol that isn't really a good fit. > Minor: There appears to be a typo at the top of Page 7. It seems that the > equation should be as follows: > scalar-op(x,Y) = element-op(Y, scalar-op(x-1), Y)), for x > 1 > Also, for completeness, you might note that scalar-op(0,Y) is the identity > element of the group. Yes, thanks for catching that. > Minor: It might be helpful to mention somewhere that scalars are always > non-negative integers. You're right; that would be helpful. I'll do that. Thanks again for the review, Dan.
- [secdir] secdir review of draft-harkins-ipsecme-s… Richard L. Barnes
- Re: [secdir] secdir review of draft-harkins-ipsec… Dan Harkins
- Re: [secdir] secdir review of draft-harkins-ipsec… Richard L. Barnes