Subject: [sasl] RFC4752 (SASL/GSSAPI) interop problem

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Nov 2009 18:26:34 -0600

There is an interop problem between various implementations of RFC4752.

To remind you, RFC4752 (SASL/GSSAPI) looks like:

    <app-layer SASL mechanism negotiation>
    C->S: <initial security context token for GSS mechanism>
   [S->C: <reply security context token>]
   [C->S: <reply security context token>]
   [...]
  [[C->S: <empty>]]
    S->C: <wrap token containing a) a bitmask of supported security
           layers, b) the server's max message size>
    C->S: <wrap token containing a) the security layer requested by the
           client, b) the client's max message size, c) requested
	   authzid>
    S->C: <app-layer outcome of authentication message>

The interop problem relates to (a) in the C->S wrap token.  That item is
a bitmask, with three bits defined:

"
          1 No security layer
          2 Integrity protection.
            Sender calls GSS_Wrap with conf_flag set to FALSE
          4 Confidentiality protection.
            Sender calls GSS_Wrap with conf_flag set to TRUE
"

Now, one group of implementors interprets this to mean that in order to
require integrity _and_ confidentiality protection the client must set
both, 2 and 4, while another group of implementors interprets this to
mean that only 4 must be sent -- after all, the GSS-API requires that
integrity protection be provided when confidentiality protection is
requested, and anyways, it's not possible to set conf_flag to both,
FALSE and TRUE.

For example, Microsoft's Active Directory requires that clients send '6'
when the server is configured to require "LDAP signing and sealing".  So
does the Perl CPAN RFC4752 implementation.  Whereas Cyrus SASL and
derivative implementations, for example, require '4'.  (GNU SASL doesn't
support security layers, therefore it is not affected by this interop
bug.)

Whatever the rationales each implementor might give for one or the
other, this interop bug exists in the field, and some of us need to work
around it.

Clients cannot tell which interpretation a server uses.  They can only
know a priori or try first one way, then the other.  The outcome of
authentication message is typically not machine-readable, depending on
the application protocol (e.g., in the LDAP case).  Servers can choose
to accept 4 and 6 as equivalent choices by the client.

No, I'm not interested in an update to RFC4752 -- SASL/GS2 should just
replace it, but the WG should be aware of this issue.

Nico
--