Subject: Re: draft-burdis-cat-srp-sasl-07.txt

From: "Trevor Perrin" <[email-masked]>
Date: Sat, 14 Sep 2002 13:49:08 -0800

>From: "Raif S. Naffah" <[email-masked]>
>
>>Also, the Introduction says that this draft is based on the optimized SRP 
>>protocol from RFC 2945, but it isn't, that statement is probably just left 
>>over from a previous draft and should be struck.
>
>it isn't?  could you be more specific and point out where it is
>misleading/ambiguous; TIA.
>

The "optimized" SRP protocol in RFC 2945 has the client send the A value in 
the same message as U, and has the server send the B value in the same 
message as s:

C->S: U,A
C<-S: s,B

Your protocol follows the "unoptimized" SRP protocol from RFC 2945:

C->S: U
S<-C: s
C->S: A
S<-C: B

Nothing wrong with that, just adds a round trip, and in fact since you 
assume that g,N aren't known by prior agreement, but must be sent along with 
s, you probably need to use the unoptimized version, since the Client 
doesn't yet know the g,N to use for computing A when sending U.

An alternative would be to allow the client to guess at a default value of 
g,N and send a tentative A value along with g,N, on its U message.  If the 
server accepts the client's g,N than it returns B on its next message, thus 
using the optimized version, otherwise the server ignores the client's A and 
returns its choice for g,N, thus using the unoptimized version..

Whether trimming a roundtrip in some cases is worth this much effort, I 
dunno, but its something I proposed to the TLS/SRP effort as well.

Trevor

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com