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

From: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Aug 2005 14:28:31 +1000

Hi Henning,

You are correct in directing discussion to this level - we need to limit the
scope of this exercise to reduce the risk of blowout.  I also agree that
this is verging on out of scope for GEOPRIV and it is exactly the kinds of
impacts on other areas where we have to be quite careful.  Obviously we
should be sensitive to requirements from SIMPLE (for instance), while not
letting that weigh down any solution with any of those dangers you mention.

I'd prefer to get "it is useful to us" statements instead of "it could be
useful to somebody", certainly.

I would, however, like to put some of your statements into perspective.
Being too conservative in this case could constrain the technology to the
point where people simply go elsewhere.  Like much in this trade, it becomes
a tradeoff.

SAML rules provide extra functionality, more likely allowing extra people
access to your data.  Using an extension places a responsibility on the
creator of those rules to understand the limitations of the system where
these are to be deployed; and also that these rules would not operate if the
system did not understand those rules.  It is my belief that this
understanding may be easily obtainable in a large number of cases.

For instance, an application provider may obtain access to their client's
location information by providing a rule that may be inserted into their
ruleset.  There is a responsibility on the application provider to determine
that the ruleset works.  Identifying a client's location server may be
enough in this case.

Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, 25 August 2005 11:36 AM
To: Thomson, Martin [WOLL:5500:EXCH]
Cc: Tschofenig, Hannes; Guenther, Christian; GEOPRIV
Subject: Re: [Geopriv] Some comments for draft-guenther-geopriv-saml-polic
y-01

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.
> 
> 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

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