Subject: RE: [Geopriv] Some comments for draft-guenther-geopriv-saml-polic y-01

From: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Aug 2005 11:12:33 +1000

Hi Hannes,

Thanks for the concise summation of issues.  In the interest of getting some
progress on the issue, I will present my point of view on these issues.

Your first two points address usability.  From a usability perspective I
think that we need to cater to two distinct sets of users in this case,
apologies if this sounds old.  The first group, by far the largest methinks,
are those who want a buddy list.  These people probably don't care much for
the complexities of SAML or fancy XML, but they can probably cut and paste
entries and change the name quite happily.  XML works for those people
because it's sort-of readable, but only as long as it remains free of
confusing stuff (like URNs and weird security stuff).

The second group of people are those writing applications, from whom we can
expect a greater degree of understanding and also a greater requirement for
functionality.  For those people I can imagine that some extra flexibility
would be useful.

There is no reason why that a location server can't use a SAML assertion
from a "trusted" issuer in place of authenticating a location recipient.
That would work within the base identity framework.

What SAML provides is additional flexibility in implementing policies, which
appeals to me as a member of that second group.  As long as it remains an
option or extension, I don't see how this could adversely affect
authorization policies.  I don't think that these extra features have a
place in common-policy, but as long as a SAML extension remained an
extension, I think that it would be quite valuable.  I don't think that we
need something as complete (and complex) as XACML though.

To address individual points...

a) authentication types

I agree that in terms of addressing a problem, authentication types could be
a little un-friendly to a user constructing a policy.  For that reason, they
might be something that we can remove.  I talked about profiling SAML for
our purposes; I think Henning is proposing taking the next step and going to
a more restricted set of functions.

On the other hand, I can see where authentication types (or strengths) can
help protect against attacks.  I can already see cases where this feature
might be applicable as another line of defense.

b) asserted vs authenticated

Again we are faced with a tradeoff, complexity vs functionality.  My
suggestion here is that a base specification can avoid the complexity and
the extra functionality can be added by a SAML document that defines an
extension.

Simple example to illustrate:
  Base: <user id="[email-masked]"/>
  Extension:
<samlcond><issuer>example.com</issuer><identity><nameid>[email-masked]</nam
eid></identity></samlcond>
  Or more simply: <user id="[email-masked]"
samlextension:issuer="example.com"/>

c) trait based authentication

I'd suggest that the definition of names be needs based and the URN
registered with IANA, for those that actually need to be registered.  I
wouldn't go any further than that from this high level.  Maybe the
"is-a-PSAP" trait could be registered, but that might be out of scope.

d) authorization statements

I'm not sure that I follow your point here.

If you refer to <AuthzDecisionStatement>, then I don't think that this is
applicable in our case - SAML 2.0 has effectively deprecated authorization
DECISION statements.

I can see where a SAML-based policy could be applied, so I'm still strongly
in favour of having SAML extensions defined for common-policy.

Regards,
Martin

p.s. your common-policy draft wasn't there, and the first URL had an extra
'-01.txt'. 

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]] 
Sent: Wednesday, 24 August 2005 5:40 PM
To: Thomson, Martin [WOLL:5500:EXCH]; GEOPRIV
Cc: Guenther, Christian
Subject: AW: [Geopriv] Some comments for
draft-guenther-geopriv-saml-policy-01

hi martin, 

thanks for your review. 
as explained during the geopriv session i think that the document raises
some important questions. let me summarize them here: 

a) quality of authentication 

in the past we said that it does not make sense to have authorization
decisions based on the type of authentication that took place. we looked
among other things at attempts to classify protocols, such as described in
http://sunsite.mff.cuni.cz/MIRRORS/ftp.ripe.net/internet-drafts/draft-zeilen
ga-auth-lvl-02.txt-01.txt. an example: would you like to specify a policy
that says: "if user x was authenticated using public key based
authentication then i allow him access to my location." hence, if he was
authenticated using a password then i do not allow it. 

the argument was that these types of policies are not really user-friendly
(since user typically have no clue about the different types of
authentications) and their technical justification is weak (password
authentication is not necessarily weaker than public key based
authentication since it depends a lot on the environment). 

have we changed our mind with respect to this issue?
we might need to consider that the saml guys are very keen on this
particular aspect. if saml is more widely used then there might be an
interworking aspect here. 

b) asserted identity

in the previous common policy draft (see
http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-05_v3.html)
i added the capability to distinguish between authenticated identity and
asserted identity. i had to remove it because everyone (later) told me that
it is too complex and does not really make sense. 

do we now want to add it as an extension? 

c) authorization based on traits. 

the saml stuff does not really provide any attribute namespaces. everything
that is defined there is a attribute/value pair. 

d) a mostly unexplored area is the relationship between authorization
statements carried inside the saml assertion and in the common / geopriv
policy. 
in some sense this, sort of, relates to what i proposed a long time ago (see
http://www.tschofenig.priv.at/drafts/draft-tschofenig-geopriv-authz-policies-00.
txt) 

i think we need to discuss these issues case-by-case. 

ciao
hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Aug 2005 21:35:33 -0400

