[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Re: Subject confirmation (was RE: Multiplesubjects in SAML assertion s)
All, I think it's critical to observe at the beginning that the SubjectConfirmation field does NOT designate a subject. Regarding: >Unless I'm misreading his intent, it would not be possible to make a SAML >Protocol request, asking an attribute authority for attribute assertions >corresponding to a <SubjectConfirmation> subject. To me, this implies that >an assertion _must_ have a <NameIdentifier> in its subject if we want an RP >to be able to request other relevant assertions. I "sort of" agree.... My note distinguishes between subject *designation* (which *might* be a name identifier, but also might be an assertionID, or something else), and subject *confirmation*, which simply verifies that "the correct" subject is present somehow -- regardless of how the subject was designated. So... while I agree that you can't request an assertion which uses SubjectConfirmation to *designate* a subject, I don't agree that an assertion must have a NameIdentifier -- it must just have *some kind* of subject designator. Regarding: >It also still leaves open the question I raised in my Multiple Subjects message >http://lists.oasis-open.org/archives/security-services/200110/msg00029.html , >about what a Relying Party should do when faced with an >AuthenticationAssertion with more than one <NameIdentifier> in its ><Subject>. SubjectConfirmation "sometimes works and sometimes doesn't" in multiple-subject cases. In the "None" case, it always works. In the "Holder of Key" case, it works *if* the subject knows which key to use -- if he has keys for more than one name in the list, then he might get confused (he might have different certs/keys for various different names, e.g.). If he only has one key, no problem -- just use it. If you really believe the line that all the subject designators are semantically equivalent, then presumably they all designate the subject who has the specified key (even if the key doesn't -- strictly speaking -- belong to any of the names which actually appear in the subject designator). Regarding: >(1) Authority asserts whatever about Subject, and only wants RelyingParty to >rely on this assertion if presented by holder-of-key (or similar mechanism) > >and > >(2) Authority asserts whatever about Subject, only wants RelyingParty to >rely on this assertion if presented by holder-of-key, *AND* asserts that >holder-of-key is Subject > >and the slightly less strict > >(3) Authority asserts whatever about Subject, and if RelyingParty cares, it >can verify that the presenter is the Subject by checking holder-of-key (1) is the correct formulation. The authority *does not* assert that holder-of-key is subject; this would be (semantically) a very dangerous assertion, and the authority has no way of knowing or controlling who holds a key. In my earlier message I very carefully phrased things to avoid any statement asserting that passing SubjectConfirmation tests means that the subject named in the assertion is really present. SubjectConfirmation does NOT guarantee that the correct subject is present (in fact if the SubjectConfirmation method is SenderVouches, then the subject is NOT present); it merely protects against *specific* threats in the intended environment of use of the assertion. Regarding: >This leaves us with no way in the standard to link a <SubjectConfirmation> >with a <NameIdentifier>, as Chris pointed out in his follow-up. I'm afraid I'm just confused. <SubjectConfirmation> is *always* used to confirm the participation of the "correct" subject in a transaction involving a SAML assertion. Given that each assertion has only ONE subject (regardless of whether there are multiple designators -- if there are then they are all presumptively equivalent), the *presence* of <SubjectConfirmation> in the assertion links it explicitly to the one & only subject of the assertion. What more is required? --bob Bob Blakley (email: blakley@us.ibm.com phone: +1 512 436 1564 fax: +1 512 436 1919) Chief Scientist, Security and Privacy, Tivoli Systems, Inc. Irving Reid <Irving.Reid@baltimore.com> on 10/03/2001 04:39:13 PM To: "'Hallam-Baker, Phillip'" <pbaker@verisign.com>, security-services@lists.oasis-open.org cc: Subject: Subject confirmation (was RE: Multiple subjects in SAML assertion s) > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Subject: RE: Multiple subjects in SAML assertions > > Core 20 states: > > If a <Subject> element contains more than one subject > specification the > issuer is asserting that the statement is true for all of the subjects > specified. For example if both a <NameIdentifier> and a > <SubjectConfirmation> element are present the issuer is > asserting that the > statement is true of both parties. This leaves us with no way in the standard to link a <SubjectConfirmation> with a <NameIdentifier>, as Chris pointed out in his follow-up. It also still leaves open the question I raised in my Multiple Subjects message http://lists.oasis-open.org/archives/security-services/200110/msg00029.html , about what a Relying Party should do when faced with an AuthenticationAssertion with more than one <NameIdentifier> in its <Subject>. > Conditions is not the place to put subject confirmation. > Phillip Hallam-Baker FBCS C.Eng. A number of the suggested uses for the existing <SubjectConfirmation> element feel like Conditions to me. For example, the SOAP profile that Prateek presented at F2F4 put a ds:KeyInfo into <SubjectConfirmation> to indicate that an assertion was only applicable in the context of a document signed by the corresponding key. That, to me, certainly belongs in <Conditions>. Perhaps we need to clarify the distinction between: (1) Authority asserts whatever about Subject, and only wants RelyingParty to rely on this assertion if presented by holder-of-key (or similar mechanism) and (2) Authority asserts whatever about Subject, only wants RelyingParty to rely on this assertion if presented by holder-of-key, *AND* asserts that holder-of-key is Subject and the slightly less strict (3) Authority asserts whatever about Subject, and if RelyingParty cares, it can verify that the presenter is the Subject by checking holder-of-key I'm using the phrase "presented by holder-of-key" in a rather generic sense to refer to any way that the RP can determine that a principal involved in a process satisfies the <SubjectConfirmation> criteria - could be because that principal signed a document containing the assertion, presented a SAML Artifact (corresponding to the assertion) over an HTTP/SSL connection with client certificate, etc. My feeling is that (2) is what most people mean when they say SubjectConfirmation, and I think that's as good a definition as any. I think we still need to change the <Subject> schema to enforce the correspondence between <SubjectConfirmation> and <NameIdentifier> elements (if there is one). Bob Blakley's message http://lists.oasis-open.org/archives/security-services/200109/msg00041.html suggests that <SubjectConfirmation> is only meaningful in an assertion. Unless I'm misreading his intent, it would not be possible to make a SAML Protocol request, asking an attribute authority for attribute assertions corresponding to a <SubjectConfirmation> subject. To me, this implies that an assertion _must_ have a <NameIdentifier> in its subject if we want an RP to be able to request other relevant assertions. With that in mind, I'd be happy if we simplified the <Subject> schema to: <element name="Subject" type="saml:SubjectType" /> <complexType name="SubjectType"> <sequence> <element ref="saml:NameIdentifier"/> <element ref="saml:SubjectConfirmation" minOccurs="0"/> </sequence> </complexType> - irving - ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC