Mac OSX Safari GSSAPI Bugs?

[Michael B Allen]

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.

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?

Thanks,
Mike