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

Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2)



Just to add fuel to the fire,

>I think we need to decide first whether we are distinguishing
>authentication methods (none, simple, sasl), authentication
>mechanisms (none, simple/anonymous, simple/unauthenticated,
>simple/authenticated,sasl/digest-md5,sasl/external) or
>authentication levels?

>"simple" and "sasl" are not authentication levels, but
>authentication methods.  Each has multiple mechanisms.
>Each mechanism offers different level of authentication
>which may depend on other factors (such as transport
>layer security).

>I see little value in supporting authentication methods
>in the ACM, however an argument could be made for specific
>authentication mechanisms.

>Personally, I see much more value in adding authentication
>level support. I think one can define simple levels like:
>"unauthenticated", "weak", "protected", "strong" in a
>useful and a fairly unambiguous manner.

Frankly I really don't know what "authentication level" means.
It *might* mean something like "strength of authentication mechanism",
though of course we don't really know how strong they are until
they get broken.

Another possibility, and one I hear frequently from customers,
might be called "authentication mechanism types" -- that is

     none
     shared secret over unprotected session
     shared secret over protected session
     token
     cryptographic smartcard
     biometric

Customers often want to base policies on which (or which combinations)
of these is used.

In general authentication based on either strength or mechanism of
authentication is
a frequently encountered requirement but can be very complicated to
implement depending
on the level of assurance required and the customer's specific policy.

--bob

Bob Blakley
Chief Scientist
Enterprise Solutions Unit
Tivoli Systems, Inc. (an IBM Company)