Subject: Re: [sasl] Last Call: draft-ietf-sasl-scram

From: Alexey Melnikov <[email-masked]>
Date: Fri, 2 Oct 2009 16:33:16 +0100

Hi Pasi,

On Fri, Sep 25, 2009 at 12:32 PM,  <[email-masked]> wrote:
> Simon Josefsson wrote:
>
>> I'd be happy to help work on a document that analyzed the consequences
>> of replacing SASLprep with just-use-RFC5198 in SASL.  But I don't think
>> SCRAM should wait for something like it to materialize.
>
> I agree that such work would take time, and we don't want to delay
> SCRAM.

Agreed.

> But as the discussion so far has shown, normalization is a very tricky
> topic, and we can't really expect implementors to understand why "just
> use UTF-8" is problematic. Perhaps we should add a note to the SCRAM
> draft; something like
>
>   Informative Note: Implementors are encouraged to create test cases
>   that use both username passwords with non-ASCII characters. In
>   particular, it's useful to test characters whose "normalization
>   form C" and "normalization form KC" are different. Some examples of
>   such characters include Vulgar Fraction One Half (U+00BD) and
>   Acute Accent (U+00B4).

Added to my copy.

> Do you think this would increase the likelihood of interoperability
> with non-ASCII passwords?

It might help and I see no disadvantages from adding it.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 2 Oct 2009 16:37:57 +0100

On 9/23/09, Nicolas Williams <[email-masked]> wrote:
> On Wed, Sep 23, 2009 at 07:54:56PM +0200, Simon Josefsson wrote:
>  > I have noticed an additional problem related to additional data in
>  > SCRAM.  RFC 4422 section 5 item 2b says:
>  >
>  >       b) An indication of whether the server is expected to provide
>  >          additional data when indicating a successful outcome.  If so,
>  >          if the server sends the additional data as a challenge, the
>  >          specification MUST indicate that the response to this challenge
>  >          is an empty response.
>  >
>  > As far as I can tell, SCRAM does not specify that the response to a
>  > server-final sent as a challenge MUST be an empty client response.  This
>  > violates the requirements in RFC 4422 for new mechanisms.
>
> I'm not sure that not saying this violates RFC4422: one could argue that
>  this is implied, and it'd be better RFC4422 had been written in such a
>  way that we needn't repeat this over and over in all mechanism
>  specifications.

As a co-editor of RFC 4422 this is exactly what I would argue for.

> But I don't mind new text to cover this.
>
>
>  >       C: Request authentication exchange
>  >       S: Empty Challenge
>  >       C: SCRAM client-first
>  >       S: SCRAM server-first
>  >       C: SCRAM client-final
>  >       S: SCRAM server-final
>  >       C: Empty Response
>  >       S: Outcome of authentication exchange
>  >
>  > (Four round-trips, ouch!)
>
>
> Blame SASL, or, rather, SASL application protocols for two of those :)
>
>  And, of course, you're missing the mechanism negotiation round-trip
>  before that:
>
>         C: List server SASL mechanisms request
>         S: Server SASL mechanism list response
>
>  > I believe section 5 needs to be rewritten to take all these variants
>  > into account.  Right now the wordings all assume the last situation.
>  >
>  > OLD:
>  >    First, the client sends the "client-first-message" containing:
>  >
>  > NEW:
>  >    If the application protocol does not support optional initial
>  >    responses, the client will request authentication and the first
>  >    server challenge MUST be empty.  The first non-empty client response
>  >    is the "client-first-message" containing:
>  >
>
> > [...]
>
>  I don't think this is necessary.

Agreed.

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Oct 2009 12:35:04 -0400

--On Friday, October 02, 2009 16:33 +0100 Alexey Melnikov
<[email-masked]> wrote:

>...
>> topic, and we can't really expect implementors to understand
>> why "just use UTF-8" is problematic. Perhaps we should add a
>> note to the SCRAM draft; something like
>> 
>>   Informative Note: Implementors are encouraged to create
>>   test cases that use both username passwords with non-ASCII
>>   characters. In particular, it's useful to test characters
>>   whose "normalization form C" and "normalization form KC"
>>   are different. Some examples of such characters include
>>   Vulgar Fraction One Half (U+00BD) and Acute Accent (U+00B4).
> 
> Added to my copy.
> 
>> Do you think this would increase the likelihood of
>> interoperability with non-ASCII passwords?
> 

Agreed.  I don't expect it to help a lot, but it can't hurt and
is better than leaving the subject completely to the imagination
of implementors who are not expert in Unicode idiosyncrasies.

   john