Re: Last Call: draft-ietf-sasl-scram

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Review section 3 of RFC 4422 before reading on.  SCRAM negotiations in
general will look like:

      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!)

If the application protocol supports additional data together with
outcome of authentication exchange, the negotiation will look like:

      C: Request authentication exchange
      S: Empty Challenge
      C: SCRAM client-first
      S: SCRAM server-first
      C: SCRAM client-final
      S: Outcome of authentication exchange with SCRAM server-final

If the application protocol supports optional initial responses, the
negotiation will look like:

      C: Request authentication exchange with SCRAM client-first
      S: SCRAM server-first
      C: SCRAM client-final
      S: SCRAM server-final
      C: Empty Response
      S: Outcome of authentication exchange

If the application protocol supports both additional data together with
outcome of authentication exchange AND optional initial response, the
negotiation will look like:

      C: Request authentication exchange with SCRAM client-first
      S: SCRAM server-first
      C: SCRAM client-final
      S: Outcome of authentication exchange with SCRAM server-final

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:

OLD:
   The server verifies the nonce and the proof, verifies that the
   authorization identity (if supplied by the client in the first
   message) is authorized to act as the authentication identity, and,
   finally, it responds with a "server-final-message", concluding the
   authentication exchange.

NEW:
   The server verifies the nonce and the proof and that the
   authorization identity (if supplied by the client in the first
   message) is authorized to act as the authentication identity.  If the
   application protocol supports sending outcome of the authentication
   exchange, it sends the outcome together with the
   "server-final-message", concluding the exchange.  Otherwise, the
   server sends the "server-final-message" as a request.

OLD:
   The client then authenticates the server by computing the
   ServerSignature and comparing it to the value sent by the server.  If
   the two are different, the client MUST consider the authentication
   exchange to be unsuccessful and it might have to drop the connection.

NEW:
   The client then authenticates the server by computing the
   ServerSignature and comparing it to the value sent by the server.  If
   the two are different, the client MUST consider the authentication
   exchange to be unsuccessful and it might have to drop the connection.
   If the application protocol does not support sending additional
   data together with the outcome of authentication, the client MUST
   respond to the server request with a empty response.

Note that this problem have consequences for my implementation: the
earlier SCRAM traces I posted are incorrect since they do not have a
final empty client response.

/Simon
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]