[11411] in Kerberos-V5-bugs
[krbdev.mit.edu #6603] issues with SPNEGO
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Sat Feb 20 23:07:36 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6603@krbdev.mit.edu>
Message-ID: <rt-6603-32500.3.25016367158902@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6603'":;"'AdminCc of krbdev.mit.edu Ticket #6603'":;@MIT.EDU
Date: Sat, 20 Feb 2010 23:07:33 -0500 (EST)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
A little analysis of the reported problems:
1. A final token produced by the initiator is not sent to the acceptor.
I would describe this problem differently: the initiator will not send
more than two tokens to the acceptor unless a MIC is required. The bug
here is that on the second call to init_ctx_cont (the third call to
spnego_gss_init_sec_context), if no MIC is required for the negotiation,
*negState is set to ACCEPT_COMPLETE and *tokflag (aka send_token) is set
to NO_TOKEN_SEND without regard for whether the token exchange has
completed. If the mechanism produces an output token,
init_ctx_call_init will set negState back to ACCEPT_INCOMPLETE, but will
leave send_token as NO_TOKEN_SEND, so spnego_gss_init_sec_context
returns GSS_S_CONTINUE_NEEDED without setting the output token--clearly
invalid behavior.
The proposed fix is to use acc_negState to decide which way to set
*negState and *tokflag. However, RFC 4178 says that acc_negState is
optional after the first reply from the target; if the target doesn't
send it, then acc_negState will have the value ACCEPT_DEFECTIVE_TOKEN
(even though the token isn't defective) and we are supposed to deduce
the negotiation state from the return value of the selected mechanism's
init_sec_context call. The proposed fix does not handle this contingency.
2. If the mechanism doesn't set
GSS_C_INTEG_FLAG, the acceptor never sets the state to ACCEPT_COMPLETE.
This appears to be a failure of the code to check for (sc->ctx_flags &
GSS_C_INTEG_FLAG) in all of the cases where it checks for sc->mic_reqd.
The proposed fix is to set sc->mic_reqd to 0 before a particular check
of sc->mic_reqd in acc_ctx_call_acc if (sc->ctx_flags &
GSS_C_INTEG_FLAG) is false. I don't think that improves the overall
cleanliness of the logic. Consistently using a static inline to check
for (sc->mic_reqd && (sc->ctx_flags & GSS_C_INTEG_FLAG)) might be better.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
