Marcos Dytz implemented SIP Pay and I asked him to review the document. Here are his review comments:
----------------------------- Von: ext Marcos Dytz [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juni 2007 10:20 An: Tschofenig, Hannes Betreff: Re: SIP SAML Draft Review Hey Hannes, I finished my review. Here are my comments: Overall the draft is much more detailed (thus, better) than anything I've read before on SIP/SAML. My points on possible improvements to be added. 1) I believe that it would be good to leave a bit the emphasis on authentication and providing different uses of the protocol (or, at least, specifying that it can be used to convey attributes, query for information, etc). 2) The SAML assertion profile sounds weird, although I never completely had a complete grasp of its meaning. I understand that it is connected with the implementation, but it never actually had any particular use to me (or I never gave it much attention). I rather see it as details that developers had to apply in order to have the implementation working and must be added to the specification in order to avoid interoperability issues. 3) I believe it is worth mentioning that one invalid condition locks the whole assertion. 4) I also believe that is worth mentioning that the Identity-Info is connected with CERTS and might go through deployment issues. 5) Is there something missing on 7.1? Sounded incomplete to me. 6) I believe that it is valid that together with signing part of the message, some fields are hashed in order to improve security. 7) The part of the AS as an authenticator and proxy could be further clarified. Just some tips on how I believe it could be further improved. Again overall the draft is very good and understandable. Cheers Marcos PS: Grammar corrections (and suggestions). I've put changes under parentheses. * areas where the applicability to SIP (are) is widely desired. * Employing SAML in SIP necessitates devising a new SAML profile(s) and binding(s) because (the) those already specified in the SAMLv2 * specification set are specific to other use contexts (contexts of use sound more connected with general use of the term, no?), e.g., HTTP-based web browsing. * 6.1. AS-driven SIP SAML URI-based Attribute ( )Assertion Fetch Profile (Double spacing) * Since the AS (is) already being trusted to create and add the Identity header containing the SIP Identity Assertion, and to supply a pointer to its domain certificate, having it point instead to a SAML assertion conveying the domain certificate and possibly some user profile attributes, does not significantly alter the first-order security considerations examined in [RFC4474]. The last one was confusing to me. I re-wrote by having two sentences. Since the (is) AS already being trusted to create and add the Identity header containing the SIP Identity Assertion, and to supply a pointer to its domain certificate. By having it point instead to a SAML assertion conveying the domain certificate and possibly some user profile attributes does not significantly alter the first-order security considerations examined in [RFC4474]. * Although this profile (is) overview is cast in terms of a SIP INVITE transaction, the reader should note that the mechanism specified herein, and in [RFC4474], may be applied to any SIP request message. * the randomness requir(e)ments specified in Section 1.3.4 of [OASIS.saml-core-2.0-os]. * The value of the NotOnOrAfter XML attribute MUST be set to a time instant later than the value for(or of?) NotBefore. * 6.1.3.4. Verifier Dereferences HTTP-based SAML ( )URI Reference * the SIP SAML assertion profile specified herein (states) that the subject's SAML assertion must adhere to causes it to be not useful to arbitrary parties. * Additionally, the assertion content dictated by the SAML assertion profile herein ensures (or provides?) ample evidence for a relying party to verify the assertion and its relationship with the received SIP request. _______________________________________________ Sip mailing list https://www1.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
