RE: [security-services] Re: Subject confirmation (was RE: Multiplesubjects in SAML assertion s)

[Jahan Moreh <jmoreh@sigaba.com>]

I very much agree....The only way I could think of associating a "subject"
with a SubjectConformation is if we have an X.509 certificate in the
optional KeyInfo element (from ds:). Of course, the specification of
"subject" in X.509 is different from SAML. So, this is a very weak
association at best.

Jahan


---------------------------
Jahan Moreh
Chief Security Architect
Sigaba Corp.
jmoreh@sigaba.com <mailto:jmoreh@sigaba.com>
cell: 310.890.9391
tel: 310.286.3070





>-----Original Message-----
>From: George Robert Blakley III [mailto:blakley@us.tivoli.com]
>Sent: Tuesday, October 16, 2001 12:02 PM
>To: Irving Reid
>Cc: 'Hallam-Baker, Phillip'; security-services@lists.oasis-open.org
>Subject: [security-services] Re: Subject confirmation (was RE: Multiple
>subjects 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/m
>sg00029.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/m
>sg00041.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>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>