Re: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03

"Dan Harkins" <> Fri, 22 April 2011 00:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36EB7E074C; Thu, 21 Apr 2011 17:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.265
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pbHNN35sGQH8; Thu, 21 Apr 2011 17:12:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 05044E06DD; Thu, 21 Apr 2011 17:12:01 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 006DC1022404E; Thu, 21 Apr 2011 17:12:00 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Thu, 21 Apr 2011 17:12:01 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Thu, 21 Apr 2011 17:12:01 -0700
From: Dan Harkins <>
To: "Richard L. Barnes" <>
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:, The IESG <>,
Subject: Re: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,