Subject: Re: WG Last Call: draft-ietf-sasl-scram-02

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 Aug 2009 10:09:07 +0200

Peter Saint-Andre <[email-masked]> writes:

> On 7/30/09 2:37 PM, Simon Josefsson wrote:
>> Alexey Melnikov <[email-masked]> writes:
>> 
>>> Peter Saint-Andre wrote:
>>>
>>>>> SECTION 4
>>>>>
>>>>> Typo: "hashed function" => "hash function"
>>>>>
>>>>> I think the following text is slightly ambiguous:
>>>>>
>>>>>   The "-PLUS" suffix is used only when the server supports channel
>>>>>   binding to the external channel.  In this case the server will
>>>>>   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>>>>>   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>>>>>   negotiation of the use of channel binding.  See Section 6.
>>>>>
>>>>> This could be read to mean that if a server does not support channel
>>>>> bindings, then it will advertise only all and only SCRAM-SHA-1 (but
>>>>> never, say, SCRAM-SHA-256). I think we mean that if a server does not
>>>>> support channel bindings, then it will advertise only mechanisms of the
>>>>> form SCRAM-SHA-length and never mechanisms of the form
>>>>> SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
>>>>> other than SHA-1).
>>>>>    
>>>>>
>>>> Alexey and I talked about this in Stockholm. I suggest the following text:
>>>>
>>>>   The "-PLUS" suffix is used only when the server supports channel
>>>>   binding to the external channel.  If the server supports channel
>>>>   binding, it will advertise both the "bare" and "plus" versions of
>>>>   whatever mechanisms it supports (e.g., if the server supports only
>>>>   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
>>>>   and SCRAM-SHA-1-PLUS); if the server does not support channel
>>>>   binding, then it will advertise only the "bare" version of the
>>>>   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
>>>>   negotiation of the use of channel binding.  See Section 6.
>>>>  
>>>>
>>> Ok, this text will be in -04.
>> 
>> Please reassure me that the same change isn't needed in GS2?  I don't
>> see any normative words above, and as far as I can tell the described
>> behaviour is already covered by other text in both SCRAM and GS2 anyway.
>
> Do you think that the former text was not ambiguous?

No, I think your version is definitely better, but I couldn't find
matching text in GS2 to change.  I _think_ your clarification is already
covered by what's in GS2 today, including for example this text:

	      <t>Servers SHOULD advertise both non-PLUS and the
		PLUS-variant of each GS2 mechanism name.  If the
		server cannot support channel binding, it MAY
		advertise only the non-PLUS variant.  If the server
		would never succeed authentication of the non-PLUS
		variant due to policy reasons, it MAY advertise only
		the PLUS-variant.</t>

It doesn't use the same words although I believe the intention is the
same.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 14:01:13 -0600

On 7/13/09 8:17 PM, Tom Yu wrote:
> This message commences a WG Last Call on the following Internet-Draft:
> 
> 	Title           : Salted Challenge Response (SCRAM) SASL Mechanism

Although the WGLC is officially over, I have a question about the use of
SASLprep.

The SCRAM I-D (draft-ietf-sasl-scram-04) says the following:

   Before sending the username to the server, the client MUST
   prepare the username using the "SASLPrep" profile [RFC4013]
   of the "stringprep" algorithm [RFC3454].

In XMPP, we have traditionally used a different stringprep profile
("nodeprep") to prepare usernames. As far as I can see, nodeprep is more
strict than SASLprep. Therefore, any username which is prepared
according to nodeprep would be safe according to SASLprep.

Instead of requiring the application of SASLprep, I would prefer wording
such as this:

   Before sending the username to the server, the client MUST
   ensure that the username is formatted such that the "SASLPrep"
   profile [RFC4013] of the "stringprep" algorithm [RFC3454] can be
   applied to it without failing.

(We have similar wording in RFC 3920 and in rfc3920bis.)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Aug 2009 21:20:09 +0100

>    applied to it without failing.
Although initially, my thought was this wasn't needed, I wondered  
about the consequences.

It seems to me that, unless we assume that both client and server  
will always have precisely the same concept of "SASLprep", then one  
would assume the server would always have to apply SASLprep anyway.

SASLprep is, also bound to change - either gradual changes in Unicode  
will cause problems sufficient to case a rewrite, or we'll change  
SASLprep itself to be a property-based, instead of table-based,  
mechanism, and the gradual changes will filter through to  
implementations.

I'm inclined, therefore, to suggest that not only is this text  
reasonable, but the "MUST" can probably be reduced to a SHOULD.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Aug 2009 15:08:11 +0100

> reasonable, but the "MUST" can probably be reduced to a SHOULD.

I can live with the SHOULD.