Mac OSX Safari GSSAPI Bugs?

[Jeffrey Hutzelman]

On Monday, May 29, 2006 04:55:57 PM -0400 Michael B Allen 
<mba2000 at ioplex.com> wrote:

> Hey,
>
> I've been studying Mac OSX 10.3 Safari 1.3.2 v312.6 GSSAPI tokens
> and I found a number of questionable differences with other
> implementations. They are listed here:
>
> 1) Safari's mechToken does not begin with the KRB5 OID and TOK_ID
>    of KRB5_AP_REQ. This causes Heimdal's GSS acceptor to choke with
>    GSS_S_DEFECTIVE_TOKEN.
>
>    According to RFC 2743 section 3.1:
>
> 3.1: Mechanism-Independent Token Format
>
>    This section specifies a mechanism-independent level of encapsulating
>    representation for the initial token of a GSS-API context ...
>    ... Use of this format is required for
>    initial context establishment tokens of Internet standards-track
>    GSS-API mechanisms; use in non-initial tokens is optional.
>
>    ... The token tag consists of the following elements, in order:
>
>       1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
>       -- constructed form, definite length encoding follows.
>
>     Safari's token begins with 0x6e which is the beginning of the AP-REQ.

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.


> 2) The Server Name field in Safari's ticket has a Name Type of 1
>    (Principal: www at FOO.NET) whereas Heimdal's is 3 (Service and Host:
>    HTTP/www.foo.net at FOO.NET). Win2K3 client uses 2 (Service and Instance:
>    HTTP/www.foo.net at FOO.NET).

The particular name type used is not relevant in this case; it's mostly 
informational for interpreting names.  The name itself is sufficient to 
tell what is going on; you can't have two distinct principals whose names 
differ only in type (see RFC4120 section 4.2.2), and most KDC's ignore it 
entirely when looking up entries in the Kerberos database.

In this case, the wrong name is also being used -- the correct name, per 
the HTTP Negotiate spec, is the GSS-API host-based service name 
"HTTP at server", which becomes the Kerberos principal 
HTTP/server.name at SERVER.REALM.  The use of the wrong name here is a known 
failing in some versions of Safari.


> 3) The Client Name field in Safari's ticket and authenticator has a Name
>    Type of 0 (Unknown) but with data consistent with type 1 (Principal)
>    whereas Heimdal and Win2K3 submit 1 (Principal: miallen at FOO.NET).

As mentioned above, the name type is irrelevant.


> 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.


> 5) Safari's authenticator does not contain a subkey whereas Heimdal and
>    Win2K3 do (Heimdal also submits an AuthorizationData field of a type
>    unknown to Ethereal (129)).

The use of a subkey is optional with this mechanism, per RFC1964.
Authorization data type 129 is AD-ETYPE-NEGOTIATION, which is used by an 
extension which allows Kerberos clients and app servers to negotiate the 
use of a better enctype than that of the session key provided by the KDC. 
The code assignment is retored in RFC4120 section 7.5.4, and the 
negotiation mechanism itself is defined in the upcoming RFC4537, due out 
any day now (until then, look at draft-zhu-kerb-enctype-nego-04.txt).


> Can anyone comment on these? What do you think the correct behavior
> should be?

<soap box>
Fortunately, correct behavior for protocols like these is generally not a 
matter of opinion or of comparing different implementations; instead, we 
have well-defined specifications which indicate exactly which behaviors are 
and are not compliant, what you can expect peers to do, and what you must 
do to interoperate.  Yes, there are some warts, inaccuracies in the specs, 
and badly-behaved-but-well-known implementations out there.  However, when 
implementing protocols for which specifications exist, it is best to always 
start with the spec, then do what you need to to work around bugs in other 
implementations, with an eye towards maintaining interoperability with 
correct ones.  Also, it helps not to ship product based on incomplete specs 
which have not yet been finalized, and to do plenty of interop testing 
before shipping.
</soap box>

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA