Public Comment

[comment-form@oasis-open.org]

Comment from: Nicolas.Williams@sun.com

 - Core

   - The Kerberos V name syntax is not that given here.  Sam Hartman suggests that a reference to RFC1964 for a string syntax would be good.

   - Keying

      - How is key material obtained for encrypting or signing SAML elements?  My impression is that if one has a certificate suitable for XMLsig then one can use send wrapped ephemeral keys or key transport or agreement and then encrypt, and/or one can just sign with the cert.  But this did not seem to be explicitly mentioned in the SAML2 drafts -- perhaps it's just that I've not read them carefully.

   - Message authentication

      - XMLenc does not really provide for message authentication, therefore it really must be used in conjunction with XMLsig.  Section 6 should not merely say that XML signatures and encryption "MAY" be combined.  The security considerations doc doesn't even mention this, or so it seems given its table-of-contents.  Again, maybe I've only made too-cursory a reading of these documents.

   - channel binding issues

      - When relying on non-SAML-based channels for session security there may be security considerations issues relating to the possibility that the end-points of the two channels may be different -- i.e., just saying "use TLS" does not mean that there will not be MITMs in a SAML exchange.  Similar issues have come up at the IETF w.r.t. SASL and TLS, for example.

 - Sec. Cons., section 5.2.1.2

   Requiring that initiators sign initial messages does not necessarily significantly reduce the responder work load that malicious initiators can cause since, presumably, the responder would have to validate the signature.

 - Conformance, section 4.2

   Ciphers are listed, but cipher modes aren't, and no reference to an XML encryption specification is given.  This is at least obnoxious, in that one has to hunt down the reference to obtain the additional information.  The reference to key transport algorithms also seems strange given the lack of discussion of keying in the core document.  The XMLenc spec has many more required algorithms, but section 4.2 is not clear as to whether all of XMLenc's requirements are applicable to SAML2 conformance or not.

 - There really should be an IETF<->OASIS liason.

   SAML specs use RFC2119 and seem to stick to some IETF I-D guidelines (e.g., normative/informative reference split, etc...); certainly they reference many IETF RFCs.  Further, I can imagine that folks will desire to transport SAML assertions in PKIX extensions, Kerberos V authorization data / ticket extensions, Kerberos V AP exchange authorization data / extensions, etc...  A liason may prove useful.

 - More examples would be appreciated.