SIP F. Cao, Ed. Internet-Draft Cisco Systems Expires: July 14, 2006 January 10, 2006 Response Authentication in Session Initiation Protocol draft-cao-sip-response-auth-01 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 July 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft describes some extensions for enhancing SIP response authentication. In the real-world SIP deployment, TLS may be not available on some hops. Due to the lack of other response authentication mechanisms in SIP, several kinds of security attacks could be conducted on those hops through SIP response. This draft suggests some approaches for complementary enhancement on SIP response authentication. With the new per-hop response authentication proposed in this draft, the security gaps on the hops without TLS can be bridged. Cao Expires July 14, 2006 [Page 1] Internet-Draft Response Authentication January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Per-hop Authentication Enhancement . . . . . . . . . . . . 4 3.2. Complementariness with TLS . . . . . . . . . . . . . . . . 6 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 5. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 7 6. Syntax and Examples . . . . . . . . . . . . . . . . . . . . . 9 6.1. Header Syntax . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 11 8.2. 432 'Failed Response Authorization Response Code . . . . . 12 9. Contributors' Address . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informational References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Cao Expires July 14, 2006 [Page 2] Internet-Draft Response Authentication January 2006 1. Introduction This document provides complementary enhancements for addressing security concerns on response authentication in Session Initiation Protocol (SIP [1]). [3] described the current limitations of some security mechanisms provided in SIP ([1]). One of them is about the difficulties of deploying TLS over each hop of all SIP dialogs. Because SIPs is the only mechanism for response authentication, the lack of TLS on some hops imposes some threats of malicious attacks through SIP response to disturb the desired service. In particular, there is no strict per-hop authentication for the received SIP response when TLS is absent. This may enable the attackers to spoof SIP response and easily disturb the SIP service. For example, if a rogue proxy can sniff the SIP requests from Proxy-1 to Proxy-2 without TLS, it can spoof the addresses and URIs of Proxy-2 and fake the response back to Proxy-1 along with its own rogue domain authentication service info, right before Proxy-2's response. Proxy-1 and the initiators of SIP requests will be deceived by the responses from the rogue proxy. This allows the rogue proxy to conduct many attacks, such as redirecting the requests to attack other targets for DoS attacks, redirecting the requests to rogue users for information disclosure, and terminating the requests for turning down SIP services. This draft suggests some approaches for complementary enhancement on per-hop response authentication inside SIP, which can bridge the gap when TLS is absent on those hops. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Domain-based Authentication Service (DAS): Authentication service is provided for each domain through its certificate and the domain private key. Proxies may act as the role of authenticate service with the domain private keys. Authenticated Identity Body (AIB): some SIP headers are replicated into a S/MIME body of the same message and are signed with a digital signature (See [5]) Chain of SIP Response Trust (CSRT): All the hops in the path of SIP response provides the authentication mechanisms so that the chain of the trust on the response message can be built from end to end. Cao Expires July 14, 2006 [Page 3] Internet-Draft Response Authentication January 2006 Certificate: An X.509v3 [15] style certificate containing a public key and a list of identities in the SubjectAltName that are bound to this key. The certificates discussed in this document are generally self signed and use the mechanisms in the SIP Identity specification to vouch for their validity. 3. Overview This section gives an overview of the requirements and the mechanisms for addressing the security concerns of SIP response. In particular, some security mechanisms on per-hop authentication are proposed to enhance the response authentication and prevent the malicious attacks through SIP response. The following requirements should be addressed: o The new response authentication must be complementary with SIPs, i.e. it should work when TLS is absent. o Response authentication between neighboring domains or nodes can be enhanced o The mechanism should be simple o CSRT can be built when either this mechanism is applied on all the hops, or this mechanism is applied on some of the hops and TLS is used for the rest. 3.1. Per-hop Authentication Enhancement One simple authentication mechanism is proposed in this document for satisfying all these requirements. This mechanism is to generate a digest challenge for the next-hop node (or domain), and the authorization to this challenge should be delayed, and piggybacked with the next normal SIP response from the next-hop downstream node (or domain). After the digest is verified, the trust can be enhanced for the SIP response from the next-hop node (or domain). There are several security mechanisms covered in this document to support this mechanism: O DAS O shared secret key with the next-hop downstream node O public key of the next-hop downstream node The figure below shows a basic call to illustrate some scenarios. The call is initiated by alice@atlanta.com to bob@biloxy.com. The assumption is that Alice and Atlanta have a shared secret, Biloxi has a public certificate, and Bob and Biloxi have a shared secret. Cao Expires July 14, 2006 [Page 4] Internet-Draft Response Authentication January 2006 Alice Atlanta Biloxi Bob | INV+E(n1) | | | |--------F1--------->| SUBECRIBE | | | +------F2----------->| | | | NOTIFY(cert) | | | |<-------F3----------+ | | | | | | | INV+E(n2) | | | +-------F4---------->+ INV+E(n3) | | | +--------F5--------->| | | | | | | | 200+hash3(n3, .) | | | 200+hash2(n2, .) |<-------F6----------+ | 200+hash1(n1, .) |<------F7-----------+ | |<--------F8---------+ | | | | | | | | | BYE+ hash3(n3, .) | | | BYE+ hash2(n2, .) |<-------F9----------+ | BYE+hash1(n1, .) |<-------F10---------+ | |<--------F11--------+ | | In message F1, Alice sends a normal invite but includes an Authentication header that include the encrypted nonce, n1, that is encrypted for the next hop which is Atlanta. In message F4, Atlanta will forward the invite to Bilboxi with a nonce that is encrypted for Biloxi however, to do the encryption, Atlanta may have to use the Sub/NOT if message F2 and F3 to fetch Biloxi's public key so that it can encrypt the nonce. Note F2 and F3 might be done for previous SIP dialogs from Atlanta.com to Bilboxi.com. In message F5, biloxi sends the INVITE with a nonce encrypted for bob using the shared secret between Biloxi and Bob. In message F6, Bob inserts a header that says the responder in bob@biloxi.com and computes a hash over key parts of the message including the responder header field value. The hash includes the decrypted content of the nonce that Biloxi sent to Bob. When biloxi receives this message it can verify that it the hash is correct and that it believes the responder information. Biloxi computes a new hash over the message using the nonce2 and sends F7 using this hash. Later in message F9, F10, and F11, the hash can be computed using the previous nonces. The proxies do not need to be session state-full as long as the nonce are constructed in a way such that the proxy can Cao Expires July 14, 2006 [Page 5] Internet-Draft Response Authentication January 2006 later check that they are only being used in the dialog for which they were originally constructed. If the verification in Biloxy or Atlanta indicates the unmatched SIP response authorization, the proxy may replace the response code with 432 Failed Response Authorization for announcing the failure of the next-hop response authentication. 3.2. Complementariness with TLS This proposed per-hop authentication mechanism is complementary with TLS in SIP deployment. If TLS is available on some hops, this mechanism can be applied to the other hops where TLS is absent. The below example demonstrate how they work together. Assume that TLS is available between Alice and Atlanta AND between Biloxi and Bob. The hop between Atlanta and Biloxi doesn't support TLS. Alice Atlanta Biloxi Bob | INV over TLS | | | |--------F1--------->| SUBECRIBE | | | +------F2----------->| | | | NOTIFY(cert) | | | |<-------F3----------+ | | | | | | | INV+E(n) | | | +-------F4---------->+ INV over TLS | | | +--------F5--------->| | | | | | | | 200 over TLS | | | 200+hash(n, .) |<-------F6----------+ | 200 over TLS |<------F7-----------+ | |<--------F8---------+ | | | | | | | | | BYE over TLS | | | BYE+ hash(n, .) |<-------F9----------+ | BYE over TLS |<-------F10---------+ | |<--------F11--------+ | | TLS can be applied to create the security tunnels for two hops, i.e. between Alice and Atlanta AND between Biloxy and Bob. Similar to the above example, the hop between Atlanta and Biloxy can use the proposed response authentication mechanism to enhace response security. All the hops in this example provide the security mechanisms to check Cao Expires July 14, 2006 [Page 6] Internet-Draft Response Authentication January 2006 that o the received response message from the desired upstream node o the integrity of this received message can be verified. Therefore, CSRT can be built by combining this extension and TLS from end to end. The rogue proxies can be prevented from attacking SIP services through SIP responses. 4. User Agent Behavior The extensions in this document require new processing and parsing for both UAS and UAC. Their behaviors are described in this section. When UAC sends the SIP request, UAC can generate nonce before assembling the new authentication header field. For DAS, UAC must obtain the certificate of DAS for the next-hop node. The nonce is encrypted and inserted into Response- Authentication. For the shared key with the next-hop node, the nonce is encrypted by the shared key to ensure its privacy. When it receives the SIP response for the corresponding SIP request, UAC should verify the authorization from the next hop. It generates its own digest through its saved nonce in decrypted format, plus some header fields and the message body in response message. This digest is compared with the one in SIP response message from the next hop. If there is a mismatch, it should treat it as an error and may terminate the dialog with the failure reason. Even if UAC may receive the response code 432 Failed Response Authorization, UAC should finish the steps for verifying the received response from the upstream node. If Response-Authorization carries the correct digest, this response code can be trusted. The proper follow-up operations should take place, such as terminating the dialog with the failure reason. If not, the received response may be suspicious. UAC should analyze the reason before taking any steps for further operations. As a recipient of the SIP request with Response-Authentication, UAS should generate the digest for SIP response with respect to the specified method. The digest is inserted into UAS's next SIP response message back to the downstream node. 5. Proxy Server Behavior The extensions in this document require new processing and parsing Cao Expires July 14, 2006 [Page 7] Internet-Draft Response Authentication January 2006 for proxy servers. Their behaviors are described in this section. After receiving the SIP request with Response-Authentication, the proxy server must save the nonce received from the upstream node. When the proxy server relays the SIP request, it is recommended that the proxy server carry its own Response-Authentication inside the request. The nonce should be encrypted in the specified methods. Before relaying the SIP request to the next-hop downstream node, the proxy server should generate its own nonce, encrypt the nonce in the specified method, and overwrite Response-Authentication header field inside the SIP request. For DAS, the nonce is encrypted by the certificate of the next-hop domain and inserted into Response-Authentication. For the shared key with the downstream node, the nonce is encrypted by the shared key to ensure its privacy. Note the nonce received from the previous hop should not be forwarded to the next hop for reducing the risk of disclosure. If the SIP response is received, the proxy server must finish two steps. First, it has to verify the authorization from the next-hop downstream node. It generates its own digest through its saved nonce in decrypted format, plus some header fields and the message body in response message. This digest is compared with the one in SIP response message from the next hop. Second, it has to generate another digest from the decrypted nonce received from the upstream node, some header fields, and the message body for SIP response. This digest is inserted into its relayed SIP response to the upstream node. Note that the proxy server has to obtain the certificate, the public key or the shared key with the downstream node (or domain) before Response-Authentication is assembled. [4] is recommended to retrieve the certificate through SUBSCRIBE and NOTIFY in the enhanced certificate management. When it receives the SIP response for the corresponding SIP request, the proxy server should compare the digest inside Response- Authorization with its generated one. If there is a mismatch, the proxy server should analyze this suspicious response. The proper follow-up operations should take place, such as replacing the response code with 432 Failed Response Authorization. Note that the saved digest for the corresponding SIP request should be piggybacked into its response. Cao Expires July 14, 2006 [Page 8] Internet-Draft Response Authentication January 2006 Even if it receives the response code 432 Failed Response- Authorization, the proxy server should finish the steps for verifying the validness of this received response from the downstream node. 6. Syntax and Examples 6.1. Header Syntax Two new SIP headers are introduced in this document. Response- Authorization appear in the response. Response-Authentication is eligible in the request. Response-Authentication = "Response-Authentication" HCOLON resp-authen-param resp-authen-param = auth-method-param * (SEMI nonce-param) auth-method-param = "method" EQUAL auth-method-enum * (SEMI alg-param) auth-method-eum = "DAS" / "SharedKey" / "PublicKey" alg-param = "alg" EQUAL token nonce-param = "nonce" EQUAL "nonce-value" Response-Authorization = "digest" EQUAL resp-author-digest Resp-author-digest = LDQUOT 32LHEX RDQUOT For the digest generated in Response-Authorization, the digest-string includes o status code of the response o addr-spec in To o addr-spec in From o addr-spec of claimer field in Responder o method and nonce in Response-Authentication o callid from Call-ID o the digits and the method from CSeq o Date field o body content of the message with the bits exactly as they are in the message (in the ABNF for SIP, the message body). In summary, digest-string for Identity header in the SIP response is digest-string = status-code ":" addr-spec ":" addr-spec ":" addr-spec ":" auth-method-enum nonce-value ":" callid ":" 1*DIGIT SP method ":" SIP-Date ":" message-body Cao Expires July 14, 2006 [Page 9] Internet-Draft Response Authentication January 2006 The decrypted nonce plus this digest-string is hashed and signed with the key based on the specified method. The mandatory procedure is sha1WithRSAEncryption as described in RFC 3371 with base64 encoding as described in RFC 3548. One simple example is given below to show how these new header fields are used when Alice sends an INVITE to bob. INVITE sip:bob@biloxi.com SIP/2.0 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Response-Authentication: method=DAS; alg=rsa-sha1; nonce=rqupqurcnvajfaqruiopqurewfval4139814kfaj134 vnnfaq2kqklpijmhyhhbvfdw43ikfr3535wtetwetw Content-Type: application/sdp Content-Length: 142 The response from Bob should provide Response-Authorization to answer the challenge from Alice. SIP/2.0 200 OK To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Response-Authorization: digest=lqkduncbhyr467u8932udjbfsgdiwoopxjnxdg wuhfduiiqriqopqr3990mcnvbgdqewzsjdormgbktgui Content-Type: application/sdp Content-Length: 131 7. Security Considerations This document provides some complementary security enhancements on SIP response authentication, when TSL is absent on some hops. For example, if a rogue proxy can sniff the SIP requests from Proxy-1 to Proxy-2 without TLS, it can spoof the addresses and URIs of Proxy-2 and send the response back to Proxy-1 along with its own rogue domain authentication service info, before Proxy-2's response. Cao Expires July 14, 2006 [Page 10] Internet-Draft Response Authentication January 2006 Without the proposed mechanisms, Proxy-1 and the initiator of SIP requests will be deceived by the response from the rogue proxy. This allows the rogue proxy to conduct attacks, such as redirecting the requests to attack other targets for DoS attacks, redirecting the requests to rogue users for information disclosure, and terminating the dialogs for turning down SIP services. With the mechanisms introduced in the document, Proxy-1 can detect the faked responses from the rogue proxy, by checking the digest in Response-Authorization. These faked responses are dropped immediately by Proxy-1 without any impact on the callers of SIP requests. All the hops with security concerns should apply these mechanisms for enhancing authentication for SIP response, when TLS is absent on those hops. CSRT should be created by combining TLS and this per-hop response authentication. If not, man-in-the-middle attacks may be possible again through SIP response, just as before. There are some open questions in the future work for enforcing these mechanisms and creating CSRT per SIP dialog. One is how to indicate CSRT is required by the originator UAC. Another is how to notify UAC if CSRT is fully formed or where CRST is missing if applicable. Another security concern is about nonce used this enhancement. Nonce should be random enough for a long period of time. Nonce during a long SIP session should be refreshed periodically to prevent it from being compromised. This document is also based on some existing results for domain-based authentication and certificate management (See [3, 4]). Therefore, these mechanisms may be affected by the secure concerns for these functional components. 8. IANA Considerations This document requests changes to the header and response-code sub- registries of the SIP parameters IANA registry. 8.1. Header Field Names This document specifies two new SIP headers: Response-Authentication and Response-Authorization. Their syntax is given in Section 6. These headers are defined by the following information, which is to be added to the header sub-registry under http://www.iana.org/assignments/sip-parameters. Cao Expires July 14, 2006 [Page 11] Internet-Draft Response Authentication January 2006 Header Name: Response-Authentication Compact Form: (none) Header Name: Response-Authorization Compact Form: (none) 8.2. 432 'Failed Response Authorization Response Code This document registers a new SIP response code which is described in Section 3.2. It is used when the expected Response-Authorization is missing or doesn't carry the correct digest. This response code is defined by the following information, which is to be added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters. Response Code Number: 432 Default Reason Phrase: Bad Identity-Info 9. Contributors' Address Cullen contributed to the development of this document in every aspect. He helped to define the scope and the essential goals in the beginning. He provided substantial input and rewrote some parts of this documents. Cullen Jennings Cisco Systems 170 West Tasman Dr MS: SJC-21/3 Phone: +1 408 421 9990 EMail: fluffy@cisco.com 10. Acknowledgments The editor and the contributors would like to acknowledge the constructive feedback and input provided by John Elwell, Jon Peterson, Jonathan Rosenberg, Peter Thermos, Dean Willis, and Rohan Mahy in emails and discussions in IETF meetings. 11. References Cao Expires July 14, 2006 [Page 12] Internet-Draft Response Authentication January 2006 11.1. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. [4] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", draft-ietf-sipping-certs-02 (work in progress), July 2005. [5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [6] Metz, C., "OTP Extended Responses", RFC 2243, November 1997. 11.2. Informational References [7] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [8] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. Cao Expires July 14, 2006 [Page 13] Internet-Draft Response Authentication January 2006 Author's Address Feng Cao (editor) Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Email: fcao@cisco.com Cao Expires July 14, 2006 [Page 14] Internet-Draft Response Authentication January 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. Cao Expires July 14, 2006 [Page 15]