Re: [TLS] Straw poll on TLS SRP status

pgut001@cs.auckland.ac.nz (Peter Gutmann) Wed, 30 May 2007 15:15 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPtN-0006Ro-Uh; Wed, 30 May 2007 11:15:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPtN-0006Re-0O for tls@ietf.org; Wed, 30 May 2007 11:15:17 -0400
Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtPtL-0006jT-JL for tls@ietf.org; Wed, 30 May 2007 11:15:16 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7BD2C4802BF; Thu, 31 May 2007 03:15:09 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gB6EAisg1JY6; Thu, 31 May 2007 03:15:09 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6096A48028F; Thu, 31 May 2007 03:15:09 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A086ED14CFB; Thu, 31 May 2007 03:15:08 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HtPtO-0002Rn-00; Thu, 31 May 2007 03:15:18 +1200
From: pgut001@cs.auckland.ac.nz
To: tjw@CS.Stanford.EDU, ynir@checkpoint.com
Subject: Re: [TLS] Straw poll on TLS SRP status
In-Reply-To: <450640D7-87B3-48E0-BBDF-68A7F399A7F2@checkpoint.com>
Message-Id: <E1HtPtO-0002Rn-00@medusa01.cs.auckland.ac.nz>
Date: Thu, 31 May 2007 03:15:18 +1200
X-Spam-Score: 0.5 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Yoav Nir <ynir@checkpoint.com> writes:

>I think SRP should not be a stand-alone extension, but rather that it should
>be introduced as part of EAP.
>
>The choice is between separate extensions for SRP and for each authentication
>method, or to introduce them all at once under EAP, as was done in IKEv2.

Is it possible to do this though?  Using the taxonomy I posted earlier, TLS-
SRP would seem to fall into the "modify the crypto portion of the TLS
handshake" bucket (alongside TLS-KRB5 and TLS-PSK), which means that you
couldn't really do it inside EAP.  Admittedly you could do a standard TLS
handshake and then follow it up with SRP inside EAP purely for the
authentication portion, but that seems (a) messy (see draft-iab-auth-mech-*)
and (b) a bit of a waste of SRP's capabilities, since it can do the whole key
exchange step as well.

Peter.


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls