Subject: subjects in LDAP ACMs

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Apr 2001 19:15:07 -0700

I note that the LDAP ACI syntax only allows a single
subject per value though it is likely quite desirable
to treat certain kinds of subjects as orthogonal factors
in the ACM.  For example, it might be useful to say
"authzId X via Y method gets Z permission".

However, adding additional, independent factors to
the ACM adds to the complexity of specification so
we must tread lightly.

My first suggestion would be remove subjects based
upon orthogonal factors from the ACM, then to discuss
support for orthogonal factors such as authnLevel.

I suggest Subjects be based solely upon presence, absence,
or value of the authorization identity.  Hence, I suggest
(provided in suggested precedence order):

  subject = this          ; self
  subject /= "authzID-" authzID)
  subject /= ("role:" dn)
  subject /= ("group:" dn)
  subject /= ("subtree:" dn)
  subject /= authorized   ; authenticated and authorized
  subject /= anonymous    ; unauthenticated
  subject /= public       ; any user

Kurt

---

From: robert byrne <[email-masked]>
Date: Thu, 12 Apr 2001 17:15:22 +0200

Kurt,

Conceptually it's certainly helpful to seperate the authzid type
subjects from factors like authnLevel, ipaddress/dns name etc.  However,
in so far as a factor is typically an extra refinement on authzID's (eg.
grant the access if it's cn=rob,o=sun.com AND he's authenticated using
SASL-DIGEST-MD5) I think factors are still very "subjecty" things.  Is
the trend of your thought to move factors into a say "factor" keyword
and then require that the subject AND factor keywords are satisfied ?

What do you mean by "authorized" below ?

BTW, do you think it would be interesting to allow boolean combinations
of subjects in the same aci ?

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 12 Apr 2001 11:14:34 -0700

>and then require that the subject AND factor keywords are satisfied ?

No.  My thought is to come up with an extensible set of orthogonal
factors which then are expressed in the syntax as such.  What
authorization identity some user has independent of the mechanism
used to authenticate the user.  What host that user appears to
on is orthogonal to the mechanism used.

>What do you mean by "authorized" below ?

Meaning that the user was "authorized" to assume an identity.
That is, the user has been authenticated and some authorization
identity has been associated with the session (this might be
an authorization identity derived from the user's authentication
identity or another authorization identity which the user is
allowed to assert).

>of subjects in the same aci ?

Interesting, yes, but too complex.  I suggest that factors be
AND'ed together and or's created by multiple values.  We use
this logic in our ACM, it's simple and effective.

---

From: robert byrne <[email-masked]>
Date: Mon, 23 Apr 2001 16:54:48 +0200

Kurt,

Your list of proposed non-factor subjects seems fine to me and I take
your point that you may want to specify a factor or factors as well as
any one of these subjects.

If we jiggle the current BNF in 4.1.1 a bit in order to group the
factors together (authnLevel, ipaddress and dns) and add your
"authorized" and "anonymous" labels then I think it does give something
that's better structured:

subject =               [factor] simpleSubject       
            		
simpleSubject = 	( "authzID-" authzID ) /
                         ( "role:" dn ) /
                         ( "group:" dn ) /
                         ( "subtree:" dn ) /
                       "this:" /
			"public:" /
			"authorized:" / ; authenticated and authorized
			"anonymous:"	; unauthenticated
	
factor = [ "authnLevel:" authnLevel ":" ]
	[ "ipAddress:" ipAddress ]
        [ "dns:" [ "*." ] domainname ) ]

I think using "authorized" is confusing as it's often used to refer to
the end result of access control the user is authorized to do the
LDAP operation.  How about rather "identified" ?

As for making the factors extensible...that sounds fine but it might be
more pragmatic to focus on the factors we have already identified
(authnLevel, ipaddress/dns names) to try to get agreement on how to
handle those.

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 23 Apr 2001 12:32:40 -0700

It's my personal opinion that ACMs should be based upon
authorization identities and that controls based upon
other factors (authentication method (or level), IP
address, DNS name, etc) should be left to other administrative
mechanisms (such as those upon within the authentication
subsystem and those external to LDAP (topology enforcement
systems)).

The primary reason is simplicity.  While an extensible
ACM which supports multiple orthogonal access control factors
would be more flexible, it is also quite complex (to design,
implement, and use).

Hence, I think we should do as RFC 2820 suggests [with clarification]:
   U1.  When in doubt, simpler is better, both at the interface and in
   the implementation.

   U2.  Subjects MUST be drawn from the "natural" LDAP namespace; they
   should be DNs [or RFC2829 authzIds].

