Re: authentication levels in the ACM

[Ryan Moats <rmoats@lemurnetworks.net>]

Doh!  Lets try a mailing list response (sigh)

Given the current state of #3, I'd prefer either 1 or 2.

Ryan

On Fri, Jul 13, 2001 at 04:50:48PM +0200, robert byrne wrote:
| 
| 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.
|