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