The suggested "non-factor subjects" are not drawn from the "natural"
LDAP name space.  They add unnecessary complexity to the interface
and its implementations.

Kurt

---

From: robert byrne <[email-masked]>
Date: Tue, 24 Apr 2001 17:39:47 +0200

Kurt,

I would say that those policy things that belong in the authentication
subsystem are those things which are likely to be required to be a
function of the authorization id only.  For example, policy like "three
consecutive failed binds by the same requestor then lock the account" or
"time of day restriction on class X of users".  Policy which is likely
to be required to be a function of dn, attribute and permissions
naturally belongs in the ACM.  I think the factors we have identified
are in this class.  For example, there may be particular sensitive
subtrees, entries and attributes the modification of which requires
strong authentication.

Anyone else care to cast a vote for or against factors in the ACM--to
recall they currently look something like this:

Finally what we are discussing here are "factors" not "subjects" and so
I don't think they are ruled out by U2.

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Apr 2001 13:29:07 -0700

At 08:39 AM 4/24/01, robert byrne wrote:
>function of the authorization id only.

No.  The authentication subsystem is a function of credentials
and other information which results in the establishment of an
authorization identity.  This authorization identity is then
granted access to information by the ACM. While the ACM could
base access upon information by other factors, such as which
mechanism was used and/or the presence of security layers, there
are numerous security considerations the user must be made aware
of.

I see a few major considerations.  In particular, an attack upon
a weak mechanism could be used to gain access requiring strong
authentication.  That is, a password exposed by use of simple bind
could be used to gain access via DIGEST-MD5.

I also note that the ACM does nothing to prevent a client to
prevent a client from exposing data to attackers.  It only prevents
the server from exposing data.  Policy meant to protect the
exposure of sensitive information must encompass the client as
well.  While the authentication/authorization system cannot prevent
clients which access the directory anonymously from exposing such
information, the authentication/authorization can and SHOULD
prevent authorized clients from accessing the directory (as a whole)
without appropriate authorization.

>I don't think they are ruled out by U2.

Authorization identities are one type of factors.  There are
numerous types of factors which could be used to make access
control decisions.  I believe RFC 2820 and this I-D uses the
term subject to refer to any kind of factor derived from or
provided from the client's LDAP association.
  "Security subject - An entity in an active role to which a
  security policy applies." [RFC2820]

  "This policy data describes security-relevant characteristics
  of the requesting subject and the rules which govern the use
  of the target object." [I-D]

I assume U2 applies not only to authorization identities but
all factors associated with the subject.  All of the factors
you suggest relate directly to the entity which the security
policy applies and hence are "subject factors" or "subjects".

Kurt

---

From: robert byrne <[email-masked]>
Date: Wed, 25 Apr 2001 15:00:07 +0200

> could be used to gain access via DIGEST-MD5.

This is certainly a deployment consideration.  At the same time the
point is somehow trivial--in security terms, all bets are off for a
client who exposes his authentication credentials.

> policy applies and hence are "subject factors" or "subjects".

The only explicit reference to these "things" I can find in 2820
actually refers to them as the "Access context" and doesn't have
anything else to say about them:

   "Access context - The context, in terms of such variables as
location,
   time of day, level of security of the underlying associations, etc.,
   in which an access to a security object is made."

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Apr 2001 08:29:01 -0700

>anything else to say about them:

As I noted previously, RFC 2820's use of the terminology is a bit
inexact.  However, I believe the intent of the stated requirements is
clear enough.  I won't hair split over them.

I just reiterate my basic position:

Support for multiple orthogonal subject factors is a rat hole
  (consider precedence and "effective rights" issues).

Support for a single subject factor which includes elements
  not drawn from the "natural" LDAP name space has limited use
  subject to significant security considerations.

The need for non-"natural" subject factors could be addressed
via other means.

For these and other reasons, I believe it best for the LDAP ACM
not support multiple orthogonal subject factors nor support
a single subject factor which includes factors not drawn from
the "natural" LDAP name space.

Lastly, I believe we need to keep the LDAP ACM simple.  Not
just for security ask, but for sake of timely completion of this
work.

Kurt

---

From: robert byrne <[email-masked]>
Date: Thu, 26 Apr 2001 14:07:08 +0200

>   (consider precedence and "effective rights" issues).

If factors complicate or clash with other parts of the model then that
could be grounds for dropping them from the model.  I wouldn't
anticipate a problem for precedence--I think you could define away any
problems there.  The impact on getEffective rights is more serious--I'm
planning to have a look at getEffectiveRights...

Rob.