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>joe@example.com</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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 26 Aug 2004 12:40:27 +0300
This archive was generated by hypermail 2.1.8 : Thu Aug 26 2004 - 10:46:42 EDT