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] | [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