Re: Authentication Levels for ACMs

[robert byrne <robert.byrne@Sun.COM>]

Kurt,

I quite like this approach.

First, as you say it's easier to understand and goes to the heart of
what authentication is about, namely, how strong is my belief that this
requestor is who he claims to be.

In addition, without an ordering on authentication mechanisms you are
obliged to manage the the authnlevel keyword in a "pointlike" way.  In
other words, an aci that granted rights to subjects with an authnlevel
of "sasl: digest-md5", for example, would not automatically grant rights
to requestors authenticated with stronger technologies like, say ssl,
when in fact that would seem to be the right thing.  I suspect that as
the number of authentication methods supported by your implementation
grows, the more important it would become to be able to take advantage
of this kind of relation between mechanisms.

The disadvantage, mitigated by your recommendation proposal, is that the
ordering is somewhat arbitrary.  I think we need to help further by
advertising the mechanisms which belong to the different categories
somewhere--say in the same place where we advertise the suppported
accessControlSchemes in the naming context.  I think this would be
important for replication where one server might well wish to verify
consistency of categories with another server before concluding a
replication agreement.

I would like to see your recommended categorisation.  Is your plan that
this would be a seperate document ?

Rob.

"Kurt D. Zeilenga" wrote:
> 
> Here is how I suggest authentication levels be described:
> 
> LDAP supports numerous authentication methods and which offer
> a wide range of security protections.  Some methods support
> multiple mechanisms.
> 
> The strength of each mechanism can depend on many variables.
> While it is possible to develop an access control factor which
> is a parameterization of the methods, mechanisms, and other
> variables; practical use of such a factor would be limited.
> 
> The average directory administrator (or user) has no clue as
> to what strength (or level) of authentication of a
> parameterazation like: 'SASL/EXTERNAL/TLS/GSSAPI' or
> 'SIMPLE/TLS/X.509' implied.  The average directory administrator
> (and user) can understand simple terms like "weak" and "strong".
> 
> It is possible to define a small set of terms in a general
> manner allowing for uses of particular mechanisms to be
> categorized.
> 
> The following authentication levels (in increasing order
> of strength) "unauthenticated", "weak", "limited", and "strong"
> based using terminology defined in [RFC 2828].
> 
> The "unauthenticated" level implies an anonymous authentication
> association.
> 
> The "weak" level implies that the authentication mechanism
> is prone to both passive and active attacks.
> 
> The "limited" level implies that the authentication is
> protects against passive attacks but may be prone to
> active attacks.
> 
> The "strong" level implies the authentication mechanism
> protects against both passive and active attacks.
> 
> A RECOMMENDED categorization is offered separately.  For
> each mechanism categorized in the recommendation,
> implementations SHOULD NOT assign a higher authentication
> level but MAY assign a lower authentication level.  For
> mechanisms not covered by the recommendation, the implementation
> SHOULD a conservative level.  Implementations SHOULD provide
> a means for the directory administrator for disabling mechanisms
> and/or lowering the authentication level associated with a
> mechanism.
> 
> ----
> 
> I would be willing to provide the RECOMMENDED categorization
> if the consensus of this WG is to pursue this.
> 
> Kurt