Mac OSX Safari GSSAPI Bugs?
Michael B Allen
mba2000 at ioplex.com
Mon May 29 16:55:57 EDT 2006
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.
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).
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).
4) Safari's authenticator checksum type is MD5 whereas Heimdal and Win2K3
client use 8003.
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)).
Can anyone comment on these? What do you think the correct behavior should be?
More information about the krbdev