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