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