Bug 780 - GSSAPI gss_acquire_cred should be used to get Kerberos credentials
Summary: GSSAPI gss_acquire_cred should be used to get Kerberos credentials
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 3.0.0
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
Depends on:
Reported: 2003-11-14 14:26 UTC by Charles Emig
Modified: 2004-12-22 19:25 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Charles Emig 2003-11-14 14:26:45 UTC
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:
                           GSS_C_DELEG_FLAG:       1
                           GSS_C_MUTUAL_FLAG:      2
                           GSS_C_REPLAY_FLAG:      4
                           GSS_C_SEQUENCE_FLAG:    8
                           GSS_C_CONF_FLAG:        16
                           GSS_C_INTEG_FLAG:       32
                   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.
Comment 1 Andrew Bartlett 2004-12-22 19:24:28 UTC
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.
Comment 2 Andrew Bartlett 2004-12-22 19:25:09 UTC
For Samba3, this really is wontfix