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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf