mapping identities RE: Compromise Authentication Proposal

[Christopher Oliva <Chris.Oliva@entrust.com>]

There is another solution which may be simpler. That is to allow the
access control configurations to specify the alternate identity instead
of a DN. This way the access controls apply to the authenticated
identity instead of an entry DN. In the case of TLS strong
authentication, the identity in the access control settings could be
specified as the subjectAltName of the certificate instead of the DN.
This solution may also prevent security loopholes in mapping mechanisms
(security mechanisms for mapping schemes must be as strong as the
security mechanism for the authentication. For TLS strong, this means
based on digital signatures). Another advantage to this is that there is
no requirement for the bound entity to be represented by an entry in the
directory.

The security protecting the access control settings themselves must
require the highest level of authentication supported by that directory
(or atleast the highest level mandated in that access control element). 

Chris.

> ----------
> From: 	Paul Leach[SMTP:paulle@MICROSOFT.com]
> Sent: 	Wednesday, October 07, 1998 3:22 PM
> To: 	'Hallvard B Furuseth'
> Cc: 	mcs@netscape.com; chris.newman@innosoft.com;
> ietf-ldapext@netscape.com; ietf-sasl@imc.org
> Subject: 	RE: Compromise Authentication Proposal
> 
> The LDAP server can do one of several things for usernames that aren't
> DNs.
> 
> 1. It can lookup the username in an authentication database that is
> NOT the
> directory itself. This is not the most natural thing for a directory
> service
> to do, but for lots of other services they don't have an obvious
> database --
> mail protocols for example.
> 
> 2. It can do a search for some attribute of the user's entry whose
> value is
> the username. The "uid" attribute (e-mail address, IIRC) is one such
> choice,
> and would integrate quite well with all of the mail protocols (at
> least).
> 
> 3. It can hand control of the whole authentication exhange to the
> authentication system on the machine it is running on. Part of the
> philosophy of the SASL approach is that one can use implementations of
> SASL
> mechanisms across many application protocols.
> 
> > -----Original Message-----
> > From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
> > Sent: Wednesday, October 07, 1998 11:48 AM
> > To: Paul Leach
> > Cc: mcs@netscape.com; chris.newman@innosoft.com;
> > ietf-ldapext@netscape.com; ietf-sasl@imc.org
> > Subject: RE: Compromise Authentication Proposal
> > 
> > 
> > I've missed something: What can the LDAP server *do* with the 
> > usernames
> > we bind as?  It's simple enough if the username is a DN, of course.
> > But if I bind as "hbf", may the server translate that to a DN - e.g.
> > with a local subtree search for (&(uid=hbf)(objectclass=person))?
> > May it bind as user user "hbf" which does not correspond to a DN, in
> a
> > private user file?
> > 
> > -- 
> > Hallvard
> > 
>