Subject: AW: [Geopriv] Some comments for draft-guenther-geopriv-saml-policy-01

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 24 Aug 2005 09:40:15 +0200

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

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Martin Thomson
Gesendet: Mittwoch, 24. August 2005 07:51
An: GEOPRIV
Cc: Guenther, Christian
Betreff: [Geopriv] Some comments for draft-guenther-geopriv-saml-policy-01

Hi All, 
After reading through this draft, I think that this should become a WG item - the concepts here aren't as complex as they were made out to be and I can definitely see a need for this work.  This document could prove to be the basis of many authorization schemes.
Some minor comments then.  The definitions should use the types defined in the SAML spec, rather than using xs:string.  Issuer -> saml:NameIDType is an easy one, but the others are also possible (AuthnContext -> saml:AuthnContextType might work, provided that we want to support authorization context declarations, if not we should at least use saml:AuthnContextClassRef; similarly for saml:Subject).  Keeping SAML capitalization here might be something worth looking at as well.  Perhaps I it might be better to profile SAML and use<redefine> with appropriate restrictions to get the appropriate subset of SAML elements for our application.
Also, regarding cardinality - what are the implications of the following? 
  <samlcondition> 
    <issuer>example.com</issuer> 
    <issuer>biloxi.com</issuer> 
    <subject><nameid>[email-masked]</nameid></subject> 
    <subject><nameid>[email-masked]</nameid></subject> 
  </samlcondition> 
Does this mean that both example.com and biloxi.com are capable of asserting the identity of [email-masked] ?  I would propose that you tighten the cardinality rules to allow only one issuer.
The common-policy schema should not be duplicated here; a reference should suffice. 
Cheers, 
Martin  

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

---

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

I concur with Hannes, in the sense that focusing on mechanical 
properties of authorization and authentication seems to add complexity 
without significantly enhancing privacy and usability. Maybe instead of 
asking (implicitly) "we have a SAML hammer, how can we turn GEOPRIV into 
a nail", we might ask what real-world problems we need to solve to 
increase security, predictability, usability and the confidence of the 
user into the system, while not adding an inordinate amount of baggage 
along the way.

I think trait-based authorization is indeed quite valuable, but there 
may be simpler ways to get there then importing SAML into the rule set, 
namely by abstracting beyond SAML details. Thus, a policy extension 
could state "allow those certified as PSAPs by dhs.gov" some access. 
That this might actually locally be translated into a SAML policy is a 
lower-layer concern.

Henning