Request for allocation regarding RFC4752 (SASL/GSSAPI) interop problem
alexey.melnikov at isode.com
Sat Dec 5 14:17:54 EST 2009
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
> 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
>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
This is going to be more involved.
>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
>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.)
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
More information about the Cyrus-sasl