[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: authentication levels in the ACM
- To: "robert.byrne" <robert.byrne@Sun.COM>
- Subject: Re: authentication levels in the ACM
- From: "Steinitz, Dominic J" <Dominic.J.Steinitz@BritishAirways.com>
- Date: 15 Jul 2001 23:03:54 Z
- Alternate-recipient: Allowed
- Cc: "Taylor, Martin S" <Martin.S.Taylor@BritishAirways.com>, ietf-ldapext <ietf-ldapext@netscape.com>
- Content-identifier: 01BA23B52215A006
- 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/; 01BA23B52215A006-BAWMTA]
- X400-originator: Dominic.J.Steinitz@BritishAirways.com
- X400-received: by mta BAWMTA in /c=gb/admd=attmail/prmd=ba/; Relayed; 15 Jul 2001 23:03:54 Z
- X400-received: by /c=gb/admd=attmail/prmd=ba/; Relayed; 15 Jul 2001 23:03:54 Z
- X400-recipients: non-disclosure;
Our view is definitely for option 2 as this leaves organisations free to choose what they consider strong enough for a given application. Methods are not necessarily a totally ordered set. Option 3 forces you to compare methods for strength which will vary depending on your view on threats, vulnerabilities and business impact.
Dominic.
robert.byrne@Sun.COM on 13/07/2001 15:53:00
To: ietf-ldapext
cc:
bcc: Dominic Steinitz
Subject: authentication levels in the ACM
Folks,
The issue of authentication levels versus mechanisms has come up again.
The history on this is that the model started with levels, went to
mechanisms and now has moved back to levels.
To help us try to reach concensus on this, here are three options and I
try to list some pros and cos of each of the options.
1. Remove reference to authentication levels and mechanisms.
This way, the model would not be capable of exressing anything
concerning the authentication method or strength of a user. The policy
of authentication requirements on users would be external to the model.
Pro:
1. simplifies the ACM
Con:
1. authentication is a basic notion for authorization and so it's
natural to want to express it in the ACM.
--
2. Go back to a list of mechanisms with no "strength ordering" among
the mechanisms.
This way an aci subject would have to specify a list authentication
mechanisms. There would be special keywords "none" and "authenticated"
to mean "no authentication" and "some kind of authentication".
Pro:
1. can force a given authzID to use a given mechanism.
Con:
1. As no ordering is defined on mechanisms, the model cannot
automatically give you behaviour you might expect: eg. if an aci
authorizes me when I bind with DIGEST-MD5, I might be surprised to find
that when I bound using SSL that it did not grant me that right. The
implication is that at grant aci create time the admin needs to list
_all_ the mecahanisms he wishes to grant rights. For deny, he needs to
consider the possibility of the subject of his deny coming in using a
different, "less strong", authentication mechanism with a potentially
different authorizationId.
--
3. Stick with authentication levels and a "strength hierarchy"
Pro:
1. The model can make use of the "strength hierarchy" in defining
ACI semantics (e.g. a deny applies to ALL subjects at lower
authnLevel).
2. Once the mechanisms are put in the buckets, the admin of acis is
easier--just choose beteen the four levels rather than lots of
mechanisms.
Con:
1. Assignment of mechanisms to levels is on a per-server basis, but
we could define a way for servers to advertise their assignments
(for example to help with replication).
2. No way to associate a particular user with a particular mechanism.
Cast your vote now! Otherwise we will default to 3, which is the
current flavour.
Rob.
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com