OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss-comment message

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


Subject: Public Comment


Comment from: thomas.wisniewski@entrust.com

Name: Thomas Wisniewski
Title: Software Architect
Organization: Entrust
Regarding Specification: WSS SAML Token Profile 1.1

Hi. I'm only an observer of the WSS TC, but I had a question/observation on
the Saml Token Profile 1.1 Spec that perhaps you can help me with -- maybe
there's a simple answer that I'm not seeing.
 
In the X509 Token Spec, there is an emphasis on a certificate substitution
attack. A lot of section 3.3 revolves around this (lines 255-258 call it out
specifically) and all three examples are such that the certificate being
used cannot be substituted -- either by signing the actual bytes of the
certificate, or by signing (thus immutable) an unambiguous reference. The
main reason for the signing is that the key identified in the certificate
may actually reside in multiple certs, therefore another certificate may be
substituted that has different attributes in it.
 
I'm not sure why the same emphasis is not placed on a SAML assertion. I.e.,
The same key may be used with different SAML assertions, hence depending on
the SAML assertion, the user may have different attributes, conditions of
use, etc... I suppose I expected a statement like:
 
"Implementations SHOULD protect against a SAML assertion substitution attack
by including either the SAML assertion itself or an immutable and
umambiguous reference to teh SAML assertion within the scope of the
signature according to the method used to reference the certificate as
described in ..."
 
My first thought was that the SAML KeyIdentifier (i.e., the STR reference)
should also be included in the signature (it is not) and that would be
sufficient in the example in section 3.5.1.4 (and 3.5.1.3). However, I see
the KeyIdentifier as being ambiguous (unlike the ds:X509IssuerSerial which
is not). For SAML 2.0, I believe the combination of the SAML Assertion ID
and the Issuer of the Assertion would make it unambiguous. Since this is not
an option, the entire SAML Assertion would need to be signed using the
STR-Transform.
 
 
 
Thanks, Tom.

Thomas Wisniewski



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