Dear ML, Today I spent some time reading http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-05.txt. Here are some comments; I apologise if some (or all) of them do not apply due to some misunderstanding on my part.
Technical comments: Section 7.1.4: "If it is signed then it MUST be signed by the same key that is used in the Transport Layer Security mechanism utilized with HTTPS." Comment: This seems to me to be a mandatory violation of the key seperation principle (see Remark 13.32 in http://www.cacr.math.uwaterloo.ca/hac/about/chap13.pdf). Section 13.3: Reason phrase "Unknown SAML Assertion Content" Comment: I think that "Assertion Content Not Recognised" makes slightly more sense. Section 7.1.5, generally Comment: Assuming that some verification step fails, what is the correct response code? Section 7.1.5, generally Comment: What are the verifier's steps if the assertion is not signed? What is the correct response code in this case? (assuming that the verifier insists on signed assertions) Section 13.3, generally. Comment: The document specifies response code 478, but does not seem to specify when it should be used. Section 7.2, "we assume that a SAML assertion is obtained out-of-band and attached to the body of the SIP message." Comment/Questions: How exactly is this attaching done? Who exactly does the attaching? The client? Are intermediaries allowed to do it, too? Must every SIP message receiver parse the body in order to detect the presence of an assertion? Most importantly, what if the SIP message already has/should have a body? How is the existing body merged with the assertion? Is the SAML-Info header *and* an assertion body allowed? If not, what is the error response code? Section 10: "The attacker could then conceivably attempt to impersonate the subject (the putative caller) to some SIP-based target entity." Comment: What if the attacker attempts to impersonate the subject to some "non-SIP-based target entity", i.e. some entity that consumes SAML assertions but, since it is not a SIP entity, may follow different verification logic that than described in the document. I think that this attack scenario deserves separate treatment in the security considerations. Editorial comments: Section 13.1: "Their syntax is given in Section 9." -> "Its syntax is specified in section 6." Section 7.1.4.1.1: "The value for the Issuer XML element MUST be a value ..." -> "If the assertion is signed, then the value for the Issuer XML element MUST be a value ..." That's all for now. Best Regards, Andreas NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of DRAGE, Keith (Keith) > Sent: Tuesday, November 04, 2008 10:25 PM > To: SIP IETF > Subject: [Sip] WGLC for draft-ietf-sip-saml-05 > > (As WG chair) > > This mail is to initiate a WGLC on > > http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-05.txt > > SIP SAML Profile and Binding > > Intended Status: Experimental > > This is a two week working group last call so please send > your comments to the list and direct to the editor by the > 18th November 2008. As this date is just after the start of > IETF#73, please put this high up your reading list. > > Normal rules apply - for each please indicate the type of > comment you are making to give us some idea of the sort of > severity, and if possible please indicate what sort of fix > would be required, or even better, supply revised text. > > regards > > Keith > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
