SIP F. Cao Internet-Draft C. Jennings Expires: January 11, 2006 Cisco Systems July 10, 2005 Response Identity and Authentication in Session Initiation Protocol draft-cao-sip-response-auth-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 January 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft describes some extensions for verifying SIP response identity and enhancing SIP response authentication. Some mechanisms are demonstrated for providing and verifying the identity of SIP responses. In order to prevent several kinds of security attacks through SIP response, SIP response authentication should be provided through a chain of trust of the SIP responses. Some extensions are proposed to enhance the per-hop authentication for handling SIP response. Cao & Jennings Expires January 11, 2006 [Page 1] Internet-Draft Response Identity and Authentication July 2005 This draft is an early work in progress and suggests some approaches but there is still significant discussion needed. Some of the attacks discussed in this draft can be mitigated by using the sips URL. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 SIP Response Identity . . . . . . . . . . . . . . . . . . 4 3.2 Chain of SIP Response Trust . . . . . . . . . . . . . . . 5 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 8 4.1 SIP Response Identity . . . . . . . . . . . . . . . . . . 8 4.2 Chain of SIP Response Trust . . . . . . . . . . . . . . . 9 5. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . 9 5.1 SIP Response Identity . . . . . . . . . . . . . . . . . . 9 5.2 Chain of SIP Response Trust . . . . . . . . . . . . . . . 10 6. Syntax and Examples . . . . . . . . . . . . . . . . . . . . 11 6.1 Header Syntax . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 8.1 Header Field Names . . . . . . . . . . . . . . . . . . . . 15 8.2 431 'Failed Responder Identity Response Code . . . . . . . 15 8.3 432 'Failed Response Authorization Response Code . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 10. Appendix A. AIB used for SIP response identity . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1 Normative References . . . . . . . . . . . . . . . . . . 18 11.2 Informational References . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . 21 Cao & Jennings Expires January 11, 2006 [Page 2] Internet-Draft Response Identity and Authentication July 2005 1. Introduction This document provides enhancements for addressing security concerns on response messages in Session Initiation Protocol (SIP [1]). There are some limitations with the current handling of SIP response without identity verification and authentication that leaves holes for malicious attacks through SIP response. [3] described the current limitations of some security mechanisms provided in SIP [1]. Due to these limitations, some extensions were added in [3] to address the need for authenticating identity of SIP request. The identity of SIP response is more complicated than that of SIP request. First, SIP response may be originated by any intermediate SIP proxies instead of the desired SIP UAS. Because SIP UAC may send requests to SIP UAS without any previous association, these intermediate SIP proxies may not be known or verified by SIP UAC beforehand. Second, the presence of the exact responder for SIP response is not clearly defined, which is different from the From header field for SIP request. In general, it is obvious that the To header field cannot be used as described above. Contact and Reply-to have their own meanings and cannot be relied on for backward compatibility. In this document, some mechanisms are demonstrated to enable the sender to verify the identity of a corresponding SIP response. Furthermore, there are still some loopholes left for malicious attacks through SIP responses. In particular, there is no strict per-hop authentication for the received SIP response. This could enable an attacker to spoof SIP response and disturb the SIP service. This issue is defined as Chain of SIP Response Trust (CSRT) in this document. Some extensions are shown in this document to enhance CSRT in SIP. 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 authenticate servers with the domain keys. Authenticated Identity Body (AIB): some SIP headers are replicated Cao & Jennings Expires January 11, 2006 [Page 3] Internet-Draft Response Identity and Authentication July 2005 into an S/MIME body of the same message and are signed with a digital signature (See [5]) Chain of SIP Response Trust (CSRT): as described in Section 1. 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, the first part is about SIP response identity and how to verify it. The rest is about CSRT for guaranteeing per-hop authentication to prevent malicious attacks through SIP response. 3.1 SIP Response Identity SIP response identify is crucial for negotiation and providing the desired services. UAC might guess the identity of the responder of the received SIP response message through the response code and some header fields. But there is no defined mechanism for determining that identity and verifying it. The following requirements should be addressed: O The identities of both UAs and proxies should be covered O The mechanism should be backward compatible. O The identity should be clearly specified for the responder of the SIP response message. O The integrity of SIP response should be covered along with the responder identify The following example is used in this document to demonstrate the mechanisms in many sections: UAC <------> Proxy-1 <------> Proxy-2 <-----> UAS UAC: alice@source.com Proxy-1: px1@source.com Proxy-2: px2@destination.com UAS: bob@destination.com Cao & Jennings Expires January 11, 2006 [Page 4] Internet-Draft Response Identity and Authentication July 2005 Alice sends an INVITE request to Bob. Proxy-2 receives the request and informs Alice of the response code 183 Session Progress, along with two new header fields called Responder and Responder-Info: Responder: claimer=px2@destination.com; verify-method=DAS; Responder-Info: https://www.destination.com/certs Identify: akfjiqiowrgnavnvnnfa2o3fafanfkfjakfjalkf203urjafskjfaf Jprqiyupirequqpiruskfka [Identity needs to be recalculated] The field of claimer specifies the exact identity of the responder. The field of verify-method indicates the secure mechanism for verifying the identify of the responder. There are several security methods covered in this document to support this mechanism: O DAS O AIB (See Appendix A) For DAS, the mechanism is similar to [3]. Some headers, including the new header Responder, and the body of the message are used to compute a hash. This hash is signed with certificate for Proxy-2's domain (destination.com), and the final output is inserted into the header field Identity introduced by [3]. One new header, Responder, is introduced to specify the exact responder and related authentication method. Responder-Info is inserted to indicate where to acquire the certificate for the claimer of the responder. For DAS, the proxy servers can obtain the certificate of DAS for the responder through Responder-Info. The digest in Identity can be verified for the responder identity. If there is a mismatch, the proxy server may replace the response code with 431 Failed Responder Identity for indicating the problem as early as possible. 3.2 Chain of SIP Response Trust In order to prevent several kinds of malicious attacks through SIP response, Chain of SIP Response Trust (CSRT) should be provided to enhance the per-hop authentication for receiving SIP response. For example, in the above example, a rogue proxy can spoof the IP address of Proxy-2 and send the response back to Proxy-1 along with its rogue domain authentication service info, before Proxy-2's Cao & Jennings Expires January 11, 2006 [Page 5] Internet-Draft Response Identity and Authentication July 2005 response. Without the per-hop authentication, Proxy-1 will be deceived by the response from the rogue proxy. The following requirements should be addressed: O authentication between neighboring domains or nodes can be enhanced O The mechanism should be simple O CSRT can be built when this mechanism is applied on all the hops. 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). 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 & Jennings Expires January 11, 2006 [Page 6] Internet-Draft Response Identity and Authentication July 2005 Alice Atlanta Biloxi Bob | INV+E(n1) | | | |--------F1--------->| SUBSCRIBE | | | +------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 includes the encrypted nonce, n1, that is encrypted for the next hop, which is Atlanta. In message F4, Atlanta will forward the invite to Biloxi with a nonce that is encrypted for Biloxi; however, to do the encryption, Atlanta may have to use the SUB/NOT in message F2 and F3 to fetch Biloxi's public key so that Atlanta can encrypt the nonce. Note F2 and F3 might have already been done for previous SIP dialogs from Atlanta.com to Biloxi.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 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 such that the proxy can later Cao & Jennings Expires January 11, 2006 [Page 7] Internet-Draft Response Identity and Authentication July 2005 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. There are some advantages of this mechanism. For example, man-in- the-middle attacks can be prevented as the rogue proxy does not have the message forward to him in a valid way and cannot compute a valid hash for the response. This method can be easily distributed to enhance the security in any specified hops among domains. A proxy such as Biloxy does not need to do work until Bob actually sends the 180 response. At this point it must decrypt the the original nonce and recompute the hash. However, this is after the call has been at some level accepted by a device that this provides service for. Therefore, CSRT can be enhanced through this extension 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. 4.1 SIP Response Identity When UAS sends the response, UAS must accurately generate the new header fields as the responder. For DAS, UAS must populate Responder inside the SIP response. In addition, the URI as claimer inside Responder must be consistent with what UAS registers in its domain. Note the URI as claimer may be different from other header fields, such as Reply-To, Contact, and To, in some scenarios. Please see Proxy Server Behavior for Identity and Responder-Info. When it receives the corresponding SIP response, UAC can verify the identify of the responder. For DAS, the certificate of DAS for the responder should be obtained to verify the digest in Identity. UAC may receive the response code 431 Failed Responder Identity. UAC should choose to avoid the verification of the responder identity. UAC should treat it as a failure and may terminate the dialog. Cao & Jennings Expires January 11, 2006 [Page 8] Internet-Draft Response Identity and Authentication July 2005 4.2 Chain of SIP Response Trust 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 next-hop. 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. 5. Proxy Server Behavior The extensions in this document require new processing and parsing for proxy servers. Their behaviors are described in this section. 5.1 SIP Response Identity The proxy server may provide the domain authentication service for an outgoing SIP response. When a SIP response is received without the header Responder, the proxy server may insert the identity of the sender as the responder along with Responder-Info and Identity. After receiving the SIP response with a new header field Responder, the proxy servers may verify the responder identity in order to detect the mismatched identity as early as possible. Cao & Jennings Expires January 11, 2006 [Page 9] Internet-Draft Response Identity and Authentication July 2005 For DAS, the proxy server can obtain the certificate of DAS for the responder through Responder-Info. The digest in Identity can be verified for the responder identity. If there is a mismatch, the proxy server may replace the response code with 431 Failed Responder Identity for announcing the problem. On the other hand, the proxy servers may relay the SIP responses without checking the responder identity and modifying any fields including response codes. 5.2 Chain of SIP Response Trust After receiving the SIP request with Response-Authentication, the proxy server must save the nonce received from the upstream node. It is recommended that when the proxy server relays the SIP request, the proxy server carry its own Response-Authentication inside the request. The nonce should be encrypted. Before relaying the SIP request to the next-hop downstream node, the proxy server should generate its own nonce, encrypt the nonce, and overwrite the 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 that to reduce the risk of disclosure, the nonce received from the previous hop should not be forwarded to the next hop. 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 the SIP response message from the next hop. Second, the proxy server 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 Cao & Jennings Expires January 11, 2006 [Page 10] Internet-Draft Response Identity and Authentication July 2005 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. 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 Four new SIP headers are introduced in this document. Responder, Responder-Info, and Response-Authorization appear in the response. Response-Authentication is eligible in the request. Responder = "Responder" HCOLON responder-param Responder-param = claimer-param *( SEMI verify-param) claimer-param = "claimer" EQUAL (name-addr / addr-spec) verify-param = "verify-method" EQUAL ("DAS" / token) Note: token in verify-param can be extended to cover other verification methods, such as AIB(See Appendix A in detail). Responder-Info = "Responder-Info" HCOLON responder-info-param responder-info-param = LAQUOT absoluteURI RAQUOT For DAS, the responder's identity is the digest in the the Identity header. This digest is generated by including the following elements of the SIP response in a bit-exact string in this specified order. O addr-spec in To O addr-spec in From O addr-spec of claimer field in Responder O callid from Call-ID Cao & Jennings Expires January 11, 2006 [Page 11] Internet-Draft Response Identity and Authentication July 2005 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 = addr-spec ":" addr-spec ":" addr-spec ":" callid ":" 1*DIGIT SP method ":" SIP-Date ":" message-body Similar to [3], this digest-string is hashed and signed with the certificate for the domain. The mandatory procedure is sha1WithRSAEncryption as described in RFC 3371 with base64 encoding as described in RFC 3548. Here is one sample response from Bob in the above example: SIP/2.0 180 Ringing Via: SIP/2.0/UDP px1.source.com;branch=z9hG4bKnashds8 ;received=101.37.45.98 Via: SIP/2.0/UDP px2.destination.com;branch=bfajk34lk2 ;received=121.56.12.1 To: Bob ;tag=a6c85cf634 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Responder: claimer=bob@destination.com; verify-method=DAS Responder-Info: https://www.destination.com/certificate Identity: oiurw20984oij12kfqfknrewqfhgahg198431ufadsafafdag32r4189f hafaaafi298r3398i32uip293gDFQqireu904328FQWlkafqroiewrjafaf k189ahffahjf4289981 Content-Length: 0 [*Identity: needs to be recalculated] Two new headers are introduced for CSRT: Cao & Jennings Expires January 11, 2006 [Page 12] Internet-Draft Response Identity and Authentication July 2005 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 auth-method-eum = "DAS" / "SharedKey" / "PublicKey" 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 The decrypted nonce plus this digest-string are 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. Cao & Jennings Expires January 11, 2006 [Page 13] Internet-Draft Response Identity and Authentication July 2005 7. Security Considerations This document provides some security enhancements on SIP response identity and response authentication. There are some advantages for the proposed mechanisms in this document. The new fields inside SIP response provide the needed responder identity with authentication methods, and are backward compatible with [1]. The mechanisms proposed for per-hop SIP response authentication can be easily used on any hops, such as hops between different domains, to prevent malicious attacks through SIP responses over those hops. Furthermore, if each hop (or all the hops with security concerns) is enhanced with these mechanisms, CRST can be created to detect and prevent several kinds of malicious attacks through SIP responses, and to guarantee the validness of SIP response. For example, if a rogue proxy can sniff the SIP requests from Proxy-1 to Proxy-2, 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. Without the proposed mechanisms, Proxy-1 and the caller of SIP requests will be deceived by the response from the rogue proxy. This will allow 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. Another example is to verify the response identity, which is important in many scenarios. This document provides the responder identity through the new header fields in SIP response, and the mechanism for verifying this identity. All the hops with security concerns should apply these mechanisms for enhancing authentication for SIP response. If not, man-in-the-middle attacks may be possible again through SIP response, just as before. This document is 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. Cao & Jennings Expires January 11, 2006 [Page 14] Internet-Draft Response Identity and Authentication July 2005 As anonymous identity is a subject for future work, this document leaves one open question about the exact impact of these mechanisms on anonymous identity. 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 four new SIP headers: Responder, Responder- Info, 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. Header Name: Responder Compact Form: (none) Header Name: Responder-Info Compact Form: (none) Header Name: Response-Authentication Compact Form: (none) Header Name: Response-Authorization Compact Form: (none) 8.2 431 'Failed Responder Identity Response Code This document registers a new SIP response code which is described in Section 3.1. It is used when the responder of the SIP response cannot be verified successfully. 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: 431 Default Reason Phrase: Failed Responder Identity 8.3 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 Cao & Jennings Expires January 11, 2006 [Page 15] Internet-Draft Response Identity and Authentication July 2005 http://www.iana.org/assignments/sip-parameters. Response Code Number: 432 Default Reason Phrase: Bad Identity-Info 9. Acknowledgments 10. Appendix A. AIB used for SIP response identity The following example is used in this document to demonstrate the mechanisms in many sections: UAC <------> Proxy-1 <------> Proxy-2 <-----> UAS UAC: alice@source.com Proxy-1: px1@source.com Proxy-2: px2@destination.com UAS: bob@destination.com Alice sends an INVITE request to Bob. Proxy-2 receives the request and informs Alice of the response code 183 Session Progress, along with two new header fields called Responder and Responder-Info: Responder: claimer=px2@destination.com; verify-method=AIB Responder-Info: https://www.destination.com/certification For AIB inside S/MIME, some headers including Responder are used as the authenticated body inside S/MIME. It is up to the responder to decide if end-to-end security is needed, which may trigger the encryption of AIB through the public key of the caller, i.e. Alice. AIB is signed with responder's private key to assure its identify. Assume that TLS is set up for each hop, including between Alice and Proxy-1 and between Proxy-1 and Proxy-2. The mechanism for handling AIB inside S/MIME can be applied for handling the identity in this scenario. Proxy-2 generates the SIP response of 183 Session Progress, and Proxy-2 must insert its URI into Responder with the link to acquire its certification inside Responder-Info. AIB may be generated by Proxy-2 without any encryption. After verifying AIB for Proxy-2's identify, Proxy-1 can propagate the same info back to Alice. Then Alice can verify Responder by herself through AIB and Responder-Info. One variation for TLS is that AIB may be encrypted by Proxy-2 with Proxy-1's certificate. This requires Proxy-1 to decrypt the AIB and verify the identity of Proxy-2 . If the identity is proven Cao & Jennings Expires January 11, 2006 [Page 16] Internet-Draft Response Identity and Authentication July 2005 consistent, Proxy-1 may have to encrypt the AIB again by Alice's public key. Similarly, Alice can verify the identity of the responder. If the verification fails, Proxy-1 may decide what the right follow-up operations are. In some scenarios for providing better secure operations, the proxies may verify the identity of the responder. If the verification indicates the unmatched SIP response identity, the proxies may replace the response code with the 431 Failed Responder Identity for announcing the identity problem as early as possible. If AIB is specified as the verifier-method inside Responder header, AIB inside S/MIME is used to provide the digital signature of the SIP response Identity. The headers used for this purpose should include the minimum set of To, From, Call-ID, CSeq, Date, and Responder. Any additional headers may be put into AIB by the responder. The following example is to illustrate the response from Proxy-2. Proxy-2 adds its identity into AIB. SIP/2.0 100 Trying Via: SIP/2.0/UDP px1.source.com;branch=z9hG4bKnashds8 ;received=127.101.56.17 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 50 Date: Thu, 21 Apr 2005 16:28:56 GMT Responder: claimer=px2@destination.com; verify-method=AIB Responder-Info: https://www.destination.com/certification Content-Type: multipart/mixed; boundary=unique-boundary-1 --unique-boundary-1 Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 3569844526 3569844526 IN IP4 source.com s=Session SDP c=IN IP4 px2.destination.com t=0 0 m=audio 61020 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Cao & Jennings Expires January 11, 2006 [Page 17] Internet-Draft Response Identity and Authentication July 2005 --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary68 Content-Length: 742 --boundary68 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Date: Thu, 21 Apr 2005 16:28:56 GMT Responder: claimer=px2@destination.com; verify-method=AIB --boundary68 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required H77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6vhJhjH776tbB9HG4 T6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnjTrfvbnj756tbB9HG4VQdT hJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4oirDAFqre570 AFAwqoireikf5287REW --boundary42-- --unique-boundary-1-- [*digest needs to be recalculated for this message] It is up to the responder to decide if end-to-end security is needed, which may trigger the encryption of AIB through the public key of the caller. In this case, only the caller can verify the signature of the responder. 11. References 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 Cao & Jennings Expires January 11, 2006 [Page 18] Internet-Draft Response Identity and Authentication July 2005 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-05 (work in progress), May 2005. [4] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", draft-ietf-sipping-certs-01 (work in progress), February 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. Authors' Addresses Feng Cao Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Email: fcao@cisco.com Cao & Jennings Expires January 11, 2006 [Page 19] Internet-Draft Response Identity and Authentication July 2005 Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 902-3341 Email: fluffy@cisco.com Cao & Jennings Expires January 11, 2006 [Page 20] Internet-Draft Response Identity and Authentication July 2005 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 (2005). 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 & Jennings Expires January 11, 2006 [Page 21]