Re: [wss-comment] Public Comment

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Thomas,

I agree with your concern.

I think it may be sufficient to sign the str, although I think signing
the entire assertion would eliminate concerns of key ambiguity and would
allign the attesting behavior with that performed for sender-vouches
assertions.

add the following after line 695

It is strongly recommended that the attesting entity protect against
substitution of another assertion or statement with equivalent
confirmation key. The attesting entity MAY accomplish this by including
either the SAML assertion or an unambiguous reference to the SAML
assertion within the content it signs to demonstrate knowledge of the
confirmation key.

The examples should also be changed to show and describe the additional
references in signed info.

and a description of the risk of assertion substitution should be added
to the security considerations section.

Ron


comment-form@oasis-open.org wrote:

>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
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wss-comment-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wss-comment-help@lists.oasis-open.org
>
>  
>