Request for allocation regarding RFC4752 (SASL/GSSAPI) interop problem

[Alexey Melnikov]

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.
>
>Whereas Cyrus SASL, for example, requires '4'.
>
Cyrus SASL interpretation is the correct one, of course ;-).

But anyway, I agree this is a bit of a problem.
Have you sent a message to CPAN people on this?

>Whatever the rationales each implementor might give for one or the
>other, this interop bug exists in the field, and we need to work around
>it.
>
>Clients cannot tell which interpretation a server uses.  They can only
>be told by the application a priori.  Servers can choose to accept 4 and
>6 as equivalent choices by the client.
>
>Therefore I propose:
>
>a) that Cyrus SASL's 'gss' plugin treat '4' and '6' as equivalent, on
>the server side;
>  
>
This would be fine.

>b) that Cyrus SASL add a property for specifying which to send on the
>client side;
>  
>
This is going to be more involved.

>and
>
>c) that applications that can re-bind or re-connect try it one way, then
>the other, while applications that cannot should make the choice of
>behavior configurable.
>
>OpenSolaris will be implementing the above.  Therefore we'd like at
>least a property name and number to be allocated for (b).
>
Ok. Can you suggest a property name? Once you do, I will allocate it.

>(Yes, I'll be sending e-mail about this to the SASL WG list too, but
>separately.  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.)
>  
>
Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address