[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

[David Woodhouse]

On Fri, 2014-07-25 at 20:01 -0400, Greg Hudson wrote:
> On 07/25/2014 07:26 PM, David Woodhouse wrote:
> > Looking at handle_mic(), I think our implementation will return
> > GSS_S_DEFECTIVE_TOKEN if it sees a final mechanism token without the MIC
> > attached. It doesn't return GSS_S_CONTINUE_NEEDED and hope for the MIC
> > to come in later on its own. I don't think that's even possible.
> 
> The server appears to do so if it sends the final mech token.  It has
> to; the client can't necessarily produce a MIC until the context is
> established.
> 
> (My reasoning, with line numbers from current master: handle_mic decides
> to reject at line 528 if no token is to be sent, but continues on if a
> token is to be sent.  At line 559, it decides to respond with
> ACCEPT_INCOMPLETE if a MIC is required.)

Ah, right. In the case where our server sends the final mech token,
although the underlying mechanism is complete, the SPNEGO negotiation
isn't. So the overall authentication isn't done yet;
spnego_gss_init_sec_context() will end up returning
GSS_S_CONTINUE_NEEDED to its caller and, for example, the HTTP server
will return the token in another 401 'Unauthorized' response to the
client.

If the underlying mechanism has completed and established a security
context, but the overall authentication has not succeeded, is that
materially different from the proposed solution that allows the
underlying security context to be established and then queries it to see
if the fallback without MIC was 'believable'?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140726/a8457a66/attachment.bin