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
