RE: [security-services] Summary: ISSUE:[MS-5-07: SSO Confirmation ](was: ISSUE: bindings-model-11: SSO Assertion'sConfirmationMethod set t oSAMLArtifact?)

[Irving Reid <Irving.Reid@baltimore.com>]

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

We didn't really have a specific attack or vulnerability in mind; as I
recall, it was more of a "maybe if we put this in some unknown attack might
not work."

In any case, if we're giving up on this principle then our artifact profile
could be simpler; we could (for example) use the assertion ID as the handle
rather than requiring a cryptographically strong random number.

I'm not (yet) suggesting we make any changes; I just wanted to point out
that we're contradicting one of our earlier goals.

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

 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.