RE: [security-services] Groups - sstc-saml-sec-consider-2.0-draft-03-diff.pdf uploaded

["Linn, John" <jlinn@rsasecurity.com>]

Here are some specific review comments on
sstc-saml-sec-consider-2.0-draft-03-diff, 21 June 2004. 

Line 159, following "in the interaction", suggest adding "(and any
subsequent uses of data obtained from the transactions)". 

Lines 257-259, suggest the following restatement: "In this role, SAML
transfers authentication data, supporting end systems' ability to protect
against unauthorized usage."

Line 315, at end of sentence, suggest addition: ", and of the correctness of
the data and processing on which the generated assertions are based." 

Line 319, "must be provide" -> "should provide an appropriate"?

Line 353, suggest changing "for integrity check CRCs of" to "integrity
checking facilities on", given that other algorithms (e.g., MACs) are those
generally used for these protocol facilities and that they provide stronger
security properties than CRCs offer. 

Line 367, suggest changing "to the key" -> "to a private or secret key
representing a principal", to avoid suggesting that public keys used to
verify authentications must be protected from disclosure. 

Lines 431-432: Breaking 40-bit symmetric keys took 4 hours in 1997 with
about 250 workstations; it would be in an afternoon's reach for a less
well-equipped attacker today.  RSA-512, however, took about 8000 MIPS-years,
which even today seems harder to fit into a moderately equipped afternoon.
I suggest replacing the sentence with "Keys of these lengths have been
successfully attacked, and their use is not recommended." 

Lines 433-434: Should also list AES among the available algorithms. 

p. 12, footnote 1: suggest changing "The RSA patents have all" -> "The RSA
algorithm patent has". 

Lines 628-629: Is there also a potential for injecting a response to an
observed request, such as a spurious "yes" reply to an authorization
decision query, or return of non-genuine attributes? 

Line 735-736 (and, similarly, at 798-799): It doesn't seem clear from this
text why the requirement for an SSO assertion to be included constitutes a
countermeasure against assertion stealing; is the intent for a tie-in with
the bullet starting at 741, concerning possible tighter validation rules for
SSO assertions than other assertions, and/or is there further rationale that
would be useful to cite here? 

Para starting at 776: this also relates to the issue noted re the bindings
document, concerning the overall integrity of the combination of RelayState
element and separate SAML message.  Suggest adding at end of sentence within
777, ", in conjunction with its associated SAML message elements". 

Line 919, 7.2.1.2: This section's discussion fits certain authentication
methods (like passwords) where users authenticate by presenting reusable
data elements to verifiers, but the recommended countermeasure may be
unnecessarily strong for some cases, as when authentication is performed
using a cryptographically based protocol between a device acting for a
principal and a verifier.  Suggest, at line 920: "revealing authentication"
-> "revealing reusable authentication" 

--jl