Subject: Re: [Geopriv] Common policy and any-except

From: Aki Niemi <[email-masked]>
Date: Tue, 14 Dec 2004 16:55:43 +0200

All,

I never got any reply to this, so I'm wondering if it was included in 
the WGLC commenting round, and if not, is it planned to be included or 
addressed?

As an aside: in the last SIMPLE meeting, there was some discussion about 
needing an "any-except" construct for the identity condition. 
Practically speaking, I'd like to see this thing end up in the base 
common-policy specification rather than have each of the work utilizing 
common-policy invent something by themselves.

Cheers,
Aki

ext Aki Niemi wrote:
> All,
> 
> This issue was briefly discussed in San Diego, but I don't think there
> was an agreement yet. It's about allowing a new identity match for
> common-policy rules, namely one that matches all (authenticated)
> identities, explicitly allowing exceptions to it:
> 
> <rule id="lkhdlk">
>    <conditions>
>       <identity>
>          <any/>
>          <except>[email-masked]</except>
>       </identity>
>    </conditions>
> </rule>
> 
> The argument against this construct seems to be that you can achieve the
> same using the already existing <domain> element. Additionally, <domain>
> seems to be favored because of claims of it being more privacy-safe.
> I.e., while the any-except construct could be circumvented by an
> attacker simply by minting an identity even within the same domain, a
> domain-except forces the attacker to at least move over to another
> domain.
> 
> The major problem with domain-except is that it makes policies like
> "require confirmation for all authenticated identities" extremely
> difficult (this policy is equivalent to the reactive authorization model
> for presence, and also has applications in conferencing). In order for
> such a policy to be represented in common-policy rules, it would require
> the rule maker to enumerate all possible domains in the world, and list
> them in its ruleset. This doesn't seem at all feasible. Exception to
> this "match-any" condition would naturally be needed because some
> identities might need to be blocked while others are allowed upon the
> confirmation (reactive authorization). 
> 
> I also have doubts that the domain-except is any more privacy-safe than
> any-except would be. In any-except, minting an identity is actually not
> enough to circumvent the block rule - the attacker would also need to
> establish valid credentials for that identity, since the matching would
> still be for any *authenticated* identity. While identities are fairly
> simple to mint, credentials aren't (depending of course how
> authentication is done). 
> 
> Of course the counter-argument is that some domains require very little
> effort in order to create new identities and/or credentials while others
> are much more difficult in that respect. However, that is also
> problematic, since in order to be able to discriminate against these
> "weak" domains, using the existing domain-except constructs in common
> policy, the rule maker (often the end user) would need to be presented
> with the whole concept of domains, and also would need to understand and
> evaluate the characteristics of a particular domain. This is a
> non-trivial task, and I'm afraid it is not reasonable to assume an
> average user has the ability to do such a thing properly. 
> 
> Also, if authentication of identities is based on some form of trust
> between service providers, then the service provider most likely is
> already blocking access from domains it doesn't trust. At least any
> identity match would fail since the requests don't contain an
> authenticated identity. The end result is the same, except users aren't
> bothered with a concept they likely won't understand or know how to use.
> 
> In conclusion, I see a lot of benefits in introducing the any-except
> construct to common-policy, while the drawbacks seem not that
> overwhelming compared to the existing domain-except. In fact, the
> domain-except construct has some problems in the intended usage of
> domain selection.
> 
> Thoughts?
> 
> Cheers,
> Aki
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Dec 2004 22:03:25 -0500

Aki,

Thanks for reviving this topic. I'd made a concrete proposal to the 
SIMPLE mailing list on Fri, 12 Nov 2004 22:34:26 -0500. The IETF web 
archives seem to be broken, but see
ftp://ftp.ietf.org/ietf-mail-archive/simple/2004-11.mail

Neither email seems to have caused any discussion, despite the interest 
at the SIMPLE meeting in this particular topic.

This seems similar to your proposal, with slightly different syntax.

Excerpt below:

--- begin quote ----

To address the other issue raised in the SIMPLE WG session discussion
earlier this week: One possible proposal, instead of an authenticated
flag, is to allow a wildcard character in the <id> element, as in

<id>*</id>

which matches any *authenticated* identity (whether the rules have
access to the name or not). This would allow to express the desired
behavior of querying for subscription permission. Non-authenticated
names would not match such <id>-tagged rules, but could be matched by
leaving out the <identity> match altogether, as before. I believe this
also allows us to get rid of the not-very-well-defined case of anonymous.

We could add a 'do not match these' clause to rules, i.e., a condition
on identity that causes the rule *not* to match. A fictitious example
that extends the existing domain-level match (<domain> + <except>):

<identity>
    <id>*</id>
    <except>[email-masked]</except>
    <except>[email-masked]</except>
</identity>

The disadvantage is that this does add more failure cases, albeit
harmless ones, such as

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

Here, the <except> is meaningless since it would never match to begin with.

As I mentioned above, this only allows true blacklisting if the <except>
is included in all "*" rules.

--- end quote ---

If there is no objection, I'd be happy to include this in the draft.

---

From: Aki Niemi <[email-masked]>
Date: Thu, 23 Dec 2004 13:49:56 +0200

Hi Henning,

Indeed the proposal you made on the SIMPLE list is approximately what I 
was looking for. So works for me at least.

Cheers,
Aki