Subject: [Geopriv] identity section in the common-policy draft

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 10 May 2005 11:54:46 +0200

hi all,

based on the feedback from aki, jonathan and henning i tried to clarify the
identity section in the common-policy draft. below you see a first attempt
to rewrite the section. 

i would like to point out that i removed the <anonymous> element since it
meaning was difficult to understand. instead i replaced it with the
<asserted> element. 
please let me know what you think. i have included a few comments into the
text itself. 

7.1 Identity

The authorization policy framework specified in this document supports the
usage of identities as input to access authorization decision processes.
This document, however, abstracts from the particularities of concrete
authentication mechanisms employed by different using protocols and is
therefore unable to specify explicitly the details of identity relevant
information. Hence, we only assume that an identity has a structure with a
username and a domain part. Documents that enhance the schema defined in
this document should, if possible, describe how a particular using protocol
is able to provide identity information in a meaningful way. 

Such an enhancement needs to map the identity used by the authentication
protocol employed in the using protocol to an identity used in the
authorization policy. It is necessary to clearly define a mapping between
the authenticated identity of the user (and the domain of the user) and the
identities used in the authorization policies. This mapping needs to
consider the large number of possible identities used in various
authentication protocols.

In this document we distinguish between four different properties of
identifiers:

- Authenticated Identities: The WR was authenticated by the PS. The
authenticated identity is used as input to the rule matching procedure. 

- Unauthenticated Identities: The WR was not authenticated by the PS and
thus any identity provided by the WR might be spoofed. 

- Asserted Identities: The WR was not directly authenticated by the PS.
Instead the WR was authenticated by an asserting party that provides an
assurance to the PS about the authentication of the WR. It is assumed that
the PS and the asserting party have some relationship with each other and
that there is a certain degree of trust that the asserting party does not
misbehave (such as lying about a non-existing authentication of the WR and
by making an incorrect assertion). An example of this approach can be found
in  <outbind://25/l%20RFC3325> [8].

- Anonymous Identities: Most using protocols also designate an identifier
that denotes an 'anonymous user'. The WR, as such, is not authenticated by
the PS nor does an assertion exist that provides the PS with information
about the authenticated identity. In order to provide an authorization
decision non-identity based (or trait-based authorization) might be
applicable. This might be accomplished by an assertion provided by a third
party that hides the identity but offers attributes about the WR that are
used as the foundation for an access control decision. Ensuring
authorization for anonymous users is outside the scope of this document. 

The following guidelines apply when performing rule matching (related to the
identity element in the conditions part of a rule):

a) A rule with no conditions matches any subscription irrelevant whether an
authenticated, an unauthenticated or an asserted identity was used by the WR
to access resources. 

b) A rule with an <identity> element assumes that there are either <id> or
<domain> elements as child elements. Unauthenticated identities never match
the values of the <id> element(s) or the <domain> element(s).

b1) OLE_LINK1If the <identity> element contains one or multiple <id>
element(s) then the authenticated identities (as provided by the security
protocol used by the using protocol) MUST be used for an equality match. 

OLE_LINK2b2) If the <identity> element contains the <domain> element
consisting of or more <except> element(s) then the domain part of the
authenticated identity MUST be used for an equality match. This allows
implementing a simple blacklist mechanism. The <except> element contains the
identity without the domain part (i.e., the username part) since it equals
the domain of the <domain> element.  Only authenticated identities MUST be
matched with the username part of the values of the <except> element(s).

c) A rule with an <asserted> element assumes that the WR was authenticated
by an asserting party that is trusted by the PS. Two options are possible: 

c1) If the <asserted> element contains one or multiple <id> element(s) then
the asserted identities  MUST be used for an equality match.

c2) If the <asserted> element contains the <domain> element consisting of or
more <except> element(s) then the domain part of the asserted identity MUST
be used for an equality match. This allows implementing a simple blacklist
mechanism. The <except> element contains the identity without the domain
part (i.e., the username part) since it equals the domain of the <domain>
element.  Only asserted identities MUST be matched with the username part of
the values of the <except> element(s). 

