|
The text in draft-ietf-ldapbis-authmeth-05.txt Section 8.2 paragraph 6 is
identical to RFC 2829 Section 6.1 paragraph 5, so this wording predates the
revision work being done in the ldapbis working group.
That said, here is a summary of my review of the issue:
1. Based on the wording of RFC2831 section 2.1.3 it appears that
the intent was for the response-auth to always be sent.
2. It appears that one use of the response-auth is to provide a limited
form of mutual authentication of the server to the client (i.e. the server can
at least prove that it knows the client's password, thus it can be
trusted).
3. For purposes of mutual authentication, the value of the response-auth is
equally valuable regardless of whether the client and server support subsequent
authentication.
4. The response-auth value is required to perform subsequent
authentication.
5. The only reason I can see for making the response-auth optional WRT LDAP
is to signal to the client whether the server supports subsequent
authentication.
I believe we should modify the text of authmeth-05 section 8.2 paragraph 6
to always have the credentials field contain the value of response-auth *if*
this can be done without causing a problem for item 5 above (ability to signal
server support for subsequent authenticaion) AND also not cause interoperability
problems for clients that may not be expecting the value.
I'd would greatly appreciate guidance from other working group members on
the best course of action to take.
Thanks,
Roger
Roger G. Harrison
Manager, eDirectory Core and Utilities Novell, Inc., the Leader Provider of Net Business Solutions www.novell.com >>> Mark Ennis <mark.ennis@adacel.com> 4/14/2003 11:48:24 PM >>> The current draft of authmeth (draft-ietf-ldapbis-authmeth-05.txt) indicates, in section 8.2 paragraph 6, that the response-auth SASL message is only included in the bind response for a successful bind when the server supports subsequent authentication. This seems counter to the intention of RFC2831 section 2.1.3 which indicates that the response-auth should always be returned. The response-auth provides one of the security aspects documented in RFC2831, that of protection against "Spoofing by counterfeit servers" (section 3.8). RFC2617, upon which RFC2831 is based, describes this protection as "The optional response digest in the "response-auth" directive supports mutual authentication -- the server proves that it knows the user's secret, and with qop=auth-int also provides limited integrity protection of the response.". Note that response-auth is optional in RFC2617, but not (in my opinion) in RFC2831. Was this diversion from the apparent intention of RFC2831 intentional and if so, what is the reasoning behind weakening the authentication procedure in this way? Regards, Mark Ennis |