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

RE: mapping identities RE: Compromise Authentication Proposal



I didn't mean my list of possible ways the LDAP server could deal with a
non-DN username to be exhaustive. And, assuming I understand you correctly,
I agree that ACLs want to present themselves with the names that users user
to login and authenticate with, not the name used by the system to locate
their record in an account database (if they are different). 

> -----Original Message-----
> From: Christopher Oliva [mailto:Chris.Oliva@entrust.com]
> Sent: Wednesday, October 07, 1998 4:24 PM
> To: Paul Leach
> Cc: 'ietf-ldapext@netscape.com'
> Subject: mapping identities RE: Compromise Authentication Proposal
> 
> 
> 
> 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.