[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [security-services] FW: Comment from: Nicolas.Williams@sun.com
Note: forwarded message attached.
--- Begin Message ---
- From: prateek mishra <email@example.com>
- To: prateek mishra <firstname.lastname@example.org>, Nicolas.Williams@sun.com
- Date: Thu, 13 Jan 2005 23:08:33 -0800 (PST)Hi Nicolas, Thanks for your note. We are starting to freeze the specification, so I made a quick pass thru your comments and have no doubt missed some key points. > > - 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. [Prateek] Just to make sure I understand your comment: you are proposing to RFC1964 instead of RFC1510 as the former provides an explicit definition of the syntax of a (string) Kerberos Principal Name Form. [\Prateek] > > - 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. > [Prateek] Discussion of trust-establishment and key management were not included within scope of SAML 2.0. While it would be helpful to have some additional material in this space, I don't believe there are any open issues here. [\Prateek] > - 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. > [Prateek] I believe you will find this information is the protocol section of core, as well as the profile, binding and conformance specifications. These specifications describe various forms of authentication (channel, DSIG, other) that are mandatory in various contexts. Section 6 only provides some general guidelines for SAML use of signing over and above those available in XML-DSIG. [\Prateek] > - 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. > [Prateek] I am not sure of the specific change you are suggesting here. Is there language regarding use of SSL/TLS that we should change? [\Prateek] > - Sec. Cons., section 18.104.22.168 > > 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. > [Prateek] Agreed, but the notion here is that malicious initiators are forced to work harder if signatures are required. Responders are less affected as signing is generally considered to be more computation-intensive than its validation. I believe this is precisely what the text states: "In addition to the benefits gained from client authentication discussed in Section 22.214.171.124, requiring a signed request also lessens the order of the asymmetry between the work done by requester and responder. The additional work required of the responder to verify the signature is a relatively small percentage of the total work required of the responder, while the process of calculating the digital signature represents a relatively large amount of work for the requester. Narrowing this asymmetry decreases the risk associated with a DOS attack." [541-545] [\Prateek] > - 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. [Prateek] I will add the missing reference to XML-ENC. There is no intent here of superseding or modifying XML-ENC. Re-reading the text, I have to agree that it sounds odd, I will have to review the original source from the list archives. Maybe this should be written as a non-normative note, more of a reminder to implementors (Recall that XML-ENC etc.) than a mandatory ("MUST") requirement. [\Prateek] > > - 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. > [Prateek] Agreed, without a doubt liason would be helpful, volunteers are solicited :-) [\Prateek] > - More examples would be appreciated. > > [Prateek] As above :-) [\Prateek] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > email@example.com > For additional commands, e-mail: > firstname.lastname@example.org > >--- End Message ---