On 9/23/09, Nicolas Williams <Nicolas(_dot_)Williams(_at_)sun(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf