The acceptor verifies the initiator MIC and then, in its last leg, calls
GSS_GetMIC on the entire conversation (including both last legs, excepting the
acceptor MIC) and sends it in an extension token to the initiator. The
initiator verifies the acceptor MIC before returning GSS_S_COMPLETE. (It is
true that this approach does require the client and server to maintain the
entire conversation state.)
Maybe this is just a stupid question, but do they really need to
maintain state of the entire conversation? I mean, both parties could
just maintain the result of a hash over the conversation so far, built
in an iterative way. Something like this:
state' = hash (state, new_message)
At the end of the conversation, they could compute GSS_mic over the state.
May be the overload of computing such hashes is worse than the memory
needed to store the entire state.
Regards,
Alejandro
With respect to communicating the mutual authentication state, a new TLV token
type is defined containing a 32-bit integer in network byte order, which
consists of req_flags as passed to GSS_Init_sec_context. These flags are masked
by, currently, GSS_C_MUTUAL_FLAG before encoding. Other flags may be allowed in
the future; at this stage we do not wish to reveal in plaintext anything more
than the mutual authentication state.
Once the acceptor returns GSS_S_COMPLETE, it will set the received mutual
authentication state in ret_flags.
-- Luke
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