c3) If the identity of the WR is NOT provided to the PS indirectly via the
assertion due to identity protection (for example, because a P-A-ID with the
sip:[email-masked] is attached). Hence, it is not possible to provide
a meaningful authorization decision based on the anonymous identifier. 

[Editor's Note: It would be possible to make some authorization decisions
based on the authenticated identity of the asserting party. This might be
reasonable to have a mechanism to separate different asserted parties since
otherwise the RM has to implicitly trust the parties that the PS trusts (a
form of transitive trust).] 

d) The <any-identity> condition that matches any authenticated and asserted
identity. Unauthenticated identities MUST NOT be used with the
<any-identity> element. The <any-identity> MAY contain one or multiple
<except-domain> elements. 

d1) If the <any-identity> element does not contain child elements then the
rule fires for any authenticated and asserted identity. 

d2) If the <any-identity> element contains one or multiple <except-domain>
element(s) then the domain part of the authenticated or asserted identity
MUST be matched against the values of the <except-domain> element(s).

[Editor's Note: Should we include a <domain> element to indicate that we
want to allow all users from a particular domain to access a certain
resource. This would be a short-cut version of the <identity> / <domain> and
the <asserted> / <domain> element.] 

Regarding string comparison the following rules apply: 

1) The <identity> condition part of the rule matches, if the identity of the
WR matches, based on case sensitive string comparison, the user part of the
<id>, and the domain part of the of the <id>, based on case insensitive
string comparison. 

2) A single <asserted> element MAY contain multiple <id> elements. If
multiple identities are provided in a single rule (within multiple <id>
elements) then the rule matches if at least one of the listed identities in
a rule matches the asserted identity of the WR. 

3) The identity of the WR matches a <domain> (either listed in the
<identity> or the <asserted> element) when the domain part of the identity
matches, based on case insensitive string comparison, the value of the
<domain> element, and the user part matches none of the <except> element
values, based on case sensitive string comparison. Only an equality match
MUST be provided. 

4) Case insensitive string comparison is also used for matching the domain
part of an identity with the value of the <except-domain> child element of
the <any-identity> element.

[Editor's Note: The following code snippets should probably be extended and
moved into the example section.]

Next, we list a few examples. The following example illustrates conditions
based on an identity. 

1) Identity based Authorization: 

For the given example the rule matches if the authenticated identity of the
WR is either [email-masked] or [email-masked]. 

<identity>

<id>[email-masked]</id>

<id>[email-masked]</id>

</identity>

2) Exceptions within the Identity Element:

The next example shows how exceptions are implemented. For the given example
the rule matches if the authenticated identity of the WR is from the
example.com domain but the user identity of the WR is neither
[email-masked], [email-masked] nor [email-masked]. 

<identity>

<domain>example.com</domain>

<except>joe</except>

<except>tony</except>

<except>mike</except>

</identity>

If a WR with the identity [email-masked] requests access to a resource
the above-shown rule is not applied since the case insensitive equality
match between the domain part of the WR identity (namely 'foo.example.com')
does not match the value in the domain part of the rule (namely
'example.com'). 

3) Asserted Identities

The following example shows a rule with an asserted identity.

<asserted>

<id>[email-masked]</id>

</identity>

This rule fires if the WR's identity is asserted by a PS trusted party and
the assertion assures that the WR was authenticated as [email-masked]. 

Conditions with the asserted identity might also indicate <domain> and
<exception> statement similar to the <identity> element. 

4) Any Authenticated and Asserted Identities

The following example matches any authenticated and any asserted identity. 

<any-identity/>

The following rule fires for any authenticated and any asserted identity
except for WR's from the example.com and the foo.com domain.  The rule would
therefore fire for [email-masked] but not for [email-masked]. 

<any-identity>

<expect-domain>example.com</expect-domain >

<expect-domain>foo.com</expect-domain >

</any-identity>

-------

ciao

hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Randall Gellens <[email-masked]>
Date: Sun, 15 May 2005 18:21:59 -0700

I have a few comments and suggestions on this draft.  They are 
in-line in the document, with "RG:" in the left margin.