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

"Richard L. Barnes" <> Fri, 22 April 2011 08:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE233E0796; Fri, 22 Apr 2011 01:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ymm2yuVKMEpd; Fri, 22 Apr 2011 01:58:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1F667E078E; Fri, 22 Apr 2011 01:58:17 -0700 (PDT)
Received: from [] (port=49483 helo=[]) by with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1QDCBs-000Olt-HH; Fri, 22 Apr 2011 04:58:16 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <>
X-Priority: 3 (Normal)
In-Reply-To: <>
Date: Fri, 22 Apr 2011 04:58:12 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: Dan Harkins <>
X-Mailer: Apple Mail (2.1082)
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 08:58:18 -0000

Hi Dan,

>> 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.

Thanks, that answer makes sense.  Consider my comments resolved!