Subject: Re: FTP GSSAPI, Channel Bindings, and Windows 2000

From: Jeffrey Altman <[email-masked]>
Date: Sat, 2 Sep 2000 10:16:02 EDT

> > If it is possible to "be liberal in what we accept" in order to work
> > with the SSPI, this is fine with me, but not if it causes us no longer
> > to be "conservative in what we send" (that is, conformant to the
> > spec).
> 
> That's about what I'd suggest -- keep sending channel bindings, but
> allow them to be missing on receipt if MS isn't going to fix this
> soon.

The (slightly revised) patch that I submitted does just this.  It
treats GSS_C_NO_CHANNEL_BINDINGS as being a wild card.  If either side
specifies it, the channel bindings are ignored.  BUT if this is the
case, then there is little (if any) security benefit from the use of
channel bindings.

                  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: Ken Raeburn <[email-masked]>
Date: 01 Sep 2000 22:21:59 -0400

Martin Rex <[email-masked]> writes:
> 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.

It doesn't say who's option it is -- the mechanism specifier, the
implementor, or the application protocol specifier.

But the relatively weak recommendation in RFC1964 indicates to me that
the change you suggest should be just fine.

Ken

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 1 Sep 2000 12:26:41 EDT

> 
> Jeffrey Altman wrote:
> > 
> > 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.
> 
> This issue raises another interesting question:
> My GSSAPI v2 wrapper for W2K Kerberos silently ignored the channel
> bindings.  Is that ok, or should my wrapper rather fail upfront in
> gss_init_sec_context() and gss_accept_sec_context() when the
> application tries to pass real channel bindings?
> 
> -Martin
> 

The fix for MIT gssftpd required detecting the incorrect bindings
failure and then testing for the GSS_C_NO_BINDINGS value.  This
allowed SHOULD behavior instead of the MUST behavior.  But I
implemented this within gss_accept_sec_context() because there was no
appropriate error to indicate the problem was that the client sent
GSS_C_NO_BINDINGS instead of real binding data.  Preferably there
would be such as error message to indicate to the caller AND the
caller could then retry without binding info is appropriate.  This
currently does not exist.

On the client, the application must be able to enforce the SHOULD or
MUST requirements as well.  Therefore, an error should be generated
and the application should retry with GSS_C_NO_BINDINGS if that is
acceptable.  

The questions is: what should the error codes be?

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 31 Aug 2000 18:16:38 EDT

Martin wrote:
> 
> 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
> 

The following patch performs the above suggested relaxation.  It
solves the problem and allows Win2000 GSSAPI to be used with the MIT
FTPD. 

Index: accept_sec_context.c
===================================================================
RCS file: /cvs/krbdev/krb5/src/lib/gssapi/krb5/accept_sec_context.c,v
retrieving revision 1.53
diff -c -w -r1.53 accept_sec_context.c
*** accept_sec_context.c        2000/06/27 20:59:39     1.53
--- accept_sec_context.c        2000/08/31 22:13:35
***************
*** 425,433 ****
--- 425,443 ----

         TREAD_STR(ptr, ptr2, reqcksum.length);
         if (memcmp(ptr2, reqcksum.contents, reqcksum.length) != 0) {
+            xfree(reqcksum.contents);
+            reqcksum.contents = 0;
+            if ((code = kg_checksum_channel_bindings(context,
+                                                    GSS_C_NO_CHANNEL_BINDINGS,
+                                                     &reqcksum, bigend))) {
+                major_status = GSS_S_BAD_BINDINGS;
+                goto fail;
+            }
+            if (memcmp(ptr2, reqcksum.contents, reqcksum.length) != 0) {
                 code = 0;
                 major_status = GSS_S_BAD_BINDINGS;
                 goto fail;
+            }
         }

         xfree(reqcksum.contents);