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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

How is the use of an authentication method choice of "sasl"
useful?  Other than saying that some SASL mechanism was
used, it's quite meaningless as to the level of authentication
it implies.

How is the use of an authentication mechanism choice of
"sasl/EXTERNAL" useful?  Other than saying that some lower
level authentication mechanism was used, it's quite
meaningless as to the level of authentication it implies.

And "simple"...  A server can be disallow "simple" when
there is inadequate transport level protection.  Here,
"simple" is "protected" or better.   But we could replicate
an ACI to a server which didn't have this restriction in place.
Here, "simple" is "weak".  An application developer could easily
expect "simple" to imply the implementations only supported
"simple" bind when adequate protections were in place, as
recommended by RFC 2829.  This might be a false expectation.

I do not support inclusion of authentication method/mechanism
based subjects in the ACI specification.  On the other hand,
I do support inclusion of authentication level based subjects
in the ACI specification.

Yes, terms like "weak", "protected", "strong" are somewhat
subjective.  However, I believe it's possible to categorize
existing standard track mechanisms into these (or similar)
categories and to provide guidelines for the categorization
of future, private, or other mechanisms which are not
explicitly categorized.   I am willing to take a stab at
putting an 'authentication level' proposal together.
There are contentious issues to be sorted out... but I
believe the can be sorted out.

As far as the 'expected behavior' argument, I believe folks
are expecting a higher level of interoperability than can
be provided by this specification.  They certainly are
not going to get 'equally capable' ACI implementations
from this (or any) LDAP ACM specification.  I note that
all current subjects in the ACM have implementation specific
behaviors.

Kurt

At 01:41 PM 4/5/01 -0500, Ellen Stokes wrote:
>Kurt,
>
>We actually had this debate a long time ago both within
>the small community working on this draft and also at a
>ldapext meeting.
>
>The smaller group was content to define levels like
>unauthenticated, weak, strong, etc as you suggest.
>Our thinking here was based on a simplification of
>what X.500 defined.
>
>The push back (big time) was what constituted a
>weak authentication level vs a strong authentication level.
>What some folks thought was 'strong', others thought
>was weak, so the view was it would be difficult to get
>consensus and hence expected behavior across vendor
>implementations.
>
>So we decided to (as you would probably say) mix authn
>levels with methods and mechanisms, the result being
>what you see in the spec.  This was consensus.
>
>Has consensus changed? I'd like to hear from others on this
>topic - but I don't want a long drawn out debate because we've
>had that already.
>
>So the question is do we
>(1) use somewhat ambiguous terms as Kurt suggests?
>(2) agree that the set posted to the mailing list last week is sufficient?
>(3) make some small change?
>
>Ellen
>
>
>At 11:21 AM 4/5/2001 -0700, Kurt D. Zeilenga wrote:
>>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.
>>
>>I note that "sasl" and "sasl/external" are quite ambiguous
>>as to the level of authentication provided.
>>
>>Kurt
>>
>>At 05:31 PM 4/5/01 +0200, robert byrne wrote:
>>
>>>Just to try to close this one item, is there anyone who thinks we need
>>>to differentiate in the ACM between, in the terms of Ellen's very last
>>>BNF, "anonymous" and "none" ?
>>>
>>>>    authnLevel = "none" /            ; from X.500:  name but no password,
>>>> same as LDAPBIS unauthenticated
>>>>                        "anonymous" /   ; from LDAP:  no name and no password
>>>
>>>Rick says he doesn't care, Kurt says X.500 says they are the same thing
>>>(from an access control point of view).
>>>They seem pretty similar to me.
>>>
>>>If we do collapse them both then I would suggest "unauthenticated" as a
>>>good name for this kind of authentication level--looks like that's
>>>consistent with ldapbis teminology.
>>>
>>>Rob.
>>>
>>>Sanjay Panwar wrote:
>>>>
>>>> I am also not very clear on the differences and meaning of following
>>>> subject options. My list is little longer that Richard's.
>>>>
>>>> 1. null or no authnLevel  vs  "any"  vs  "none"  vs  "anonymous"
>>>>     (same as the points made in the attached mail)
>>>>
>>>> 2. null or no subject  vs  "public:"  vs  anonymous
>>>>     Is it legal to define a ACI without a subject ? How should it be
>>>> interpreted. How is public different from anonymous or no subject ?
>>>>
>>>> 3. "group:"  vs  "role:"
>>>>     group is defined as the distinguished name of a groupOfNames or
>>>> groupOfUniqueNames entry. role is not defined that clearly. Is it the
>>>> distinguished name of a organizationalRole entry ?
>>>>
>>>> - Panwar
>>>>
>>>> Richard V Huber wrote:
>>>>
>>>> > The more I read Section 4.2.3, the less I understand the difference
>>>> > between "any" as an authnLevel and an omitted authnLevel.
>>>> >
>>>> > There are three statements in 4.2.3 that I am trying to figure out.
>>>> > I'm rephrasing them here:
>>>> >
>>>> >  1. No authnLevel -> no specific type of authentication is required
>>>> >
>>>> >  2. LDAP simple auth with no password is 'anonymous'
>>>> >
>>>> >  3. 'any' -> any mechanism except "no authentication"
>>>> >
>>>> > So here are my questions:
>>>> >
>>>> >  A. Is an omitted authnLevel equivalent to 'any'?
>>>> >
>>>> >  B. Is an omitted authnLevel equivalent to the union of 'any' and
>>>> >     'anonymous'?  [This would be a fairly dangerous situation.]
>>>> >
>>>> >  C. Does an omitted authnLevel mean "anyone bound with a non-null user
>>>> >     ID"?  [This seems just about as dangerous as B.]
>>>> >
>>>> >  D. Is there a difference between a BIND with a non-null user ID and
>>>> >     BIND with a null user ID if the password is null (anonymous and
>>>> >     more anonymous)?  [This is the anonymous vs. unauthenticated issue
>>>> >     discussed at the LDAPBIS session last week.]
>>>> >
>>>> >  E. If so, does 'anonymous' mean "any or no user ID as long as the
>>>> >     password is null"?
>>>> >
>>>> > I think I lean towards YES on A and E, NO on B and C.  I could live
>>>> > with either answer to D, but if it is YES, we need an explicit
>>>> > authnLevel to recognize 'unauthenticated'; it should not be included
>>>> > when the ACI omits the authnLevel.
>>>> >
>>>> > Rick Huber