[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] SubjectConfirmation errata
Ron Monzillo wrote: > Prateek Mishra wrote: > > hi Prateek and Scott, > >> [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. >> > IMV, an entity satisfying the confirmation method has been authorized > by the > assertion issuer to use (the identity of) the subject of the assertion. > > IMV, if an additional identifier is present it indicates that the > assertion issuer has authorized > the attribution of this additional identifier to any entity that > satisfies the confirmation method. > > As such, the presence of this additional identifier indicates that to > the assertion issuer, the > attesting entity is different (by this additional attribute) from the > subject. > > is that not sufficient? > > Ron > >> 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 >>> >>> >>> >> >> >> >> --------------------------------------------------------------------- >> 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]