Subject: FTP GSSAPI, Channel Bindings, and Windows 2000

From: Jeffrey Altman <[email-masked]>
Date: Thu, 31 Aug 2000 13:45:51 EDT

Martin Rex has pointed out to me that the Windows 2000 Kerberos 5 SSPI
does not support the functionality necessary for implementing Channel
Bindings in GSSAPI-KRB5.  I have just discovered that if channel
bindings are not sent by the FTP client, the MIT K5 FTP server cannot
authenticate the provided credentials and the errors returned are
somewhat random:

  GSSAPI accepted as authentication type
  Trying to authenticate to <[email-masked]>
  calling gss_init_sec_context  
  ---> ADAT
  535-GSSAPI error major: Miscellaneous failure
  535-GSSAPI error minor: Wrong principal in request
  535 GSSAPI error: accepting context
  ---> AUTH GSSAPI
  334 Using authentication type GSSAPI; ADAT must follow
  Trying to authenticate to <[email-masked]>
  calling gss_init_sec_context
  ---> ADAT
  535-GSSAPI error major: Incorrect channel bindings were supplied
  535-GSSAPI error minor: No error
  535 GSSAPI error: accepting context
  GSSAPI ADAT failed

Notice the error for "ftp" is wrong principal in request.  This error
is incorrect as ftp/[email-masked] is a
valid service ticket for which the appropriate keytab entries are
available.  And for which it succeeds when channel bindings are
provided:

  Connected to yclept.kermit.columbia.edu.
  220 yclept.kermit.columbia.edu FTP server (Version 5.60) ready.
  ---> AUTH GSSAPI
  334 Using authentication type GSSAPI; ADAT must follow
  GSSAPI accepted as authentication type
  Trying to authenticate to <[email-masked]>
  calling gss_init_sec_context
  ---> ADAT
  calling gss_init_sec_context
  GSSAPI authentication succeeded
  FTP Command channel is Private (encrypted)

I am assuming (since there appears to be no method to negotiate the
use of channel bindings) that channel bindings are required for the
FTP GSSAPI-KRB5 protocol and therefore it is impossible to implement
this protocol with Windows 2000's Kerberos 5 SSPI.  This definitely
appears to be the reading of page 25 of RFC 2228.

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 31 Aug 2000 21:13:30 +0200 (METDST)

Jeffrey Altman wrote:
> authenticate the provided credentials.
>
 [...]
> appears to be the reading of page 25 of RFC 2228.

I'm not convinced that (only) W2K Kerberos is wrong here.

Although there are several places among the following documents:

   RFC1964  The Kerberos 5 GSS-API mechanism
   RFC2228  FTP Security Extensions
   RFC2743  GSS-API v2 Update 1 (high level document)
   RFC2744  GSS-API v2 C-Bindings

that talk about channel bindings, there are three sections that
I find particularly interesting:

RFC2228: FTP Security Extensions, Appendix I (Page 25)

     The chan_bindings input to GSS_Init_Sec_Context and
     GSS_Accept_Sec_Context should use the client internet address and
     server internet address as the initiator and acceptor addresses,
     respectively.  The address type for both should be GSS_C_AF_INET. No
     application data should be specified.

I can only see a "should" here, not a shall or must.
Does the RFC2228 imply that it should not prevent interoperability if just
one of client or server uses channel bindings and the other one doesn't?

RFC2743: GSS-API v2 Update 1 (high level document)

  1.1.3:  Security Contexts

     No correlation between security context and communications protocol
     association is dictated. (The optional channel binding facility,
     discussed in Section 1.1.6 of this document, represents an
     intentional exception to this rule, supporting additional protection
     features within GSS-API supporting mechanisms.)

The high level spec rfc2743 states that the channel bindings facility
is optional.

RFC1964: The Kerberos 5 GSSAPI mechansism
  1.1.1. Initial Token

     In computing the contents of the "Bnd" field, the following detailed
     points apply:

        (1) Each integer field shall be formatted into four bytes, using
        little-endian byte ordering, for purposes of MD5 hash
        computation.

        (2) All input length fields within gss_buffer_desc elements of a
        gss_channel_bindings_struct, even those which are zero-valued,
        shall be included in the hash calculation; the value elements of
        gss_buffer_desc elements shall be dereferenced, and the
        resulting data shall be included within the hash computation,
        only for the case of gss_buffer_desc elements having non-zero
        length specifiers.

        (3) If the caller passes the value GSS_C_NO_BINDINGS instead of
        a valid channel bindings structure, the Bnd field shall be set
        to 16 zero-valued bytes.

     When input source address channel binding values are provided by a
     caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the
     source address specifier value within the input structure is
     GSS_C_NULL_ADDRTYPE), and the corresponding token received from the
     context's peer bears address restrictions, it is recommended that an
     implementation of the Kerberos V5 GSS-API mechanism should check that
     the source address as provided by the caller matches that in the
     received token, and should return the GSS_S_BAD_BINDINGS major_status
     value if a mismatch is detected. Note: discussion is ongoing about
     the strength of recommendation to be made in this area, and on the
     circumstances under which such a recommendation should be applicable;
     implementors are therefore advised that changes on this matter may be
     included in subsequent versions of this specification.

Now this is interesting:  This last paragraph suggests primarily that
gss_accept_sec_context() should use acceptor-supplied channel bindings
to match against ticket restrictions in the KRB_AP_REQ.  It doesn't
require (and doesn't even mention) that context establishment should
fail if one did supply channel bindings and the other one didn't.

How about relaxing the check of the channel bindings of MIT Kerberos 
in gss_accept_sec_context() so that it doesn't fail when acceptor used
channel bindings and the initiator didn't?  gss_accept_sec_context() may
still check the IP-Addrs in the ticket in this case -- which would
be closer to what traditional Kerberos was doing, I think.

-Martin