[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on Access Control Model - authentication levels
I'm copying this to the LDAPBIS list since one of the comments in the
Ellen's new BNF points out something that may be of interest. The
specification of "none" as an authorization level comes from X.501.
The X.501 4th edition draft says (section 18.4.2.3):
For access control purposes, the "simple" authentication level
requires a password; the case of identification only, with no
password supplied, is considered "none".
This is relevant to the discussion we had in Minneapolis concerning
"anonymous" vs. "unauthorized". It seems to give support to the idea
that they are NOT the same thing.
Rick Huber
: From stokes@austin.ibm.com Mon Apr 2 13:08:58 2001
: Return-Path: <stokes@austin.ibm.com>
: X-Sender: stokes@popmail2.austin.ibm.com
: To: rvh@qsun.mt.att.com (Richard V Huber), ietf-ldapext@netscape.com
: From: Ellen Stokes <stokes@austin.ibm.com>
: Subject: Re: Comments on Access Control Model - authentication levels
: Mime-Version: 1.0
:
: There have been many notes on authentication levels. This response
: addresses those notes.
: Below is the BNF. In section 4.2.3 I'll incorporate the following points
: below. In the Security
: Considerations section I'll note that ipAddresses are easily forged (as
: stated in requirement
: S6), but that it is an accepted though non-secure practice. Ranges of
: ipaddress are not
: supported, but wild-carded dns names are for the most-specific part of the
: name.
:
: I've incorporated authentication definitions from LDAP and X.500 as noted
: below.
: Instead of hiding domain and wild-carded domain names with ipAddress, I've
: surface
: them as a subject (see below). Only the left-most (most specific) part of
: the dns
: name can be wild-carded.
: There are 4 authn levels: non, anonymous, simple, and sasl, and 2
: groupings: unauthn and
: authn. If authnLevel is omitted in the access control information,
: authnLevel defaults to 'authn'.
: authnLevel only makes sense to be applied to certain subjects (see below).
: I've omitted(for brevity) in this email the BNF expansion of IPv6address
: (taken from
: RFC 2373) since it did not change.
:
:
: subject = ([ "authnLevel:" authnLevel ":" ]
: ( "authzID-" authzID ) /
: ( "role:" dn ) /
: ( "group:" dn ) /
: ( "subtree:" dn ) /
: "this:" ) /
: ( "ipAddress:" ipAddress ) /
: ( "dns:" [ "*." ] domainname ) /
: "public:"
:
: authnLevel = "none" / ; from X.500: name but no password,
: same as LDAPBIS unauthenticated
: "anonymous" / ; from LDAP: no name and no password
: "simple" / ; from LDAP: name and password
: sasl / ; from LDAP
: "unauthn" / ; groups none + anonymous
: "authn" ; groups simple or sasl, this
: is the default is authnLevel is omitted
:
: sasl = "sasl:"
: ("any" /
: mechanism)
:
: mechanism = ' sasl mechanism from 4.2 of [LDAPv3]
:
: ipAddress = IPv6address
:
: domainname = domaincomponent *( "." domaincomponent )
:
: domaincomponent = ALPHA [ *61( ALPHA / DIGIT / "-" ) ( ALPHA / DIGIT )]
:
:
: Ellen
:
:
:
: At 01:56 PM 3/29/2001 -0500, Richard V Huber wrote:
: >The BNF allows the authentication level to be omitted from ACI. It
: >also allows specification of "none" and "any".
: >
: >Section 4.2.3 explains the difference between omitting the
: >specification and using "any", but it does not explain "none". I
: >suggest "none" be removed from the BNF.
: >
: >Section 4.2.3 also says "For permission to be granted, the subject must
: >have been authenticated to at least the level specified, but that if
: >the right is a deny, then everyone is denied access unless they have
: >been authenticated to at least the level specified in authnLevel."
: >
: >I think we will have a lot of problems trying to agree on a
: >well-ordering of authnLevels. I suggest we remove the parts about "at
: >least the level specified". I also feel the part about "... then
: >everyone is denied access unless ..." is unclear.
: >
: >Can we just say "For permission to be granted, the subject must have
: >been authenticated to the level specified."
: >
: >Rick Huber