[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").

 

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

 
Line 226: [RSP] Replace "SAML as multi-party"
     with "SAML as a multi-party".

 
Line 281: [RSP] Replace "must be provide"
     with "must provide" and remove extraneous period at the end.

 
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.

 
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.

 
Line 374: [RSP] Replace "description cipher
     suites" with "description of cipher suites"

 
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.

 
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.

 
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?

 
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.

 
Line 625: [RSP] Remove extraneous period.

 
Lines 646-647: [JLinn/RSP] The sentence reads
     oddly.  It is unclear what is "it" (two references)?

 
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?

 
Line 717: [RSP] Replace "resource" with "assertion". 
     The resource wasn't captured, the assertion response was.

 
Line 732: [RSP] Note that the current -09 [SAMLBind]
     document does not contain section numbers.  Thus the reference to "4.1.1.7"
     is an unknown reference.  I presume the problem is really with the SAMLBind
     document which should have section numbers.

 
Line 742: [RSP] The reference to [SAMLBind] Section
     4.1.2.5 is an unknown reference.  See note .-1.

 
Line 759: [RSP] dangling reference to [SAMLBind]
     Section 4.2.3. (see .-2)

 
Line 766: [RSP] Replace "are" with "is"

 
Lines 785-789: [RSP] This is a very long run-on
     sentence.  Reword for clarity.

 
Lines 790-794: [RSP] Another very long run-on sentence.

 
Line 833: [RSP] "A collects these assertions"
     should be "A sender collects these assertions"

 
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

mailto: