Network Working Group A. Niemi Internet-Draft Nokia Research Center Expires: August 31, 2006 February 27, 2006 Reported Issues with the Security Mechanism Agreement for the Session Initiation Protocol (SIP) draft-niemi-rfc3329-issues-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document records some of the issues reported by implementors of the Security Mechanism Agreement for the Session Initiation Protocol (SIP), or RFC 3329. It is intended to serve as an aid in discussions and a checklist for a possible revision of the RFC. Niemi Expires August 31, 2006 [Page 1] Internet-Draft SIP Security Agreement February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. List of Issues . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Calculation of the digest-verify Parameter Value . . . . . 3 2.2. PRACK Missing from Allowed Methods . . . . . . . . . . . . 5 2.3. Server Behavior with Security-Verify . . . . . . . . . . . 5 2.4. Proxy Adding Security-Client and Security-Verify . . . . . 5 2.5. Proxy Behavior for Modifying Proxy-Require and Require . . 5 2.6. Client Behavior with Supported . . . . . . . . . . . . . . 5 2.7. In Which Requests Should Security-Verify be Used? . . . . . 5 2.8. How to Indicate Preference with Multiple ipsec-3gpp Mechanisms? . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Way Forward . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Niemi Expires August 31, 2006 [Page 2] Internet-Draft SIP Security Agreement February 2006 1. Introduction The Security Mechanism Agreement for the Session Initiation Protocol (SIP) [RFC3329] defines new functionality for negotiating the security mechanisms used between a SIP user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities. RFC 3329 was published in January 2003, and since then has received some feedback from various implementors of the specification, revealing some inconsistencies and problems with the specification. This document records some of the issues reported by implementors of sec-agree, or RFC 3329. It is intended to serve as an aid in discussions and a checklist for a possible revision of the RFC. 2. List of Issues This section lists a collection of the main issues encountered with the implementation of the specification. 2.1. Calculation of the digest-verify Parameter Value Security Agreement adds an additional checksum for when Digest authentication is used as the selected security mechanism. This is to protect the negotiation of the security-agreement, namely the contents of the Security-Server header field is mirrored in a checksum in the Security-Verify header field. The calculation is defined as follows: If the "qop" directive's value is "auth" or is unspecified, then A2 is: A2 = Method ":" digest-uri-value ":" security-server If the "qop" value is "auth-int", then A2 is: A2 = Method ":" digest-uri-value ":" H(entity-body) ":" security-server All linear white spaces in the Security-Server header field MUST be replaced by a single SP before calculating or interpreting the digest-verify parameter. Method, digest-uri-value, entity-body, and any other HTTP Digest parameter are as specified in RFC 2617. There are a number of issues with this definition: Niemi Expires August 31, 2006 [Page 3] Internet-Draft SIP Security Agreement February 2006 o First, it doesn't say how SWS between the header name and ":" is treated. This whitespace can be removed without the header semantic changing. But generally it is impossible for an application to know after receiving the header field from a parser whether there was whitespace there, whether it was removed along the message path, etc. o Second, it doesn't clearly define how a Security-Server that is split across multiple header fields is handled. Are the headers pulled together and only after that hashed into A2, or are all of the headers including the field name all put into the hash? o Third, it takes the header field name in as part of the hash calculation unnecessarily. This may cause some interoperability problems, if an intermediary has chosen to uppercase/lowercase the field name. After all SECURITY-SERVER and Security-Server are one and the same. A better way to calculate the verify hash would be to: 1. pull together all header fields if split accross many lines 2. strip all whitespace instead of replacing with SWS 3. toss the header field name I.e., something like this: Security-Server: tls;q=0.1 Security-Server: digest;q=0.2;d-qop=auth-int;d-alg=MD5 Would yield the following input for A2: "tls;q=0.1,digest;q=0.2;d-qop=auth-int;d-alg=MD5" The problem with this proposal is that it is not backwards compatible. But the benefit is that it guarantees consistent calculation of the "d-ver" value. Another option is to simply clarify the current text and defined method. A related issue with the "d-ver" parameter is whether or not it is included in each subsequent Security-Verify header field, which is supposed to be added to all requests sent using the selected security mechanism. Especially with qop of auth-int, it seems superfluous, since the security mechanism has already been selected. Niemi Expires August 31, 2006 [Page 4] Internet-Draft SIP Security Agreement February 2006 2.2. PRACK Missing from Allowed Methods The problem is that table 1 in RFC3329 is not listing the header fields applicable to the PRACK method. 2.3. Server Behavior with Security-Verify Currently, RFC 3329 says any detected modification of the server's security mechanism list (i.e., malformed Security-Verify contents), the server side should do a new challenge via 494. It has been suggested that that is really unnecessary, if the selected security mechanism was successfully used to deliver the request. In fact, the behavior only makes sense for the digest mechanism. 2.4. Proxy Adding Security-Client and Security-Verify Currently, table 1 of RFC 3329 suggests that a proxy can add both the Security-Client and Security-Server header fields in requests. This is wrong and the table should probably list only 'rd' under the proxy column for these header fields. 2.5. Proxy Behavior for Modifying Proxy-Require and Require By default, RFC 3261 doesn't allow a proxy to modify Proxy-Require, or the Require header fields. Some specifications instruct the proxy to do just that, which needs to be motivated in such specifications. RFC 3329 does a poor job at that, and it should include more text justifying why and in which scenarios it is OK to modify these header fields. 2.6. Client Behavior with Supported Currently, the server is instructed (MUST strength) to generate a 421, if the sec-agree parameter in all of Require, Proxy-Require and Supported header fields of the request. However, it is only recommended (SHOULD strength) to put the sec-agree parameter in the Supported header field of the request. 2.7. In Which Requests Should Security-Verify be Used? The text in RFC 3329 should probably explicitly exclude ACK and CANCEL. Now, this is only called out implicitly in Table 1. 2.8. How to Indicate Preference with Multiple ipsec-3gpp Mechanisms? Using the ipsec-3gpp security mechanism, as specified in appendix A of RFC 3329, it is possible to indicate support for more than one ipsec-3gpp mechanism that are different only in the offered Niemi Expires August 31, 2006 [Page 5] Internet-Draft SIP Security Agreement February 2006 encryption and hmac algorithms. Although straight-forward, it is not very well defined how these mechanisms are prioritized using the qvalue. 3. Way Forward There are two main alternatives to clarifying the presented issues in RFC 3329. First, we start revising the RFC, and correct the found bugs in the new version. Second, we publish all of the found issues in the RFC errata pages, and possibly define the 'd-ver' calculation correction as a separate update to RFC 3329. 4. Security Considerations None 5. References 5.1. Normative References [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003. 5.2. Informative References Niemi Expires August 31, 2006 [Page 6] Internet-Draft SIP Security Agreement February 2006 Author's Address Aki Niemi Nokia Research Center P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 Email: aki.niemi@nokia.com Niemi Expires August 31, 2006 [Page 7] Internet-Draft SIP Security Agreement February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niemi Expires August 31, 2006 [Page 8]