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] | [List Home]


Subject: Review comments on sstc-saml-bindings-2.0-draft-12-diff.pdf


Here are a few comments based on a review pass through the bindings draft. 

Lines 341 and 344: Should these state, respectively for integrity and
confidentiality, "...needs to be guaranteed at the transport layer..."
rather than "...needs to be guaranteed..." as written?  Previous sections
3.2.2.4 and 3.2.2.5 discuss means to provide these services at the SOAP
layer; in some environments where a requirement for these services exists,
it might be satisfied there without also being applied at the TLS/SSL layer.


Line 483: This isn't a problem where the DEFLATE encoding method is used by
default, but it could become burdensome if other methods are employed and
need to be identified with comparable ~50 character strings inside a URL.
Does this seem like a likely enough prospect to motivate some scheme to
allow shorter-form identifiers, whether within a registry or in the
hierarchy described by a default prefix? 

Lines 460-463 (and, similarly, 614-617, 831-834): It strikes me that it's
important not only to protect the integrity of the RelayState item in its
own right, but also to protect the integrity of its relationship with the
other SAML message elements with which it belongs.  Otherwise, substitution
attacks might be possible.  Does the SAML message's signature include the
RelayState, even though it's treated separately in the bindings?  Otherwise,
it seems that we'd be trusting the HTTP UA to maintain this correspondence
correctly.  Without SSL/TLS or equivalent cross-network protection, there
could also be vulnerability to independent attackers. 

Lines 644-645: Is the RelayState form control within the same form as the
SAMLRequest or SAMLResponse control?  Presuming so, I suggest stating this
explicitly.   (Similarly at lines 854-855, there for the SAMLart control.) 

--jl



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