Subject: draft-burdis-cat-srp-sasl-05

From: Keith Burdis <[email-masked]>
Date: Sun, 4 Nov 2001 20:58:54 +0200

Greetings

Raif and I are pleased to announce that we've released a new version of the
SRP SASL mechanism draft for comment. Here is the list of changes since the
previous version:

 - Added element size limits and changed SHOULD to MUST in Section 3.7.
      
 - Added "mandatory" and "maxbuffersize" options, and changed SHOULD, SHOULD
   NOT to MUST and MUST NOT in Section 4.2.
	     
 - The salt s is now sent with N and g.  The rationale is to make the
   exchanges, as well as the ordering of their elements, closer to [RFC-
   2945].
		       
 - Made sending the server evidence M2 conditional upon activation of
   Confidentiality Protection security service.  Now, the server MUST only
   send M2 if Confidentiality Protection is not activated, and MUST NOT if
   it is.
				    
 - Changed the order of elements when computing both M1 (client's evidence)
   and M2 (server's evidence) to reflect the informal SRP convention, which
   is to place any "extra" data for the hash at the end.
						 
 - Added a new section, "Replay detection sequence number counters" (Section
   7.3), that describes how these counters are used to provide replay
   detection.
							   
 - Added a new section, "SASL Profile Considerations," (Section 7.4) where
   various SASL profile related issues are covered.
								  
 - Updated the list of contributors.
								      
 - Changed the references to use symbolic names instead of numbers.

The one change that may need to be explained further is that of not sending
M2 when confidentiality protection has been negotiated. The reason for doing
this is to avoid an extra round trip when it is not needed. If
confidentatiality protection is active then the client can use the first
message it receives from the server in the security layer to determine
whether or not the server knows the session key. Additionally, if the server
does not know the session key, then it will not be able to decrypt any
messages sent by the client.

We would like to thank Stephen Farrell, Magnus Nyström and Thomas Wu for the
feedback that they provided on the previous draft. Many of the
clarifications and improvements can be attributed to their questions and
suggestions.

As always, comments are welcome.

  - Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras					JAPH 	QEFH
---