Re: DIGEST-MD5: conflict between RFC 2829 and RFC 2831

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Please cc ietf-ldapbis@openldap.org on any issue pertaining
to the LDAP SASL profile (RFC 2251/2829).  I note that DIGEST-MD5
is actually on the LDAPbis charter as well... (at least until
a SASL WG is formed).

Kurt

At 11:22 AM 3/27/01 -0500, Steve Miller wrote:
>Hi,
>
>We are currently building our own ldap/SASL DIGEST-MD5 implementation,
>and have been testing against the Openldap (2.0.7) with the Cyrus
>(1.5.24) SASL implementation. We have source code for both.
>
>We ran into an interoperability problem between the OpenLdap/Cyrus
>client and our server. I tracked it down to a difference in step 3 of
>RFC2831, that is the second server response to the client. Section 2.1.3
>of that spec says:
>
>2.1.3  Step Three
>
>   The server receives and validates the "digest-response". The server
>   checks that the nonce-count is "00000001". If it supports subsequent
>   authentication (see section 2.2), it saves the value of the nonce and
>** the nonce-count. It sends a message formatted as follows:
>
>    response-auth = "rspauth" "=" response-value
>    ...
>
>   where response-value is calculated as above, using the values sent in
> 
>
>And RFC 2829, Authentication Methods for LDAP, section 6.1 says:
>
>   ...
>   The server will respond with a bind response in which the resultCode
>   is either success, or an error indication.  If the authentication is
>** successful and the server does not support subsequent authentication,
>** then the credentials field is absent.  If the authentication is
>   successful and the server supports subsequent authentication, then
>   the credentials field contains the string defined by "response-auth"
>   in section 2.1.3 of [4].   Support for subsequent authentication is
>   OPTIONAL in clients and servers.
>
>
>According to subsequent email discussions with Larry Greenfield
>(CMU/Cyrus), RFC 2829 is incorrect in this regard, and inconsistent with
>current practice, which always send the 'rspauth', even if the server
>does not support subsequent authentication.
>
>Since I've just started following these lists, I'm not clear on how to
>get this resolved; I'm certainly willing to help.  A possible re-wording
>is:
>
>
>RFC 2831
>  ...
>  The server receives and validates the "digest-response". The server
>  checks that the nonce-count is "00000001". It sends a message
>formatted as follows:
>
>  ...(description of rspauth )...
>
>  If the server supports subsequent authentication (see section 2.2), it
>saves the value of the nonce   and the nonce-count.
>  ...
>
>RFC 2829
>   ...
>   The server will respond with a bind response in which the resultCode
>   is either success, or an error indication.  If the authentication is
>   successful , then the credentials field contains the string defined
>by "response-auth"
>   in section 2.1.3 of [4].   Support for subsequent authentication is
>   OPTIONAL in clients and servers.
>   ...
>
>
>Steve