Subject: Re: Bind and StrongAuthRequired

From: Simon Spero <[email-masked]>
Date: Fri, 26 Jul 2002 19:32:35 -0400

[Allow BindResponse to request a stronger authentiation mechanism]

This change makes a lot of sense; it also suggests removing the requirement 
in [draft-ietf-ldapbis-authmeth-03.txt: para G.12] that states that servers 
MUST support password based authentication.

If a server is allowed to reject binds for reasons of lack of strength, 
it's silly to require a server to advertise a mechanism that it knows in 
advance it's going to reject.

BTW, were there any changes made to the auth document?

Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 26 Jul 2002 20:33:27 -0700

At 04:32 PM 2002-07-26, Simon Spero wrote:
>This change makes a lot of sense; it also suggests removing the requirement in [draft-ietf-ldapbis-authmeth-03.txt: para G.12] that states that servers MUST support password based authentication.

LDAP must have a mandatory-to-implement strong authentication
mechanism.  That's DIGEST-MD5.

Note that mandatory-to-implement does not imply mandatory-to-use.
A server SHOULD NOT advertise mechanisms which are not available
for use.

The authmeth I-D needs to clarified such that it is clear that
DIGEST-MD5 MUST be implemented if any form of authentication
(other than anonymous) is implemented.  That is, section 3 (2)
ought to be replaced with:
        Implementations which support any form of authentication
        (other than anonymous) MUST implement the SASL DIGEST-MD5
        mechanism [4], as described in 8.2.  This provides client
        authentication with protection against passive eavesdropping  
        attacks, but does not provide protection against active
        intermediary attacks.  DIGEST-MD5 also provides data
        integrity and data confidentiality capabilities.

I also suggest that implementation of DIGEST-MD5
integrity protections be made REQUIRED and
data confidentiality RECOMMENDED.  Integrity
protections, in particular, are necessary to
prevent hijack attacks.

(This might be viewed as a RFC 2831bis issue.  But
whether its done in authmeth or 2831bis, I think it
needs to be done.)

>If a server is allowed to reject binds for reasons of lack of strength, it's silly to require a server to advertise a mechanism that it knows in advance it's going to reject.

I concur.

>BTW, were there any changes made to the auth document?

Not since the last revision...  NOW is a very good time to
comment on authmeth.

---

From: Simon Spero <[email-masked]>
Date: Mon, 29 Jul 2002 14:50:07 -0400

> mechanism.  That's DIGEST-MD5.

Are you  distinguishing between 'support' and 'implement'? i.e. is a 
conformant implementation required to provide code that can perform the 
protocol interactions described in the relevant RFC, but not required to 
make this mechanism available to a client, or provide the infrastructure to 
support secure storage of user and password information?

>         mechanism [4], as described in 8.2.  This provides client

I'm still not sure why it's necessary to require a server that support any 
kind of authentication (non-password) authentication  to implement support 
for password authentication.

 It makes sense to require servers not only to implement but to offer 
DIGEST-MD5 iff any form of password authentication is supported, but in 
servers designed for use in (e.g.) a Kerberos-based environment requiring 
implementation support for passwords seems like an undue burden.

Simon

---

From: Mark Wahl <[email-masked]>
Date: Mon, 29 Jul 2002 14:11:41 -0500

> protections, in particular, are necessary to

That would seem to be a new requirement beyond what was required for 
LDAPv3.  Existing implementations of DIGEST-MD5 in LDAPv3 which support only
password protection would thus not interoperate if an implementation of 
LDAPv3bis required integrity protection.   But I don't see an 
interoperability problem with current implementations, and whether hijack
attacks is possible or likely depends on the network environment.  What is 
the case for other protocols with similar deployment issues like perhaps 
IMAP that use SASL?  Do they mandate integrity protection?  

I suggest we separate solving _interoperability_ problems from new features
and new requirements.

Mark Wahl
Sun Microsystems Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Jul 2002 13:27:27 -0700

For now, let's table this issue (as an LDAPbis issue).

Those interested in discussing the larger SASL/DIGEST-MD5
security layer issue should participate in SASL mailing
list <[email-masked]> discussions.  I am sure this
issue will come up in their RFC2831bis work.

(Note that we're presently deferring our RFC 2831 work
item to the SASL mailing list as they are appear better
suited to do this engineering.)

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Jul 2002 13:05:29 -0700

At 11:50 AM 2002-07-29, Simon Spero wrote:
>--On Friday, July 26, 2002 8:33 PM -0700 "Kurt D. Zeilenga" <[email-masked]> wrote:
>
>Are you  distinguishing between 'support' and 'implement'?

Yes. MUST/SHOULD/MAY state requirements upon implementations,
not upon users (or deployments) of those implementations.  If
I recall correctly, the technical specification states that
implementations should be allow individual mechanisms to be
disabled.  (If not, we should add such.)

>I'm still not sure why it's necessary to require a server that support any kind of authentication (non-password) authentication  to implement support for password authentication.

It considered required that each protocol which support update
operations to have a suitable mandatory-to-implement authentication
mechanism.  The long standing consensus is that DIGEST-MD5
is LDAP's mandatory-to-implement authentication mechanism.

>It makes sense to require servers not only to implement but to offer DIGEST-MD5 iff any form of password authentication is supported, but in servers designed for use in (e.g.) a Kerberos-based environment requiring implementation support for passwords seems like an undue burden.

Interoperability on the Internet (which is what we design for)
requires all implementations be burden with the requirement
for mandatory-to-implement mechanism.