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

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Dec 2009 19:04:56 +0000

Nicolas Williams wrote:

>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.
>
Such implementations are broken. The server end specifies all modes it 
support (bitmask), the client must pick one of the modes (only 1 bit) 
and send it back.

>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.)
>  
>