FW: Comment from: [email protected]

Comment from: 

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