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. 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. Instead I think we can add text saying that we're describing the full, uncompressed exchange, and that nothing in SCRAM prevents either sending the client-first message with the authentication request, nor sending the server-final message as additional data of the outcome of authentication message + a redundant re-statement of the rule from RFC4422 section 5, item 2(b). For my money the result will be more readable this way. Nico -- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf