SIPPING Working Group Sanjoy Sen Internet Draft Lee Valerius Category: Standards Track Nortel Networks Expires on: May 2002 Vesa Torvinen Ericsson November 2001 Single Hop Message Authentication in SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 Abstract To date, the HTTP access authentication framework, as described in [RFC2617] and as used in [SIPbis05], has permitted limited SIP message authentication from UAC to Proxy/UAS, Proxy to Proxy, and Proxy to UAS. This draft addresses some of the shortcomings of SIP usage of Digest for message authentication between a SIP User Agent and a Proxy one hop away (e.g., an outbound Proxy). For the messages exchanged between the UA and a Proxy one hop away, the Service Provider may want to provide a different level of protection than that possible for the same messages end-to-end. Authentication of both requests and responses traveling in either direction should be possible with minimum number of necessary roundtrip exchanges. We discuss some the limitations of SIP Digest message authentication framework in satisfying these requirements and propose possible solutions. A new value of the "qop-options" parameter would indicate to a SIP entity that the challenging entity is one hop away and the maximum protection of SIP message is required. Some other aspects of Internet Draft Single Hop Message Authentication in SIP Nov 2001 this solution are in the form of behavior enhancements of SIP Proxy and UA. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction ...................................................2 2 Conventions used in this document ..............................2 3 Digest for SIP Message Authentication between UA and Proxy one hop away...........................................................3 4 Example Call Flows .............................................5 5 Security Considerations ........................................9 6 References .....................................................9 7 Acknowledgments ................................................9 8 Author's Address ...............................................9 9 Full Copyright Statement ......................................10 1 Introduction To date, the HTTP access authentication framework, as described in [RFC2617] and as used in [SIPbis05], has permitted limited SIP message authentication from UAC to Proxy/UAS, Proxy to Proxy, and Proxy to UAS. This draft addresses some of the shortcomings of SIP usage of Digest for message authentication between a SIP User Agent and a Proxy one hop away (e.g., an outbound Proxy). For the messages exchanged between the UA and a Proxy one hop away, the Service Provider may want to provide a different level of protection than that possible for the same messages end-to-end. Thus, it may be required that integrity protection of the entire message (except perhaps the header carrying the credential) be provided. Authentication of both requests and responses traveling in either direction should be possible with minimum number of necessary roundtrip exchanges. The latter consideration is particularly important for access networks that are resource-constrained and prone to large round-trip times. In Section 3, we discuss some the limitations of SIP Digest message authentication framework in satisfying some of the above requirements and propose possible solutions. A new value of the "qop-options" parameter would indicate to a SIP entity that the challenging entity is one hop away and the maximum protection of SIP message is required. Other aspects of this solution are in the form of behavior enhancements of SIP Proxy and UA. In Section 4, the solution is exemplified with some high-level call flows. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in Sen Expires May 2002 [Page 2] Internet Draft Single Hop Message Authentication in SIP Nov 2001 this document are to be interpreted as described in RFC-2119. 3 Digest for SIP Message Authentication between UA and Proxy one hop away We believe that the requirements discussed in the rest of this section are either not clearly addressed in the existing SIP authentication framework or not addressed at all. Requirement# 1: It would be possible to authenticate all SIP messages between the UA and the Proxy at the level of protection negotiated between them. This can be decomposed into two scenarios. A) UAC-Proxy message authentication: For authenticating requests from the UAC [RFC2617], the Proxy issues the Digest challenge in the Proxy-Authenticate header in a 407 response. In response to the challenge, the UAC should include the credential in Proxy-Authorization header and resubmit the request. It is not clear from [RFC2617] or [SIPbis05] how the response forwarded upstream by the Proxy towards the UAC will be authenticated at the protection level negotiated between the Proxy and the UAC. It is proposed here that the Proxy insert the Authentication-Info header (with the proper credential) in the response that it forwards upstream towards the UAC. B) UAS-Proxy message authentication: According to [RFC2617], the UAS can authenticate requests forwarded by the Proxy as follows: the UAS must generate a 407 response with a Proxy-Authenticate header containing a Digest challenge. In response, the Proxy should re-submit the request with a Proxy- Authorization header carrying the credential. All subsequent responses from the UAS to be authenticated by the Proxy should carry the Proxy-Authentication-Info header with proper credential. However, a couple of problems arise for UAS-Proxy authentication in SIP. First, the use of Proxy-Authentication-Info header is not mentioned in [SIPbis05]. Secondly, a Proxy is prohibited from adding the Proxy-Authorization header to a forwarded request, unless the request is re-submitted. It is required that a Proxy re-submitting a Sen Expires May 2002 [Page 3] Internet Draft Single Hop Message Authentication in SIP Nov 2001 request must increase the CSeq header field of the request implying that when the corresponding response is received at the UAC, it would be dropped. To alleviate the problem, it has been suggested in the list that the Proxy should be able to "resubmit" a request just by changing the branch parameter of the top-most Via header (this is equivalent of doing an empty fork). To the UAS, this is a new transaction anyway. If the UA and the Proxy had already authenticated each other, this would allow the Proxy to insert a Proxy-Authorization header (containing its credential) in an incoming request to be forwarded preemptively (i.e., without waiting for a challenge, and thereby avoiding a roundtrip) to the UAS. If the credential is deemed valid by the UAS, the response sent back should contain a Proxy- Authentication-Info header for mutual authentication by the Proxy. If the credential is deemed invalid to the UAS, it will send a 407 response with a Proxy-Authenticate header containing a Digest challenge and the Proxy would "re-submit" the request in the same way as above. Requirement # 2: The security mechanism must be able to protect a SIP message to the maximum extent possible, when the SIP entities are just one hop away. Also, the framework should support replay protection for all messages. This is decomposed into two parts, which are evaluated separately. A) Maximum Integrity protection of SIP messages: Digest supports integrity protection of the SIP message body (not the headers) when the qop-options directive within the Digest challenge is set to the value "auth-int". A new qop-options value - "auth-extd-int" is proposed, which when set by the SIP entity one hop away issuing the challenge, will direct the client to include for integrity protection all headers and bodies of the message that are mutually agreed on for maximum protection. For example, this might mean that the A2 parameter of the Digest response [RFC2617] is computed as follows: A2 = H(entire message with all headers in canonical form, excluding the header which carries the credential). B) Anti-replay protection: This is really a function of how the server generates the nonce. In order to limit performance impact, it may be required that the same nonce be used over multiple messages. In that case, the nonce-count is useful to provide replay protection. It is recommended that the Proxy server generate a new nonce value whenever possible. For example, if the UAS sends its authorization credentials to the Proxy Sen Expires May 2002 [Page 4] Internet Draft Single Hop Message Authentication in SIP Nov 2001 in the Proxy-Authentication-Info header, it should send a new next- nonce value. Requirement # 3: In order to avoid excess round-trip, a Proxy should be able to piggyback its challenge in a 401 or 407 response that it forwards upstream to the UAC. This is useful in certain operations where the user authentication and message authentication mechanisms are different and take place at different network entities. An example of this is the third generation mobile network [3gpp-req] where the authentication of the SIP UA might be conducted at an entity different than the Proxy with whom the UA establishes the message integrity relationship. [RFC2617] notes that if a client is to be authenticated by multiple entities, the challenges must be carried in different responses. However, [SIPbis05] allows for the Proxy to aggregate multiple challenges in responses to forked requests and insert them to a single 401 or 407 response to be sent upstream. The same mechanism can possibly be leveraged by the Proxy, which can add a Proxy- Authenticate header (carrying its challenge) to a 401/407 response that will be forwarded upstream. Generally, a Proxy sends its challenge upstream in a 407 response. The UAC responds with a matching credential for each challenge. 4 Example Call Flows We will consider an example utilizing a mobile, wireless terminal as UA to illustrate some of the above proposals. There is a SIP serving proxy (also acting as a Registrar) that would authenticate the UA and would also support the ability to terminate INVITEs to the UA. There is a SIP outbound Proxy that acts as a "point of presence" for the roaming UA to the SIP world. At the time of registration, the roaming user is authenticated by the serving Proxy. Subsequently, all messages between the user agent and the outbound Proxy must be authenticated. Two cases are considered. CASE 1: UA registering and originating a call UA Outbound Proxy Serving Proxy | | | | REGISTER F1 | | |---------------->| REGISTER F1 | | |-------------------->| | | | | | 401 Unauthorized F2 | Sen Expires May 2002 [Page 5] Internet Draft Single Hop Message Authentication in SIP Nov 2001 | 401 F3 |<--------------------| |<----------------| | | | | | REGISTER F4 | | |---------------->| REGISTER F5 | | |-------------------->| | | 200 OK | | 200 OK F6 |<--------------------| |<----------------| | | INVITE F7 | | |---------------->| INVITE | |-------------> | | | |<------------- |<----------------| 200 OK | 200 OK F8 | | | |---------------->| | ACK F9 |-------------> | | ACK F1: UA sends a REGISTER message to the outbound Proxy, which is forwarded to the serving Proxy. F2: The serving Proxy returns a 401 "Unauthorized" message containing a WWW-Authenticate header carrying an authentication challenge. The challenge may utilize any known authentication method. SIP/2.0 401 Unauthorized ... WWW-Authenticate:... F3: The outbound Proxy adds a Proxy-Authenticate header to 401 containing the proxy-initiated security challenge. This example features a Digest challenge so as to illustrate the usage of the new qop-options value "auth-extd-int". SIP/2.0 401 Unauthorized ... WWW-Authenticate:... Proxy-Authenticate: Digest realm=MOBILEUSR nonce=, algorithm=MD5, qop=auth-extd-int F4: The UA re-sends the REGISTER with the authentication response in Authorization header and the Digest response in Proxy-Authorization header. Sen Expires May 2002 [Page 6] Internet Draft Single Hop Message Authentication in SIP Nov 2001 REGISTER sip:server.nortel.com SIP/2.0 ... Authorization:... Proxy-Authorization: Digest username=, realm=MOBILEUSR, nonce=, uri=, response=, cnonce=, nc=1, qop=auth-extd-int F5: The outbound Proxy forwards the REGISTER after verifying the Digest response and stripping off the Proxy-Authorization header. REGISTER sip:server.nortel.com SIP/2.0 ... Authorization:... F6: The 200 OK to the REGISTER arrives at the Proxy. The Proxy inserts the Authentication-Info header in the 200 OK for authenticating the message to the UAC [Note: this assumes that the authentication of the REGISTER message at the Proxy in step F5 is successful]. SIP/2.0 200 OK Authentication-Info: nextnonce=, qop=auth-extd-int, rspauth=, nc=1 F7: A subsequent INVITE request to a user Bob, must also be integrity protected - the UA pre-emptively adds the Proxy- Authorization header. INVITE sip: bob@server.nortel.com SIP/2.0 ... Proxy-Authorization: Digest username=, realm=MOBILEUSR, nonce=, uri=, response=, cnonce=, nc=2, qop= auth-extd-int F8: The 200 OK response is forwarded to the UA by the Proxy after inserting the Authentication-Info header. SIP/2.0 200 OK Authentication-Info: qop=auth-extd-int, rspauth=, nc=2 F9: UA sends an ACK message complete the INVITE transaction ACK sip: bob@server.nortel.com SIP/2.0 ... Proxy-Authorization: Digest username=, realm=MOBILEUSR, nonce=, uri=, response=, cnonce=, nc=3, qop= auth-extd-int Sen Expires May 2002 [Page 7] Internet Draft Single Hop Message Authentication in SIP Nov 2001 CASE 2: UA receives an incoming INVITE through the outbound Proxy. The UA and the outbound Proxy has mutually authenticated as described in CASE 1. UA Outbound Proxy | | | | INVITE | INVITE F1 |<------------- |<----------------| | | |---------------->| | 200 OK F2 |-------------> | | 200 OK | | | |<------------- |<----------------| ACK | ACK F3 | | | F1: The Outbound Proxy receives an incoming INVITE. The Proxy modifies the branch parameter in the top-most Via header, inserts the Proxy-Authorization header containing the Digest credentials and "re-submits" the request to the UAS. INVITE sip: tom@host.nortel.com SIP/2.0 Via: SIP/2.0/UDP server.nortel.com;branch=23ade45.1 ... Proxy-Authorization: Digest username=, realm=MOBILEUSR, nonce=, uri=, response=, cnonce=, nc=1, qop= auth-extd-int F2: If the authentication is successful, the UAS sends a 200 OK with the Authentication-Info header. SIP/2.0 200 OK Authentication-Info: qop=auth-extd-int, rspauth=, nc=1 F3: The Proxy inserts the Proxy-Authorization in the incoming ACK message and again "resubmits" the request Sen Expires May 2002 [Page 8] Internet Draft Single Hop Message Authentication in SIP Nov 2001 ACK sip: tom@host.nortel.com SIP/2.0 Via: SIP/2.0/UDP server.nortel.com;branch=23ade45.1 ... Proxy-Authorization: Digest username=, realm=MOBILEUSR, nonce=, uri=, response=, cnonce=, nc=2, qop= auth-extd-int 5 Security Considerations Most of the security considerations in Section 4 of [RFC2617] still apply except that now we can provide a better level of integrity protection with consequent reduction in risk for MITM attacks. However, since the authentication mechanisms are carried in the challenges in clear-text, bidding-down type of attack is still possible. 6 References [SIPbis05] Session Initiation Protocol, draft-ietf-sip-rfc2543bis- 05.txt [RFC2617] HTTP Authentication: Basic and Digest Access Authentication, RFC 2617 [3gpp-req] 3GPP requirements on SIP, draft-garcia-sipping-3gpp-reqs- 00.txt 7 Acknowledgments The authors would like to thank Scott Orton of Nortel Networks and Tao Haukka of Nokia for their useful comments and suggestions related to this draft. 8 Author's Address Sanjoy Sen Nortel Networks sanjoy@nortelnetworks.com Lee Valerius Nortel Networks valerius@nortelnetworks.com Vesa Torvinen Oy LM Ericsson Ab Sen Expires May 2002 [Page 9] Internet Draft Single Hop Message Authentication in SIP Nov 2001 vesa.torvinen@ericsson.fi 9 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Sen Expires May 2002 [Page 10]