[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 ](was: ISSUE: bindings-model-11: SSO Assertion'sConfirmationMethod set t oSAMLArtifact?)
Agreed, this has kind of slipped in as we reviewed text in various related pieces of the specification. I am strongly inclined to remove and make the mods unless there is compelling evidence of its utility. Good topic for our Tuesday meeting. Ironicaly, I spent last week ranting at people about the dangers of making small changes to security protocols! - prateek >>-----Original Message----- >>From: Irving Reid [mailto:Irving.Reid@baltimore.com] >>Sent: Sunday, March 17, 2002 11:24 PM >>To: 'Jeff.Hodges@sun.com'; oasis sstc >>Subject: RE: [security-services] Summary: ISSUE:[MS-5-07: SSO >>Confirmation ] (was: ISSUE: bindings-model-11: SSO >>Assertion'sConfirmationMethod set t o SAMLArtifact?) >> >> >>> 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. >> >>---------------------------------------------------------------- >>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