The Samba 3.0.0 code currently calls krb5_get_credential directly to get a
Kerberos service ticket for the server. The ticket is then wrapped in a pseudo
GSS wrapper before being sent out on the wire. The checksums used for the
Kerberos ticket authenticator differ when krb5_get_credential verses when
created through the GSSAPI interface.
The checksum generated by calling krb5_get_credential directly is 16 bytes long.
The checksum for a GSSAPI Kerberos ticket should be at least 24 bytes long.
I'll include a portion of the Kerberos 5 GSSAPI RFC below that references the
checksum as expected when a GSS wrapper is used:
"For purposes of this specification, the authenticator shall include
the optional sequence number, and the checksum field shall be used to
convey channel binding, service flags, and optional delegation
information. The checksum will have a type of 0x8003 (a value being
registered within the Kerberos protocol specification), and a value
field of at least 24 bytes in length. The length of the value field
is extended beyond 24 bytes if and only if an optional facility to
carry a Kerberos-defined KRB_CRED message for delegation purposes is
supported by an implementation and active on a context. When
delegation is active, a TGT with its FORWARDABLE flag set will be
transferred within the KRB_CRED message.
The checksum value field's format is as follows:
Byte Name Description
0..3 Lgth Number of bytes in Bnd field;
Currently contains hex 10 00 00 00
(16, represented in little-endian form)
4..19 Bnd MD5 hash of channel bindings, taken over all non-null
components of bindings, in order of declaration.
Integer fields within channel bindings are represented
in little-endian order for the purposes of the MD5
20..23 Flags Bit vector of context-establishment flags,
with values consistent with RFC-1509, p. 41:
The resulting bit vector is encoded into bytes 20..23
in little-endian form.
24..25 DlgOpt The Delegation Option identifier (=1) [optional]
26..27 Dlgth The length of the Deleg field. [optional]
28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional]"
This can be found on page 3 of RFC #1964.
Not all operating systems are as forgiving as Windows when it come to the GSSAPI
spec. Since the tickets are being wrapped in a GSSAPI wrapper, they should be
obtained using the GSSAPIs.
We can't use standard GSSAPI for a number of reasons:
- We need to access the raw kerberos (not gssapi) local/remote subkeys for SMB
- We need to control what principal we request as a target
Samba4 may use more GSSAPI, by close co-operation with a possibly included copy
of Heimdal kerberos. Otherwise, it's a non-starter, due to the level of
varience in this area.
For Samba3, this really is wontfix