I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I am not knowledgeable in SIP or in SAML, so another reviewer has also reviewed this document. Executive Summary: I believe this was an early review request, not a review for last call or IESG telechat. The document appears to be in an early stage of maturity. I found some of the English difficult to parse. It could stand significant WG review. The hard-to-parse English will make it difficult for implementers to interpret the text the same way, and could cause implementations to not interoperate properly. The English MUST be cleaned up to enable getting the security right. Way way too many options and loose language; this really needs to be tightened up. Security Review: In section 4, the document states "In oder for any trait-based system to be practical, participating entities must agree on the attributes. And then it goes on to say we don't define attributes or explain how to discover what attributes are supported. Then why bring this up? I mention it in the security review portion for 2 reasons: 1) There are so many things this document raises and then does not discuss it took a while before I could determine what this document actually DID discuss. 2) Each of the things raised and not fully discussed seemed to be options, and this document describes a profile of options on options on options. There is a lot of text here that says this could happen, and this could happen and this could happen - how about some nice RFC2119 langauge describing what MUST/SHOULD/MAY happen so that implementers can interoperate? I get very concerned when I see so many options. I doubt anybody could ever tell whether security was achieved or not because there are so many optional pieces to consider. section 7.1.3 step 2 mentions cached credentials. The security Considerations do not discuss cached credentials. Security Considerations have a nunber of SHOULDs (or shoulds) but little discussion of when it is appropriate to not do so. In a number of cases I wondered why these were not MUSTs. For example, in countermeasures, "should be signed" - why not "MUST be signed"? The element attribute methd SHOULD be set to XXXX, but MAY be set to something else. Are we standardizing here? What is the reason it SHOULD be set to XXXXX, and under what circumastnaces woudl it be appropriate to not do so? "Note that any SIP message may be used to convey the SAML assertion even though SIP INVITE may be th emost approrpiate candidate." - are we standardizing, or writing something that allows any variation of implementation to claim compliance? 10.3 "The SAML assertion may contain several elements to prevent replay attacks. There is, however, a clear tradeoff between the replaying an assertion and re-using it over multiple SIP exchanges/sessions." - So are we standardizing some guidelines at least, to help guide implementers to develop something that will interoperate reasonably? Other comments: In the Introduction, it says various means of authorization exist, and it lists 3 types, then says the authors selected SAML (which was not one of the three). I found the terminology section confusing. It would be easier on readers if citations were of the form "Title" [RFCXXXX] rather than just [RFCXXXX]. To know what document RFCXXXX refers to requires looking up the document or looking in the references, which interrupts reading. Hope this helps, David Harrington dbharrington at comcast.net ietfdbh at comcast.net dharrington at huawei.com _______________________________________________ secdir mailing list secdir at mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir at ietf.org https://www.ietf.org/mailman/listinfo/secdir