[Date Prev][Date Next]
RE: authmeth: missing protection
- To: "John McMeeking" <email@example.com>, <ietf-ldapbis@OpenLDAP.org>
- Subject: RE: authmeth: missing protection
- From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
- Date: Tue, 17 Feb 2004 11:10:39 +1100
- Content-class: urn:content-classes:message
- Thread-index: AcP0nr+6kO4IaYT9TCm3p5+XvqijAwAS3OIQ
- Thread-topic: authmeth: missing protection
As the mechanism is recommended by LDAP, and not the free choice of the implementer, there is a responsibility to provide some context for its use.
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of John McMeeking
Sent: Tuesday, 17 February 2004 01:59
Subject: Re: authmeth: missing protection
I can't speak to this issue specifically, but it raises a minor question:
Is there any reason to say anyhting about this in authmeth? Weaknesses of
DIGEST-MD5 apply to any protocol that supports it, not just LDAP. The same
thing applies to discussion of TLS ciphers that are recommended or not. Is
it common practice to list such issues in standards for other protocols
that support such technologies? It seems like the kind of thing that
should be said in one place, and applies to all applications of that
"Roger Harrison" <RHARRISON@novell.com> wrote on 02/16/2004 03:03:56 AM:
> > >>> Hallvard B Furuseth <firstname.lastname@example.org> 1/3/2004 7:34:57 AM
> > authmeth-09 says:
> > > 6.2. Digest Authentication
> > >
> > > (...) [DIGEST-MD5]. This provides client
> > > authentication with protection against passive eavesdropping
> > > attacks, but does not provide protection against active intermediary
> > > attacks.
> > What does this mean? That DIGEST-MD5 is vulnerable to
> > man-in-the-middle attacks? I didn't think it was.
> I don't have enough experience with Digest Authentication to speak
> to this. Can someone else in the WG please comment?
> > BTW, maybe 'simple anonymous bind' should be 'simple anonymous or
> > unauthenticated bind'.
> > It goes on to say:
> > > 10.1. Start TLS Security Considerations
> > > The use of TLS does not provide or
> > > ensure for confidentiality and/or non-repudiation of the data housed
> > > by an LDAP-based directory server.
> > I don't understand. I thought confidentiality was exactly one of
> > the things TLS was for.
> I think the point is that TLS protects the data in transit between
> client and server, but it can't do anything to protect the data at
> the point it is housed. E.g. if the data is all just in text files
> on the LDAP server's file system with world-readable permissions,
> anyone with access to the server's file system can see the data.
> > --
> > Hallvard