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: [security-services] Comments/questions on draft-sstc-sec-consider-04

Darren Platt and I requested folks in our RSA Labs group to review the current SAML documents.  John Linn's draft-sstc-sec-consider comments/questions are extracted below (denoted with [JLinn]).  I've interspersed a few of my own along the way (denoted with "RSP").


  1. General Comment: [JLinn] Generally, this document makes many useful recommendations about security mechanisms that could be applied in response to threats.  It would be useful if more requirements and recommendations for use of particular mechanisms were indicated explicitly, perhaps becoming conformance requirements.  As it stands, different suggestions might be applied by different entities, leading to inconsistent assurance as they interoperate. [RSP: I echo John's sentiment here. I think it would be useful to make it very clear in the document what is recommended for SAML (this is done in section 4.5.2 for cipher suites, but not anywhere else). Next, I think we should identify many of them as Conformance Requirements.]
  2. Line 226: [RSP] Replace "SAML as multi-party" with "SAML as a multi-party".
  3. Line 281: [RSP] Replace "must be provide" with "must provide" and remove extraneous period at the end.
  4. Line 320: [JLinn] CRCs shouldn't say CRCs, as it isn't the form of integrity check actually used for TLS. [RSP] also mention (as in section 4.2.1) that IPsec applies only between 2 nodes.
  5. Lines 328-329 & Lines 333-334: [JLinn] lists of security services for which keys are managed and used should include confidentiality as well as authentication, data integrity, and non-repudiation.
  6. Line 374: [RSP] Replace "description cipher suites" with "description of cipher suites"
  7. Lines 394-395: [JLinn] it's worth noting that the effort to break a 512-bit RSA key (approximately 8,000 MIPS-years) still requires substantially more effort than that needed to break a 40-bit symmetric key.  Even today, access to unusually powerful resources would be required to achieve this in an afternoon.
  8. Lines 589-591: [JLinn] for completeness, note that the signature must also be validated by the recipient in order for an integrity guarantee to be achieved.
  9. Lines 604-607: [JLinn] individual, per-message signing may not protect against an active attacker's saving responses returned from one transaction and inserting them as responses to different transactions.  Are sequence numbers necessarily managed and applied with sufficient uniqueness, and reliably checked for correspondence with requests, in order to defend against this threat?
  10. Lines 619-623: [JLinn] Is "certificate-backed authentication over server-side SSL" intended to be the standard SSL/TLS handshake with client-side certificates?  If so, suggest citing as "SSL with client-side and server-side authentication"; the standardized form of certificate-based client authentication doesn't take place "over" a distinct channel that provides server-side authentication.
  11. Line 625: [RSP] Remove extraneous period.
  12. Lines 646-647: [JLinn/RSP] The sentence reads oddly.  It is unclear what is "it" (two references)?
  13. Lines 670-685: [JLinn] The structure of the bulleted list here is unclear.  Is the intent that all but the final item are recommended, but that the final item (which uniquely says "must") is required?
  14. Line 717: [RSP] Replace "resource" with "assertion".  The resource wasn't captured, the assertion response was.
  15. Line 732: [RSP] Note that the current -09 [SAMLBind] document does not contain section numbers.  Thus the reference to "" is an unknown reference.  I presume the problem is really with the SAMLBind document which should have section numbers.
  16. Line 742: [RSP] The reference to [SAMLBind] Section is an unknown reference.  See note .-1.
  17. Line 759: [RSP] dangling reference to [SAMLBind] Section 4.2.3. (see .-2)
  18. Line 766: [RSP] Replace "are" with "is"
  19. Lines 785-789: [RSP] This is a very long run-on sentence.  Reword for clarity.
  20. Lines 790-794: [RSP] Another very long run-on sentence.
  21. Line 833: [RSP] "A collects these assertions" should be "A sender collects these assertions"
  22. Line 866: [RSP] Replace "insertion" with "deletion"


Rob Philpott

RSA Security Inc.

The Most Trusted Name in e-Security

Tel: 781-687-7585

Mobile: 617-510-0893

Fax: 781-687-7019




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

Powered by eList eXpress LLC