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:rphilpott@rsasecurity.com
|