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 mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf