[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: increasing complexity - draft-ietf-ldapext-acl-model-08.txt
- To: markd <markd@pwd.hp.com>
- Subject: Re: increasing complexity - draft-ietf-ldapext-acl-model-08.txt
- From: "Steinitz, Dominic J" <Dominic.J.Steinitz@BritishAirways.com>
- Date: 06 Jul 2001 15:02:52 Z
- Alternate-recipient: Allowed
- Cc: "Taylor, Martin S" <Martin.S.Taylor@BritishAirways.com>, ietf-ldapext <ietf-ldapext@netscape.com>
- Content-identifier: 049213B45D31C189
- Content-return: Allowed
- Conversion: Allowed
- Disclose-recipients: Prohibited
- Original-encoded-information-types: IA5-Text
- X400-content-type: P2-1988 ( 22 )
- X400-mts-identifier: [/c=gb/admd=attmail/prmd=ba/; 049213B45D31C189-BAWMTA]
- X400-originator: Dominic.J.Steinitz@BritishAirways.com
- X400-received: by mta BAWMTA in /c=gb/admd=attmail/prmd=ba/; Relayed; 06 Jul 2001 15:02:52 Z
- X400-received: by /c=gb/admd=attmail/prmd=ba/; Relayed; 06 Jul 2001 15:02:52 Z
- X400-recipients: non-disclosure;
We prefer authentication method to authentication strength. This allows different organisations to make their own choice about what is acceptable for a particular application.
Why force authentication methods to have strengths relative to each other? For example, I may wish to say that voice authentication is ok for application A, fingerprint for application B, voice and fingerprint for application C and voice or fingerprint for application D.
This is a general security question not one that is just applicable to ldap. Experience has shown us that giving each authentication method a strength is unnecessarily constraining. It is better to leave an organisation to make the decision about which methods are acceptable.
I am not convinced by the deprecated argument. Again, I suggest individual organisations should be left to make a decision about whether a given method is still acceptable for a given application.
Dominic.
markd@pwd.hp.com on 06/07/2001 11:13:00
To: ietf-ldapext
cc:
bcc: Dominic Steinitz
Subject: Re: increasing complexity - draft-ietf-ldapext-acl-model-08.txt
> > - remove authnLevel. Don't add integrity/confidentiality
> > factors.
>
> Having read the draft, either the authnLevel should be
> removed or just auth mechanisms listed. The current proposed
> bucketization of authnLevel is a receipe for interoperability
> nightmares.
>
I disagree that this is an interop nightmare. When an admin
is constructing an ACI using an authnLevel, they are interested
in the probability that an authenticated user is who they claim
to be.
Two systems may allow different mechanisms, but the mechanisms
can be mapped onto the different strengths, so I think it would
aid interop.
The strength level 'buckets' also help when a mechanism is depricated
for some reason (eg Cram-MD5 would not have been categorized as
weak a few years ago), or when a new mechanism is added to the server.
Mark
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com