[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Should response-auth be optional for digest authentication in authmeth?



My impression is that using the presences/absence of the rspauth field to indicate support for subsequent authentication is unnecessary as RFC2831 section 2.2.2 indicates an attempt to use subsequent authentication should be ignored by servers which do not permit it (it is treated as a request for authenticaion and the server response is a new digest-challenge).

- Mark.

Roger Harrison wrote:
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 <http://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