Subject: [Geopriv] revised identity text

From: Tschofenig Hannes <[email-masked]>
Date: Sun, 15 May 2005 21:36:03 +0200

hi all,

based on the comments received by christian guenther i have modified the
recently submitted identity text of the common-policy document. further
enhancements and clarifications are necessary. this issue will be discussed
during the geopriv/ecrit interim meeting:

OLE_LINK37.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 one 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) then a meaningful authorization
decision is not possible.  

[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 <id> elements of 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. The values of a <domain>
element MUST be matched with the domain part of the provided identity using
an equality match. No wildcarding is 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: Aki Niemi <[email-masked]>
Date: Wed, 18 May 2005 16:38:41 +0300

Hi All,

Hannes asked me to summarize an issue that was sent to the SIMPLE WG 
about common-policy. This is an issue in the context of manipulating 
common-policy rules using XCAP.

The problem is that XCAP only allows selection (and therefore addition, 
removal and modification) of nodes based on element name, attribute and 
position. It doesn't support selection based on element content. 
Therefore selecting <id> elements within the <identity> seems 
unnecessarily hard, since the rule maker always needs an up-to-date copy 
of the <identity> element to find out the position of the correct <id> 
to be selected.

To fix this, there has been a proposal to tweak the <id> element such 
that instead of:

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

it becomes:

<id value="[email-masked]" />

Selecting this element is much easier in XCAP simply using the attribute 
value as the node selector, and also seems like a minor change to 
common-policy schema.

Cheers,
Aki

ext Tschofenig Hannes wrote:
> enhancements and clarifications are necessary. this issue will be 
> discussed during the geopriv/ecrit interim meeting:
> 
>  
> 
> *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.
> 
> 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.
> 
> 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 [8] <outbind://25/l%20RFC3325>.
> 
> - 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) If 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.
> 
> b2) If the <identity> element contains the <domain> element consisting 
> of one or more <except> element(s) then the domain part of the 
> 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 
> 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) then a meaningful 
> authorization decision is not possible. 
> 
> [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 
> 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).
> 
> resource. This would be a short-cut version of the <identity> / <domain> 
> and the <asserted> / <domain> element.]
> 
> 1) The <id> elements of 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.
> 
> elements) then the rule matches if at least one of the listed identities 
> in a rule matches the asserted identity of the WR.
> 
> <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. The values of 
> a <domain> element MUST be matched with the domain part of 
> the provided identity using an equality match. No wildcarding is 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.
> 
>  
> 
> For the given example the rule matches if the authenticated identity of 
> the WR is either [email-masked] or [email-masked].
> 
> <identity>
> 
> 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 
> 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
> 
>  
> 
> 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].
> 
>  
> 
> 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>
> 
> ------------------------------------------------------------------------
>