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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: Re: [security-services] SubjectConfirmation errata


[PM]
Scott,

I am broadly in agreement with the changes proposed.

I am concerned about how relying parties figure out whether they are 
dealing with an attesting entity distinct from the assertion subject
vs. the subject itself. Authorization and other decisions may be driven 
off this distinction.

Processing Logic for determining whether attesting entity == subject in 
a SAML HoK assertion:
------------------------------------------------------------------------------------------------

1. Validate proof material (signature, SSL handshake, whatever) against
the <subjectconfirmation>/<confirmationdata> elements found in the 
assertion.

2. At least one <subjectconfirmation>/<confirmationdata> element must  
correspond to the proof material; otherwise fail.

3. If the <subjectconfirmation> element in (2) does not include a 
<NameId> element, then attesting entity == subject.
4.  If the <subjectconfirmation> element in (2) includes a  <NameId> 
element, compare it to the value of <Subject>/<NameId>.
      If the two are identical (after normalization), then attesting 
entity == subject
5. Otherwise, attesting entity != subject.

I guess the concern here is with the relative indirectness of the 
process versus the use of a new condition element that signals 
the issuers intent (attesting entity != subject).
Obviously, there is a cost associated with the latter approach (schema 
for the new element). But maybe it is worth the expense?

SenderVouches is a SAML 1.1 legacy. SAML 1.1 HoK assertions are tightly 
bound to assertion subjects; SV is a one-off that allows others to speak 
for the subject. The generalization of HoK in SAML 2.0 removes the need 
for use of SV. If appropriate, we could even move to deprecate its use
in SAML 2.x at some point.

[\PM]

This is the AI associated with the language around the confirmation elements

>and clarifying the intent of the embedded secondary identifier. It also
>encompasses Prateek's errata (PE 40), and adds some additional "SHOULD"
>guidance around cases where multiple attesting entities (other than the
>subject) are known/intended. The intent was certainly that each
>SubjectConfirmation would identify at most one such additional party, so
>multiple elements should be used in such cases.
>
>I've included text in core, and cleaned up/extended the language for both
>holder of key and bearer. Bearer was far too strictly worded, and was
>botched, much like holder of key was. I did not touch sender-vouches, as I
>quite simply do not understand it, so I'm not stepping in there.
>
>  
>
>
>Core:
>
>Insert the following at line 698:
>
>"If the <SubjectConfirmation> element in an assertion subject contains an
>identifier that is distinct from the identifier in the enclosing subject,
>the issuer authorizes the attesting entity to wield the assertion on behalf
>of that subject. A relying party MAY apply additional constraints on the use
>of such an assertion at its discretion, based upon the identities of both
>the subject and the attesting entity.
>
>If an assertion is issued for use by an entity other than the subject, then
>that entity SHOULD be identified in the <SubjectConfirmation> element."
>
>Profiles:
>
>  
>
>Replace lines 335-337 with:
>
>"As described in [XMLSig], each <ds:KeyInfo> element holds a key or
>information that enables an application to obtain a key. The holder of one
>or more of the specified keys is considered to be an acceptable attesting
>entity for the assertion by the asserting party."
>
>Insert the following at line 341:
>
>"If the keys contained in the <SubjectConfirmationData> element belong to an
>entity other than the subject, then the asserting party SHOULD identify that
>entity to the relying party by including a SAML identifier representing it
>in the enclosing <SubjectConfirmation> element.
>
>Note that a given <SubjectConfirmation> element using the Holder of Key
>method SHOULD include keys belonging to only a single attesting entity. If
>multiple attesting entities are to be permitted to use the assertion, then
>multiple <SubjectConfirmation> elements SHOULD be included."
>
>Replace lines 361-363 with:
>
>"The bearer of the assertion is considered to be an acceptable attesting
>entity for the assertion by the asserting party, subject to any optional
>constraints on confirmation using the attributes that MAY be present in the
><SubjectConfirmationData> element, as defined by [SAMLCore].
>
>If the intended bearer is known by the asserting party to be an entity other
>than the subject, then the asserting party SHOULD identify that entity to
>the relying party by including a SAML identifier representing it in the
>enclosing <SubjectConfirmation> element.
>
>If multiple attesting entities are to be permitted to use the assertion
>based on bearer semantics, then multiple <SubjectConfirmation> elements
>SHOULD be included."
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>  
>




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