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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
