OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

imi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [imi] SAML 2 profile questions




Mike Jones wrote:

> 2.3.3 states:
> 
> Assertions issued in accordance with this profile MUST contain a single 
> <saml:AuthnStatement> that reflects the authentication of the token 
> requester to the identity provider. It MAY contain a single 
> <saml:AttributeStatement> that carries one or more <saml:Attribute> 
> elements reflecting the claims requested by the relying party, in the 
> manner specified by SIP.
> 
>  
> 
> In 2.3.3, why  is the AuthnStatement mandatory, rather than optional?  
> Isn’t it legitimate to have the token convey claims while being silent 
> about authentication?

If you are using bearer assertions, then the presence of the authn token 
only provides extra granularity for access control if it contains
a) the LOA value and/or
b) a permanent ID of the user that is known to the SP.

Otherwise it does not serve any security purpose, since an attacker that 
can copy the bearer assertion can copy the authn assertion as well and 
masquerade as the original user.


> 
>  
> 
> Similarly, why is the AttributeStatement optional?  Because sometimes 
> there are no claims?

My preferred model is that the attribute statement is mandatory and the 
authn statement is optional and is only present if it provides some 
valid purpose, such as a permanent ID, LOA or proof of possession token.


> 
> In 2.3.3, the draft states that “the assertion MUST be signed”.  I 
> understand the value of this, but I’d like us to at least discuss this 
> before assuming that this should be a MUST.  For instance, is this a 
> MUST when the token is used with the SAML 2.0 protocol?
> 
>  

In many cases TLS is sufficient, so I see no need to make this mandatory.

> 
> 2.6 states “The Information Card model's support for hiding the identity 
> of the relying party from the identity provider, combined with 
> constraints on the implementation of the model for use with web 
> browsers, leads to requests for "unconstrained" bearer assertions with 
> no audience or subject confirmation conditions on use. This is 
> *extremely *dangerous and insecure, 

This is clearly more dangerous than a bearer credential with an audience 
restriction. But on a scale of 1 to 100, where would you place both 
types of bearer credentials as opposed to pop credentials which are 
placed at one end of the scale. I dont think they are orders of 
magnitude appart, and would be relatively close together on this scale.

even if assertion validity is
> extremely short term. This profile recommends against such a practice 
> and urges implementations, if they do support such behavior, to enable 
> deployers to disable it by requiring requests for bearer assertions be 
> accompanied by the identity of the relying party.”  Do others feel that 
> this criticism of non-auditing cards, which have important privacy 
> properties, is a bit over the top?

If you want privacy protection then you can always use a freshly minted 
randomly generated identifier to identify the user in each new assertion

regards

David


> 
>  
> 
>                                                                 -- Mike
> 
>  
> 

-- 
-------------------------------------------------------------
The Israeli group Breaking the Silence has just released a collection of
testimonies by Israeli soldiers that took part in the Gaza attack last
December and January. The testimonies expose significant gaps between 
the official stances of the Israeli military and events on the ground.

See  http://www.shovrimshtika.org/news_item_e.asp?id=30

The Israeli government defies Obama, and continues its settlement expansion

Israel plans to allocate $250 million over the next two years for 
settlements

http://www.palestinecampaign.org/index7b.asp?m_id=1&l1_id=4&l2_id=24&Content_ID=698

whilst simultaneously continuing to bulldoze Palestinian homes

http://salsa.democracyinaction.org/o/301/t/9462/campaign.jsp?campaign_KEY=27357

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]