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] Does SubjectConfirmation==HolderOfKey meanSubject==Sender?


I've cut and pasted chunks from Bob Blakley's message
http://lists.oasis-open.org/archives/security-services/200110/msg00093.html,
to highlight a point I think we need to clarify.

When the "HolderOfKey" element was introduced (I believe it was Tim Moses at
F2F#3 who brought it up), it seemed clear to me that it was intended to
designate a subject. That is,

"The subject of this assertion is the principal who can prove possession of
keying material corresponding to the attached ds:KeyInfo"

One example use case was to tie an assertion to an SSL connection with
client key/certificate authentication; another was to tie an assertion to a
signed message.

Bob's view differs:

> From: George Robert Blakley III [mailto:blakley@us.tivoli.com]
> Sent: Tuesday, October 16, 2001 3:02 PM
> Subject: [security-services] Re: Subject confirmation (was 
>           RE: Multiple subjects in SAML assertions)
> 
> I think it's critical to observe at the beginning that the
> SubjectConfirmation field does NOT designate
> a subject.
> 
> ... 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.

I don't think we can solve this problem in the general case. What we _can_
do is put conditions on an assertion, so that relying parties can tie the
assertion to some surrounding context. I'll invent some new SAML elements to
use as examples:

<Assertion>
   <Conditions>
      <SignedBy>
         <ds:KeyInfo>...

indicates that an assertion is only valid if the message to which it is
attached was signed by the holder of the appropriate key (we might want to
generalize this to something like "cryptographic context", to handle cases
where assertions are presented over authenticated SSL or whatever).

<Assertion>
   <Conditions>
      <AttachedTo>[message hash]

indicates that the assertion applies only to the hashed message.

The thread that ties these examples, and most of the rest that I can think
of, is the *Sender*. What the relying party can really determine is whether
the sender's use of an assertion corresponds to the intended use of that
assertion.

None of this says anything about the "meaning" of the attachment between the
assertion and the message. It's none of SAML's business. Applications might
want to attach SAML assertions representing the Subject, the Object, and the
Subject's brother-in-law, and use the same confirmation mechanism to verify
all of those attachments.

My point is that SAML can't say whether the assertion designates a "subject"
in some application using SAML. Only that application (or perhaps the SAML
Profile for that application) can specify this. I believe the
<SubjectConfirmation> element is misleading; that's why I keep trying to
push this sort of confirmation into the <Conditions> element.

> 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).

OK, this makes a little more sense to me - if we accept that multiple
subject designators in an assertion must all refer to the same principal,
then a single SubjectConfirmation confirms the _principal_, and therefore
all the subject designators.

That still doesn't answer the hard question about multiple subject
designators: How does a relying party retrieve additional information about
the principal? What if it gets contradictory attribute assertions, each
applying to one of the subject designators?


> 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.

This is the core question. Based on my memory of F2F#3, I would have
expected most people to choose (2). The whole reason we named it
<SubjectConfirmation> in the first place, was because the original proposal
the relying party used the ConfirmationMethod to make sure it was talking
*to* the subject. Things only got messy when we tried to extend it to Sender
!= Subject.

 - 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.


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


Powered by eList eXpress LLC