This is a general statement, but seems somewhat pertinent in this 
thread. There is a grave danger, I believe, in reaching too far from 
current deployment and implementation experience. We have almost none of 
either, for any of the common policy or geopriv policy work. The dangers 
are three-fold:

- they make the overall technology more confusing to outside 
implementors and raise the bar to entry, thus delaying interoperability 
and deployment;

- they increase the cost of deployment, as it offers more configuration 
options to consider and more user training;

- they may well encourage the use of much more restrictive, but more 
readily scoped, technology.

While one could argue that nobody has to implement these extended rules, 
the nature of the policy rules under our common policy framework is such 
that you can't match on them if you don't understand a condition part, 
so that this essentially means having to support two sets of rules 
(complex and simple [non-SAML]).

I also cannot see all but the most technically adept users editing XML 
directly. Thus, implementors have to build user interfaces that allow to 
express the full complexity of policy rules, as otherwise a user 
interface would not be able to read and then re-create the original 
rule, with user modifications.

Thus, I would recommend that we are very conservative in venturing into 
elaborate policy languages. The history of policy-related efforts, in 
terms of their implementation and usability, has not been a happy one. 
The "it could be useful to somebody" approach that one might safely 
advocate elsewhere unfortunately does not apply here. Unlike more 
naturally constrained areas of standardization, policy languages are 
almost indefinitely expandable, given that most of us have no problem 
coming up with an ever-expanding range of plausible policies that 
somebody might need to express.

Therefore, I advocate that we delay consideration of more elaborate 
policies until there is demonstrable customer demand and deployment 
experience with the simpler system, that we have yet to finish, 
implement and test.

 From a discussion perspective, this draft does not seem specific to 
GEOPRIV as such, as one might reasonably need to consider its 
application to, say, SIMPLE in particular.

Henning

Martin Thomson wrote:
> Hi Hannes,
> 
> Thanks for the concise summation of issues.  In the interest of getting 
> some progress on the issue, I will present my point of view on these issues.
> 
> apologies if this sounds old.  The first group, by far the largest 
> methinks, are those who want a buddy list.  These people probably don't 
> care much for the complexities of SAML or fancy XML, but they can 
> probably cut and paste entries and change the name quite happily.  XML 
> works for those people because it's sort-of readable, but only as long 
> as it remains free of confusing stuff (like URNs and weird security stuff).
> 
> The second group of people are those writing applications, from whom we 
> can expect a greater degree of understanding and also a greater 
> requirement for functionality.  For those people I can imagine that some 
> extra flexibility would be useful.
> 
> from a "trusted" issuer in place of authenticating a location 
> recipient.  That would work within the base identity framework.
> 
> What SAML provides is additional flexibility in implementing policies, 
> which appeals to me as a member of that second group.  As long as it 
> remains an option or extension, I don't see how this could adversely 
> affect authorization policies.  I don't think that these extra features 
> have a place in common-policy, but as long as a SAML extension remained 
> an extension, I think that it would be quite valuable.  I don't think 
> that we need something as complete (and complex) as XACML though.
> 
> 
> I agree that in terms of addressing a problem, authentication types 
> could be a little un-friendly to a user constructing a policy.  For that 
> reason, they might be something that we can remove.  I talked about 
> profiling SAML for our purposes; I think Henning is proposing taking the 
> next step and going to a more restricted set of functions.
> 
> On the other hand, I can see where authentication types (or strengths) 
> can help protect against attacks.  I can already see cases where this 
> feature might be applicable as another line of defense.
> 
> suggestion here is that a base specification can avoid the complexity 
> and the extra functionality can be added by a SAML document that defines 
> an extension.
> 
> <samlcond><issuer>example.com</issuer><identity><nameid>[email-masked]</nameid></identity></samlcond> 
> 
> If you refer to <AuthzDecisionStatement>, then I don't think that this 
> is applicable in our case - SAML 2.0 has effectively deprecated 
> authorization DECISION statements.
> 
> 
> I can see where a SAML-based policy could be applied, so I'm still 
> strongly in favour of having SAML extensions defined for common-policy.
> 
> Regards,
> Martin
> 
> p.s. your common-policy draft wasn't there, and the first URL had an 
> extra '-01.txt'.
> 
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.ripe.net/internet-drafts/draft-zeilenga-auth-lvl-02.txt-01.txt. 
> an example: would you like to specify a policy that says: "if user x was 
> authenticated using public key based authentication then i allow him 
> access to my location." hence, if he was authenticated using a password 
> then i do not allow it.
> 
> the argument was that these types of policies are not really 
> user-friendly (since user typically have no clue about the different 
> types of authentications) and their technical justification is weak 
> (password authentication is not necessarily weaker than public key based 
> asserted identity. i had to remove it because everyone (later) told me 
> that it is too complex and does not really make sense.
> 
> the saml stuff does not really provide any attribute namespaces. 
> everything that is defined there is a attribute/value pair.
> 
> http://www.tschofenig.priv.at/drafts/draft-tschofenig-geopriv-authz-policies-00.txt) 
> 
> 
> ------------------------------------------------------------------------
>