Mac OSX Safari GSSAPI Bugs?
jhutz at cmu.edu
Mon May 29 18:00:27 EDT 2006
On Monday, May 29, 2006 04:55:57 PM -0400 Michael B Allen
<mba2000 at ioplex.com> wrote:
> 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
> 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?
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
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
More information about the krbdev