Draft: draft-camarillo-sipping-profile-key-00.txt Reviewer: Miguel Garcia [Miguel.An.Garcia@nokia.com] Review Date: Tuesday 7/11/2006 8:00 AM CST Review Deadline: 7/15/2006 Status: Expert Review Summary: This draft is on the right track but has open issues, described in the review. Following the template in RFC 3427: 1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance to these guidelines. The Expert Reviewer will send email to the Transport Area Directors on this determination. The expert reviewer can cite one or more of the guidelines that haven't been followed in his/her opinion. I am the designated expert and I am cc:ing the RAI ADs in this email. 2. The proposed extension MUST NOT define SIP option tags, response codes, or methods. The document defines the P-Profile-Key header field. No option tags, response codes, or methods, are defined. Thus, the requirement is met. 3. The function of the proposed header MUST NOT overlap with current or planned chartered extensions. The P-Profile-Key header field does not relate to any ongoing or planned chartered extensions, and therefore satisfies this requirement. 4. The proposed header MUST be of a purely informational nature, and MUST NOT significantly change the behavior of SIP entities which support it. Headers which merely provide additional information pertinent to a request or a response are acceptable. If the headers redefine or contradict normative behavior defined in standards track SIP specifications, that is what is meant by significantly different behavior. The P-Profile-Key header field allows a first proxy to provide a second proxy with the key to be used by this second proxy to query the user database for a given profile. Therefore, it is an optimization to avoid a second lookup in a database. Session establishment is not affected by the presence or absence of this header. Therefore, this header field does not contradict any normative behavior defined somewhere else. 5. The proposed header MUST NOT undermine SIP security in any sense. The Internet Draft proposing the new header MUST address security issues in detail as if it were a Standards Track document. Note that, if the intended application scenario makes certain assumptions regarding security, the security considerations only need to meet the intended application scenario rather than the general Internet case. In any case, security issues need to be discussed for arbitrary usage scenarios (including the general Internet case). The document indicates that the header is to be applied to the IMS environment, within trusted elements (e.g., belonging to the same administrative domain) where protection is achieved by means of IPsec or physical protection of the network. It seems that the draft just merely indicates what the security considerations are when the header is applied to the initially planned environment, namely, IMS. Perhaps the draft should discuss the consequences of applying this header to a public environment, where the data contents could be spoofed. It is my opinion than, even if the contents of this header could be spoofed, it does not offer any benefit for mounting an attack (e.g., against the database). In other words, a malicious entity could equally mount the attack without accessing to the P-Profile-Key header field value. 6. The proposed header MUST be clearly documented in an (Individual or Working Group) Informational RFC, and registered with IANA. The reviewed document is intended to become the informational RFC required by this consideration. Acceptance of this document for publication as an informational RFC will address this requirement. 7. An applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet. The reviewed document contains an applicability statement, although merely indicates that it is believed that the header is only useful in IMS due to the IMS architectural design. However, the document does not discuss why this header is not applicable to the public Internet, even there were a use case for it. I believe the P-Profile-Key header field is not applicable to the Internet because it requires the second proxy to trust the first, in that the value of the header is accurate, and there isn't a general available mechanism for proxies to trust other proxies. Luck of this trust would allow a first proxy to forge the contents of the P-Profile-Key header so that the second proxy either retrieves a wrong service profile from the user database (if the key points to a different profile), or the query to the user database fails (if the key does not exist). Besides, the assumption is that the architecture provides for two proxies accessing the same user database, something that may not be a common scenario in the Internet. 8. Other comments I have also other technical comments. 8.1) The document introduces the concept of Public Service Identities and Wildcarded Public Service Identities in Section 2, however, the definition of them occurs after its first usage. I would recommend to expand these two terms prior to any usage, perhaps in a new missing section: Terminology. 8.2) Section 2, 4th paragraph uses (twice) the term "Wildcarded Public User Identity". I believe this is a typo and should instead refer to "Wildcarded Public Service Identity". 8.3) The last paragraph in Section 4 provides an example of the P-Profile-Key database that misses the 'sip:' scheme part of the URI: P-Profile-Key: 8.3) The acronyms HSS, I-CSCF, S-CSCF, should be expanded at their first occurrence (so, in the second paragraph in Section 5). 8.4) I believe reference [1] is available in a more updated version than 3.14.0, January 2004. You should refer to version 7.0.0 dated June 2006. The same also applies to other referred 3GPP specifications.