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: RE: [security-services] Summary: ISSUE:[MS-5-07: SSO Confirmation ]



On Sun, 17 Mar 2002, Irving Reid wrote:

> > From: Jeff Hodges [mailto:Jeff.Hodges@sun.com]
> > Sent: Friday, March 15, 2002 6:03 PM
> > The change to make to bindings-model-11 is to change lines 525-526 of
> > bindings-model-11 to say..
> >
> >  The <saml:ConfirmationMethod> element of each assertion MUST be 
> >  set to the value specified in [SAMLCore] for "SAML Artifact", and the 
> >  <saml:SubjectConfirmationData> element MUST be present with its value 
> >  being the SAML_artifact supplied to obtain the assertion(s). 
> 
> This explicitly breaks one of the original design principles for the SAML
> artifact binding. When we built the artifact binding, we imposed on
> ourselves a specific constraint that is MUST NOT be possible to derive the
> artifact from the corresponding assertion, to make sure that someone who
> could get their hands on the assertion couldn't trick the sender into
> thinking they were the intended recipient.

If the intent is to provide a verifiable connection between the artifact 
and the assertion, the SubjectConfirmationData could be a hash of the 
Artifact value.  That way a party verifying the assertion could determine 
that it was indeed an assertion about the referenced Artifact, but could 
not use the Assertion to generate an Artifact it didn't have.  

That said, I don't see that the currently-specified web browser Artifact
profile needs this connection between Artifact and Assertion.  A relying
party is obliged to trust an authority's assertion that a particular
returned Assertion really does apply to the Artifact in question, and
since the RP has just done a query-by-artifact, a rogue AP would have the
Artifact and could generate the above hash.  Further protection would be
provded by doing something like a keyed hash as SubjectConfirmationData
where the AP and the RP share a secret key, but it's hard to see that
there's a need for this.  The association between an Artifact and an 
Assertion is made by the AP by its response to the query, and RPs will 
have to make do with that, seems to me.

 - RL "Bob"




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


Powered by eList eXpress LLC