[Date Prev][Date Next]
Re: SASL mechanisms that return no data in last leg
I'd have to agree with Alexey. The mechanism for provide data
with the last leg of the exchange is optional. That is, if there
is data to be sent AND the server chooses not to require
another roundtrip, the server can attach the data to last
Another point is that SASL allows the mechanism data
in any message of the exchange to be any octet string,
including a zero length string. Hence, it seems that
no string and a zero length string are not necessarily
semantically equivalent here.
At 05:14 PM 3/6/2004, Alexey Melnikov wrote:
>Luke Howard wrote:
>>We have noticed an interoperability issue with clients that
>>assume that saslServerCreds will be present, but zero length,
>>when a SASL mechanism returns no data for the last leg of an
>>authentication. (An example of such a mechanism is GSSAPI.)
>>OpenLDAP and PADL GSS-SASL both omit saslServerCreds in this
>>case, whereas Active Directory returns it with a zero-length
>>octet. It seems to me that the Active Directory behaviour
>>actually makes more sense, and the OpenLDAP client (which
>>uses Cyrus SASL) accepts both behaviours.
>Actually might interpretation of RFC 2222 would be exactly the opposite.
>If the last leg from the server to the client doesn't send anything, this means there is no "additional data with success". The latter implies that nothing should be sent.
>>However, we have
>>noticed that some proprietary GSSAPI SASL clients fail if
>>saslServerCreds is not present.
>>RFC 2222 doesn't really distinguished between not present and
>>zero length; it merely says that after the server receives the
>>last client response the "authentication process is complete".
>I guess the authmech document should say that clients should treat missing data in the last response from the server as if a zero length response was sent. And that for interoperability it is recommended to send zero length response.