SIP F. Cao, Ed. Internet-Draft Cisco Systems Expires: July 14, 2006 January 10, 2006 Response Identity in Session Initiation Protocol draft-cao-sip-response-identity-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 July 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The mechanism for securely providing responder's identity in response message is missing in the current Session Initiation Protocol. Due to different call scenarios, the exact response identity is hard to guess through the existing response message. This draft describes some extensions for providing SIP response identity and two security mechanisms for verifying the integrity of response identity. It does so by defining new header fields as well as one new response code. Furthermore, the issue of how to require the presence of response identity in one SIP dialog is also discussed with one solution. Cao Expires July 14, 2006 [Page 1] Internet-Draft Response Identity January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Response Identity with DAS . . . . . . . . . . . . . . . . 4 3.2. Response Identity with AIB . . . . . . . . . . . . . . . . 6 3.3. Enforcement on Response Identity . . . . . . . . . . . . . 7 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 4.1. DAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. AIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Enforcement on Response Identity . . . . . . . . . . . . . 9 5. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 9 5.1. DAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. AIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Enforcement on Response Identity . . . . . . . . . . . . . 10 6. Syntax and Examples . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 14 8.2. 431 'Failed Responder Identity Response Code . . . . . . . 15 8.3. One new option tag: responder-id . . . . . . . . . . . . . 15 8.4. One new warn-code: 380 . . . . . . . . . . . . . . . . . . 15 9. Contributors' Address . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informational References . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Cao Expires July 14, 2006 [Page 2] Internet-Draft Response Identity January 2006 1. Introduction This document provides enhancements for addressing security concerns on response messages in Session Initiation Protocol (SIP [1]). Because the mechanism for securely providing responder's identity inside response message is missing in the current SIP, some holes are left open for several kinds of malicious attacks through 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, before the expected response from Proxy-2. Without any security mechanism to verify response identity, Proxy-1 and the initiator of SIP requests will be deceived by the faking response from the rogue proxy. This allows the rogue proxy to conduct malicious 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. 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 before hand. Second, the presence of the exact responder for SIP response is not clearly defined, which is different from From field for SIP request. In general, it is obvious that To field cannot be used as described above. Due to backward compatibility, some other existing header fields, such as Contact and Reply-to, have their own meanings and can not be relied on in all the scenarios. In this document, some extensions are demonstrated to insert the identity of SIP response in response message. Two security mechanisms are outlined to verify the integrity of response identity. One is Domain-based Authentication Service (DAS), the other Authenticated Identity Body (AIB). Furthermore, the issue of how to require the presence of response identity in one SIP dialog is also discussed with one solution. 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 Cao Expires July 14, 2006 [Page 3] Internet-Draft Response Identity January 2006 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]) 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 extensions are introduced to announce the exact response identiy along with the specified security mechanism for verifying it. Both DAS and AIB are analyzed as the security mechanisms. One solution is demonstrated on how to require the presence of response identity in one SIP dialog. 3.1. Response Identity with DAS SIP response identify is crucial for proceeding the dialog and providing the desired services. In the current SIP, 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 clarifying that identify 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: Cao Expires July 14, 2006 [Page 4] Internet-Draft Response Identity January 2006 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=DAS; Responder-Info: https://www.destination.com/certs;alg=rsa-sha1 Identify: akfjiqiowrgnavnvnnfa2o3fafanfkfjakfjalkf203urjafskjfaf Jprqiyupirequqpiruskfka3i91emgiow20mjaf [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 the next section) For DAS, the mechanism is similar to [3]. Some headers, including the new header field introduced in this document, 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 field, Responder, is introduced to specify the exact responder and related authentication method. Responder-Info is another new header field introduced to 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 the new defined reponse code, 431 Failed Responder Identity, for indicating the problem as early as possible. There are some advantages for adopting DAS to address response identity. It satisfies all the requirements listed above. It is based on domain authentication service, which allows the relevant Cao Expires July 14, 2006 [Page 5] Internet-Draft Response Identity January 2006 proxies to insert the response identity on behalf of UA. DAS allows the involved intermediate parties to verify the response identity. This flexibiltiy helps to detect the response identity problem as early as possible and prevent some malicious attacks through response messages. But there is one shortcoming for DAS about its ability for supporting anonymity. As the responder identity has to be clearly put into the header of the response message, there is no way to hide it from all the intermediate parties involved in the same dialog. 3.2. Response Identity with AIB When the responder may not reveal its identity to all the intermediate parties involved in the same dialog, anonymity is desired by the responder to reveal its identiy to its specified parties. AIB is proposed here as the security mechanism to support anonymity in end-to-end scenarios and end-to-middle scenarios. The same example is used here to demonstrate AIB. Alice sends an INVITE request to Bob. Proxy-2 receives the request and informs Alice of the response message, 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; alg=rsa-sha1 "Responder" specifies "AIB" as the security mechanism for verifying response identity. "Responder-Info" provides the links for obtaining the related security parameters for AIB to verify responder identity. The AIB portion in the response message body should cover the minimum set of {To, From, Call-ID, CSeq, Date, Responder}. Any additional headers may be put into AIB by the responder for enhancing the integrity of the response message. It is up to the responder to decide if it wants to hide its identity and who can see its identity. If Proxy-2 decides not to hide its identiy, Proxy-2 can put both "Responder" and "Responder-Info" into response header, and signed the AIB portion by its private keys. Then each party involved in the same dialog is able to check the identity. In this case, either Proxy-1 or Alice can verify the responder identity by obtaining Responder, Responder-Info and AIB portion. Cao Expires July 14, 2006 [Page 6] Internet-Draft Response Identity January 2006 If Proxy-2 wants to hide its identity from intermediate parties, Proxy-2 MUST NOT put "Responder" and "Responder-Info" into response header. Instead, AIB portion inside response message body should be encrypted by the public key (or certificate) of Alice, and signed by Proxy-2's own private key. In this case, only the originator Alice knows the response identity and the way to verify it. Proxy-1 can be prevented from identifying the responder. AIB provides the desired security mechanism for anonymity protection for some responders. But the overhead of insert AIB into the response message is much higher. Another tradeoff is AIB may block the verification of response identity in the intermediate parties, which can delay the earliness of detection on the malicious attacks from rogue parties. End-to-middle security for SIP response needs to be explored in some scenarios. 3.3. Enforcement on Response Identity The initiator of SIP request has to require the response identity for enforcing response indentity in its dialog. One new option tag in "Require:" is defined for this purpose: Require: responder-id In some cases, the relevant proxy might insert this option into SIP request on behalf of the initiator. When receiving SIP request with "Require: responder-id", the responder must provide its identity in its response using the mechanisms introduced in the above sections. One exception is that some policies defined for the responder do not allow its identity to be revealed to the initiator of SIP request. Instead of providing its identity in its response, the responder should use one new warn-code inside "Warning" to give its reason: Warning: 380 Responder Identity Cannot be Revealed In this case, the responder should understand the potential consequence for hiding its identity. The intiator (or the proxy that inserts "Require: responder-id") may not accept the response without the required response identity, and the dialog may be cancelled. 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. Cao Expires July 14, 2006 [Page 7] Internet-Draft Response Identity January 2006 4.1. DAS 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. In this case, UAC should choose to avoid the verification of the responder identity. UAC should treat it as a failure and may terminate the dialog. 4.2. AIB When UAS wants to provide response identity with AIB, UAS must decide if it wants to hide its identity from some intermediate parties involved in the same dialog. If not, UAS can display both "Responder" and "Responder-Info" into response header, choose AIB portion, and sign the AIB portion by its private key inside the response message body. Otherwise, UAS MUST NOT put "Responder" and "Responder-Info" into response header. Instead, AIB portion inserted response message body should be encrypted by the public key (or certificate) of initiator of SIP request, and signed by UAS's own private key. In this case, only the initiator knows the response identity and how to verify it. If UAS wants to reveal its identity to specified proxies involved in the same dialog, end-to-middle security mechanisms can be applied here to embed the encrypted context in S/MIME for those proxies. When it receives the corresponding SIP response, UAC can verify the identify of the responder. For AIB, the certificate of the responder should be obtained to verify the digest of AIB portion inside the response body. UAC may receive the response code 431 Failed Responder Identity. In this case, UAC should choose to avoid the verification of the responder identity. UAC should treat it as a failure and may Cao Expires July 14, 2006 [Page 8] Internet-Draft Response Identity January 2006 terminate the dialog. 4.3. Enforcement on Response Identity UAC of SIP request has to put the new option tag in the request header: Require: responder-id When receiving SIP request with "Require: responder-id", UAS must provide its identity in its response using the mechanisms introduced in the above sections. The exception is that UAS cannot reveal its identity due to the policy control. Instead of providing its identity in its response, UAS should provide its warning through one new warn-code: Warning: 380 Responder Identity Cannot be Revealed When receiving the response without the expected response identity, UAC checks if warning is present. If "Warning: 380 Responder Identity Cannot be Revealed" is inside response header, UAC realizes that responder wants to hide its identity. UAC should decide if it is willing to trust the response and continue the dialog, or terminate the dialog. 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. DAS The proxy server may provide the domain authentication service for 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. 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 should save the response and start Cao Expires July 14, 2006 [Page 9] Internet-Draft Response Identity January 2006 a timer waiting for the response with matched digest. When the timer expires, the proxy should decide what response should be sent back. One option is to modify the saved response by replacing the response code with "431 Failed Responder Identity" for announcing the problem. In some scenarios, the proxy servers may relay the SIP responses without checking the responder identity and modifying any fields including response codes. 5.2. AIB After receiving the SIP response with a new header field Responder, the proxy may find out if AIB is the security mechanism for verifying the responder identity. If yes, the proxy may obtain the certificate of the responder through Responder-Info. The digest can be generated through AIB portion to compare with the one carried inside the response message body. If there is a mismatch, the proxy should save the response and start a timer waiting for the response with matched digest. When the timer expires, the proxy should decide what response should be sent back. One option is to modify the saved response by replacing the response code with "431 Failed Responder Identity" for announcing the problem. In some scenarios, the proxy servers may relay the SIP responses without checking the responder identity and modifying any fields including response codes. If Responder is not present in response message, the proxy may ignore the response identity. In some special scenarios related to end-to- middle security, the proxy may need to look into the message body to figure out if it is allowed to decrypt AIB portion. Once the AIB portion is decrypted, the proxy has to check if Responder is included for response identity verification. If yes, the digest is generated again to compare with the one carried inside the message body. If there is a mismatch, the operations for proxy are similar to the above. 5.3. Enforcement on Response Identity In some scenarios, the relevant proxy may insert "Require: responder-id" into the SIP request asking for the response identity. If the proxy is the reponsder after receiving SIP request with "Require: responder-id", it must provide its identity in its response using the mechanisms introduced in the above sections. The exception is that the proxy cannot reveal its identity due to its policy control. Instead of providing its identity in its response, the proxy should provide its warning through one new warn-code: Cao Expires July 14, 2006 [Page 10] Internet-Draft Response Identity January 2006 Warning: 380 Responder Identity Cannot be Revealed The relevant proxy that inserts "Require: responder-id" should check the response identity inside the response message. If the response provides no response identity, it should check if warning is present. If "Warning: 380 Responder Identity Cannot be Revealed" is inside response header, the proxy realizes that responder wants to hide its identity. it can decide if it is willing to trust the response and continue the dialog, or terminate the dialog. 6. Syntax and Examples 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" / "AIB" / token) Note: token in verify-param can be extended to cover other verification method, such as AIB(See Appendix A in detail). Responder-Info = "Responder-Info" HCOLON responder-info-param responder-info-param = LAQUOT absoluteURI RAQUOT *( SEMI security-param) security-param = "alg" EQUAL token For DAS, the responder's identity is the digest in 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 o the digits and the method from CSeq o Date field o body content of the message with the bits exactly as they are inthe message (in the ABNF for SIP, the message body). In summary, digest-string for Identity header in the SIP response is Cao Expires July 14, 2006 [Page 11] Internet-Draft Response Identity January 2006 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. DAS is specified as the security mechanism. 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;alg=rsa-sha1 Identity: oiurw20984oij12kfqfknrewqfhgahg198431ufadsafafdag32r4189f hafaaafi298r3398i32uip293gDFQqireu904328FQWlkafqroiewrjafaf k189ahffahjf4289981 Content-Length: 0 [*Identity: needs to be recalculated] The AIB portion in the response message body should cover the minimum set of {To, From, Call-ID, CSeq, Date, Responder}. Any additional headers may be put into AIB by the responder for enhancing the integrity of the response message. Another example is to illustrate the response from Proxy-2. Proxy-2 provides its identity through 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 Cao Expires July 14, 2006 [Page 12] Internet-Draft Response Identity January 2006 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; alg=rsa-sha1 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 --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 Cao Expires July 14, 2006 [Page 13] Internet-Draft Response Identity January 2006 --boundary42-- --unique-boundary-1-- [*digest needs to be recalculated for this message] 7. Security Considerations This document provides the extension for SIP response identity along with two security mechanisms for verifgying it. There are some advantages for the proposed mechanisms in this document. The new header fields inside SIP response provide the desired responder identity, and are backward compatible with [1]. Anonymity is also addressed through one security mechanism. These two proposed security mechanisms can be used to detect the rogue response identities and prevent some malicious attacks through SIP responses. When AIB is used for hiding response identity from intermediate parties, end-to-middle security should be explored for allowing some intermediate proxies to check the response identity. Another security concern is about the response authentication. Because the current SIP response relies on TLS and TLS is often absent on many hops, the whole response message may be compromised, let alone the defined response identity in this document. Another internet draft [6] is underway to provide complementary enhancement on SIP response authentication. 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. 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- Cao Expires July 14, 2006 [Page 14] Internet-Draft Response Identity January 2006 registry under http://www.iana.org/assignments/sip-parameters. Header Name: Responder Compact Form: (none) Header Name: Responder-Info 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. One new option tag: responder-id This document registers a new option tag which is described in Section 3.3. It is used when the initiator of SIP request wants the responder to provide its identity. http://www.iana.org/assignments/sip-parameters. Option tag: Name: responder-id Description: responder-id is used by the intiator of SIP request. It asks the responder of that SIP request to provide its identity with its response. 8.4. One new warn-code: 380 This document registers a new warn-code which is described in Section 3.3. It is used when the responder wants to indicate that it is unwilling to reveal its identity after receiving "Require: responder-id" in SIP request. http://www.iana.org/assignments/sip-parameters. Warn-code: Code: 380 Description: Due to its policy control, the responder may not be allowed to reveal its identity. When the SIP request asks for response identity, the responder can give out its warning Cao Expires July 14, 2006 [Page 15] Internet-Draft Response Identity January 2006 by this new code. 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 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 Cao Expires July 14, 2006 [Page 16] Internet-Draft Response Identity January 2006 Identity Body (AIB) Format", RFC 3893, September 2004. [6] Cao, F. and C. Jennings, "Response Authentication in Session Initiation Protocol", draft-cao-sip-response-auth-01 (work in progress), December 2005. [7] Metz, C., "OTP Extended Responses", RFC 2243, November 1997. 11.2. Informational References [8] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [9] 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. [10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. Cao Expires July 14, 2006 [Page 17] Internet-Draft Response Identity January 2006 Author's Address Feng Cao (editor) Cisco Systems 170 West Tasman Drive MS: SJC-09/2 San Jose, CA 95134 USA Phone: +1 408 525-9988 Email: fcao@cisco.com Cao Expires July 14, 2006 [Page 18] Internet-Draft Response Identity 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 19]