Re: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03
"Richard L. Barnes" <rbarnes@bbn.com> Fri, 22 April 2011 08:58 UTC
Return-Path: <rbarnes@bbn.com>
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 EE233E0796; Fri, 22 Apr 2011 01:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level:
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 mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymm2yuVKMEpd; Fri, 22 Apr 2011 01:58:17 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 1F667E078E; Fri, 22 Apr 2011 01:58:17 -0700 (PDT)
Received: from [128.89.253.73] (port=49483 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) 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" <rbarnes@bbn.com>
X-Priority: 3 (Normal)
In-Reply-To: <0090e9b435a992eaf44a521642c5f513.squirrel@www.trepanning.net>
Date: Fri, 22 Apr 2011 04:58:12 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <E0493562-DD68-4F65-9E5A-CD62C2653481@bbn.com>
References: <1E5F005F-8CC3-41B9-B860-A36ABA95E708@bbn.com> <0090e9b435a992eaf44a521642c5f513.squirrel@www.trepanning.net>
To: Dan Harkins <dharkins@lounge.org>
X-Mailer: Apple Mail (2.1082)
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 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! --Richard
- [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