Subject: Re: [TLS] Straw poll on TLS SRP status

From: Tom Wu <[email-masked]>
Date: Sun, 27 May 2007 15:40:44 -0700 (PDT)

> I really think you should give the user the choice between IPR-laden methods (such as EAP-SRP) and IPR-free methods such as EAP-MD5.

As you indicate, your bias affects how you frame the issue and what
premises you accept.  In actuality, your point is ironically a good
one in favor of making TLS-SRP Proposed, precisely because it's a good
thing to have a choice between a strong password solution (TLS-SRP)
and a weaker one (EAP-MD5?) in TLS.

And given that SRP's licensing terms have made it the most widespread
of the various strong password techniques, it's the only viable
candidate for Proposed status, if you believe that it is to the
benefit of the greater good to have a strong (against passive and
active dictionary attack), well-tested, and standardized mechanism
for password authentication over TLS.  Then let the market decide.

Tom
-- 
Tom Wu
http://www-cs-students.stanford.edu/~tjw/

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 May 2007 13:59:38 +0300

Note that I am not against SRP at all.  Although the EAP-SRP effort  
seems to have been abandoned, it still has method type number 19 in  
IANA.

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.

On May 28, 2007, at 1:40 AM, Tom Wu wrote:

>> I really think you should give the user the choice between IPR- 
>> laden methods (such as EAP-SRP) and IPR-free methods such as EAP-MD5.
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 31 May 2007 03:15:18 +1200

Yoav Nir <[email-masked]> 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.