Mac OSX Safari GSSAPI Bugs?

[Luke Howard]

>That requirement is guidance to mechanism designers, not implementors.  In 
>this case, and for some of the details below, you need to look at RFC1964 
>(in the longer term, the current version of the full Kerberos GSS-API 
>mechanism specification is defined in RFC4121, but for the age of code and 
>particular mechanisms involved, you really want to look at 1964.  You may 
>also need to read the SPNEGO spec; unfortunately, I don't recall that 
>number off the top of my head, but a quick search through the rfc-index 
>should find it).
>
>0x6e is the tag for [APPLICATION 14], which is indeed the first octet of a 
>properly encoded AP-REQ.  Effectively, the initial context token is not 
>wrapped as required by RFC2743.  I seem to recall this is a common failing, 
>though not how common.

I'm surprised this works at all. RFC 1964 requires the InitialContextToken
to be wrapped, it's just RFC 1508 that suggests the other tokens need not
be wrapped (although RFC 1964 overrules this).

How does the acceptor know what mechanism to dispatch to if the token is
not wrapped? I guess you know from mechTypes but that is an abstraction
violation that would make it impossible to build a mechanism glue that just
wraps around the GSS-API.

(Although, sigh, now I look at the Heimdal mechglue we already have code
to handle raw AP-REQs to deal with GSS_C_DCE_STYLE.)

>> 4) Safari's authenticator checksum type is MD5 whereas Heimdal and Win2K3
>>    client use 8003.
>
>This is also a bug in Safari.  The correct cksumtype is in fact 0x8003; 
>this magic "checksum" type is used by the Kerberos GSS-API mechanism to 
>convey options, channel bindings, and data related to credential 
>delegation.  The format of the checksum data is described in RFC1964, 
>starting on page 4.

It looks like Apple rolled their own GSS-API implementation; rolling their
own SPNEGO I can understand, but GSS? That just doesn't make sense to me.

-- Luke

--