On 9/23/09, Nicolas Williams <Nicolas.Williams@xxxxxxx> 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. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf