SIPNetwork Working Group JariJ. Arkko INTERNET-DRAFT VesaInternet-Draft V. Torvinen <draft-ietf-sip-sec-agree-04.txt> GonzaloExpires: April 28, 2003 G. Camarillo June 2002Ericsson Expires: December 2002 TaoA. Niemi T. Haukka Nokia Sanjoy Sen Nortel NetworksOctober 28, 2002 Security Mechanism Agreement for SIP Sessionsthe Session Initiation Protocol (SIP) draft-ietf-sip-sec-agree-05 Status of this memoMemo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.Internet- Drafts. 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".progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txthttp:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.htmlhttp://www.ietf.org/shadow.html. This document is an individual submission to the IETF. Comments should be directed to the authors.Internet-Draft will expire on April 28, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract SIP has a number of security mechanisms. Some of them have been built in to the SIP protocol, such as HTTP authentication or secure attachments. These mechanisms have even alternative algorithms and parameters. SIP does not currently provide any mechanism for selecting which security mechanisms to use between two entities. In particular, even if some mechanisms such as OPTIONS were used to make this selection, the selection would be vulnerable against the Bidding-Down attack.This document defines three header fieldsnew functionality for negotiating the security mechanisms within SIPused between a SIP entitySession Initiation Protocol (SIP) user agent and its next SIP hop. Anext-hop SIP entity applying this mechanism must always require some minimum security (i.e. integrity protection) from all communicating parties in order to secure the negotiation, butentity. This new functionality supplements the negotiation can agree on which specificexisting methods of choosing security is used. TABLE OF CONTENTSmechanisms between SIP entities. Table of Contents 1. Introduction....................................................2Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Problem.....................................................3 3. Solution........................................................4 3.1. Requirements...............................................4 3.2.Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Overview of Operations.....................................5 3.3. Syntax.....................................................6 3.4.Operation . . . . . . . . . . . . . . . . . . . 4 2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Protocol Operation.........................................7 3.4.1Operation . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Client Initiated........................................7 3.4.2Initiated . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2 Server Initiated........................................8 3.5.Initiated . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Security Mechanism Initiation..............................9 3.6.Initiation . . . . . . . . . . . . . . . 10 2.5 Duration of theSecurity Association......................10 3.7.Associations . . . . . . . . . . . . . 10 2.6 Summary of Header Field Use...............................10 4.Use . . . . . . . . . . . . . . . . 11 3. Backwards Compatibility........................................11 5. Examples.......................................................11 5.1.Compatibility . . . . . . . . . . . . . . . . . . 12 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Client Initiated..........................................10 5.2.Initiated . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Server Initiated..........................................12 5.3.Initiated . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Negotiation between Proxies......................13Considerations . . . . . . . . . . . . . . . . . . 16 6. Security Considerations........................................13 7.IANA Considerations............................................15Considerations . . . . . . . . . . . . . . . . . . . . 17 6.1 Registration Information . . . . . . . . . . . . . . . . . . 18 6.2 Registration Template . . . . . . . . . . . . . . . . . . . 19 6.3 Header Field Names . . . . . . . . . . . . . . . . . . . . . 19 6.4 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 19 6.5 Option Tags . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments................................................15 9.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 Normative References...........................................15 10. Non-Normative References.......................................16 11. AuthorsĘs Addresses............................................16References . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . . 23 Full Copyright Statement . . . . . . . . . . . . . . . . . . 25 1. Introduction Traditionally, security protocols have included facilities to agree on the used mechanisms, algorithms, and other security parameters. The reason for thisThis is that algorithm development typically uncovers problems in old algorithms and sometimes even produces new problems. Furthermore,to add flexibility, since different mechanisms and algorithmsare usually suitable forto different situations. Typically, protocols also select other parameters beyond algorithms atscenarios. Also, the same time. The purposeevolution of this specification is to define a similar negotiation functionality in SIP . SIP has some security functionality built- in (e.g. HTTP Digest authentication ), it can utilize secure attachments (e.g. S/MIME ), and it can also use underlyingsecurity protocols (e.g. IPsec/IKE mechanisms often introduces new algorithms, or TLS ). Someuncovers problems in existing ones, making negotiation of the built-in security functionality allows also alternative algorithms and other parameters. While some work within the SIP Working Group has been looking towards reducing the numbermechanisms a necessity. The purpose of recommended security solutions (i.e., recommend just one lower layer security protocol), we can not expectthis specification is to cut down the number of items indefine negotiation functionality for the whole list to one. There will still be multiple security solutions utilized by SIP. Furthermore, itSession Initiation Protocol (SIP) . This negotiation is likely that new methods will appear in the future,intended to complement the methods that exist today. Chapter 2 shows that withoutwork only between a UA and its first-hop SIP entity. 1.1 Motivations Without a secured method to choose between security mechanisms and/or their parameters, SIP is vulnerable to certain attacks. As the HTTP authentication RFC  points out, authenticationAuthentication and integrity protection using multiple alternative methods and algorithms is vulnerable to Man-in-the-Middle (MitM) attacks. More seriously, itattacks (e.g., see ). It is also hard or sometimes even impossible to know whether a SIP peer entityspecific security mechanism is truly unableunavailable to perform (e.g., Digest, TLS, or S/MIME)a SIP peer entity, or if in fact a MitM attack is in action. In certain small networks consisting of workstations and serversthese issues are not very relevant, as the administrators of such networks can deploy appropriate software versions and set up policies for using exactly the right type of security. However, SIP willis also expected to be deployed to hundreds of millions of small devices with little or no possibilities for coordinated security policies, let alone software upgrades, and this makes these issues much worse. This conclusion is also supported by the requirements from 3GPP . Chapter 6 documentswhich necessitates the proposed solution, and chapter 7 gives some demonstrative examples. 2. Problem Description SIP has alternative security mechanisms such as HTTP authentication with integrity protection, lower layer security protocols, and S/MIME. It is likely that their use will continue inneed for the future. SIP security is developing, and is likelynegotiation functionality to be available from the very beginning of deployment (e.g., see also new solutions). 1.2 Design Goals 1. The entities involved in the future. Deployment of large number of SIP-based consumer devices such as 3GPP terminals requires all network devicessecurity agreement process need to be ablefind out exactly which security mechanisms to accommodate past, current and future mechanisms; there is no possibility for instantaneous change since the new solutions are coming gradually in as new standards and product releases occur. It is sometimes even impossible to upgrade some of the devices without getting completely new hardware. So, the basic security problem that such a large SIP-based network must consider, would be on how do security mechanisms get selected? It would be desirable to take advantage of new mechanisms as they become available in products. Firstly, we need to know somehow what security should be applied, andapply, preferably find this outwithout too manyexcessive additional roundtrips. Secondly,2. The selection of security mechanisms MUSTitself needs to be secure. Traditionally, all security protocols use a secure form of negotiation. For instance, after establishing mutual keys through Diffie-Hellman, IKE sends hashes of the previously sent data --including the offered crypto mechanisms.mechanisms . This allows the peers to detect if the initial, unprotected offers were tampered with. 3. The security implications of this are subtle, but do have a fundamental importance in building large networks that change over time. Given that the hashes are produced also using algorithms agreedentities involved in the first unprotected messages, one could ask what the difference insecurity really is. Assuming integrity protection is mandatory and only secure algorithms are used, we stillagreement process need to prevent MitM attackers from modifying other parameters, such as whether encryption is providedbe able to indicate success or not. Let us first assume two peers capablefailure of using both strong and weak security. Ifthe initial offers aresecurity agreement process. 4. The security agreement process should not protected in any way,introduce any attacker can easily "downgrade" the offers by removing the strong options. This would force the two peersadditional state to use weak security between them. But ifbe maintained by the offers are protectedinvolved entities. 1.3 Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in some way -- suchthis document are to be interpreted as by hashing, or repeating them later when the selected security is really on --described in BCP 14, RFC 2119 . 2. Solution 2.1 Overview of Operation The message flow below illustrates how the situation is different. It would not be sufficient for the attackermechanism defined in this document works: 1. Client ----------client list---------> Server 2. Client <---------server list---------- Server 3. Client ------(turn on security)------- Server 4. Client ----------server list---------> Server 5. Client <---------ok or error---------- Server Figure 1: Security agreement message flow. Step 1: Clients wishing to modifyuse this specification can send a single message. Instead,list of their supported security mechanisms along the attacker would havefirst request to modify both the offer message, as well as the message that containsthe hash/repetition. More importantly,server. Step 2: Servers wishing to use this specification can challenge the attacker would haveclient to forgeperform the weaksecurity that is presentagreement procedure. The security mechanisms and parameters supported by the server are sent along in this challenge. Step 3: The client then proceeds to select the second message, and wouldhighest-preference security mechanism they have to do soin real time between the sent offerscommon and to turn on the later messages. Otherwise, the peers would notice thatselected security. Step 4: The client contacts the hash is incorrect. Ifserver again, now using the attackerselected security mechanism. The server's list of supported security mechanisms is ablereturned as a response to break the weak security,the challenge. Step 5: The server verifies its own list of security method and/ormechanisms in order to ensure that the algorithm shouldoriginal list had not be used. In conclusion,been modified. This procedure is stateless for servers (unless the used security difference is making a trivial attack possible versus demandingmechanisms require the attackerserver to break algorithms. An example of where this has a serious consequence is when a network is first deployed with integrity protection (such as HTTP Digest ),keep some state). The client and then later new devicesthe server lists are added that support also encryption (such as S/MIME ). In this situation, an insecure negotiation procedure allows attackers to trivially force even new devices to use only integrity protection. 3. Solution 3.1 Requirements The solution toboth static (i.e., they do not and cannot change based on the SIP security negotiation problem should haveinput from the following properties: (a) It allowsother side). Nodes may, however, maintain several static lists, one for each interface, for example. Between Steps 1 and 2, the selectionserver may set up a non-self-describing security mechanism if necessary. Note that with this type of security mechanisms, such as lower layer security protocols or HTTP digest. It also allowsthe selection of individual algorithms and parameters whenserver is necessarily stateful. The client would set up the non-self-describing security functions are integrated inmechanism between Steps 2 and 4. 2.2 Syntax We define three new SIP (such asheader fields, namely Security-Client, Security-Server and Security-Verify. The notation used in the case of HTTP authentication). (b) It allows next-hop security negotiation. (c) It is secure (i.e., preventsAugmented BNF definitions for the bidding down attack.) (d) It is capable of running without additional roundtrips. Thissyntax elements in this section is importantas used in the cellular environment, where link delays are relatively high,SIP , and an additional roundtrip could delay the call set up further. (e) It does not introduceany additional state to servers and proxies. Currently, SIP doeselements not have any mechanism which fulfills all the requirements above. The basic SIP features suchdefined in this section are as OPTIONSdefined in SIP and Require, Supported headers are capable of informing peers about various capabilities including security mechanisms. However,the straight forward use of these features can not guarantee a secured agreement. HTTP Digest algorithm lists  are not secure for picking among the digest integrity algorithms, as is described in the HTTP authentication RFC  itself. More seriously, they have no provisions for allowing encryptiondocuments to be negotiated. Hence,which it would be hard to turn on possible future encryption schemes in a secure manner. A self-describing security mechanismrefers: security-client = "Security-Client" HCOLON sec-mechanism *(COMMA sec-mechanism) security-server = "Security-Server" HCOLON sec-mechanism *(COMMA sec-mechanism) security-verify = "Security-Verify" HCOLON sec-mechanism *(COMMA sec-mechanism) sec-mechanism = mechanism-name *(SEMI mech-parameters) mechanism-name = ( "digest" / "tls" / "ipsec-ike" / "ipsec-man" / token ) mech-parameters = ( preference / digest-algorithm / digest-qop / digest-verify / extension ) preference = "q" EQUAL qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) digest-algorithm = "d-alg" EQUAL token digest-qop = "d-qop" EQUAL token digest-verify = LDQUOT 32LHEX RDQUOT extension = generic-param Note that qvalue is a security mechanism that, when used, contains all necessary information aboutalready defined in the method being used as well as all ofSIP BNF . We have copied its definitions here for completeness. The parameters such as algorithms. A non-self-describing security mechanism is a security mechanism that, when used, requires that the use ofdescribed by the method or some of its parametersBNF above have been agreed beforehand. Most security mechanisms used with SIP are self-describing. The use of HTTP digest, as well asthe chosen algorithm is visible fromfollowing semantics: Mechanism-name This token identifies the HTTP authentication headers. The use of S/MIME is indicatedsecurity mechanism supported by the MIME headers, and the CMS structures inside S/MIME describe the used algorithms. TLS is run onclient, when it appears in a separate portSecurity-Client header field; or by the server, when it appears in SIP, and where IPsec/IKE is used, IKE negotiates all the necessary parameters.a Security-Server or in a Security- Verify header field. The only exception to this list ismechanism-name tokens are registered with the use ofIANA. This specification defines four values: * "tls" for TLS . * "digest" for HTTP Digest . * "ipsec-ike" for IPsec with IKE . * "ipsec-man" for manually keyed IPsec.IPsec headers do not contain information aboutwithout IKE. Preference The "q" value indicates a relative preference for the used algorithms. Furthermore, peersparticular mechanism. The higher the value the more preferred the mechanism is. All the security mechanisms MUST have different "q" values. It is an error to set up IPsec Security Associations before they can be used to receive traffic. In contrast S/MIME can be received even if no Security Association was in place, becauseprovide two mechanisms with the application can searchsame "q" value. Digest-algorithm This optional parameter is defined here only for a Security Association (or create a new one) after having received a message that contains S/MIME. InHTTP Digest  in order to make it possible to negotiate both self-describing and non-self-describing security mechanisms, we need another requirement onprevent the security agreement scheme: (f)bidding-down attack for the HTTP Digest algorithm parameter. The security agreement scheme must allow both sides to decide oncontent of the desired security mechanism before it is actually used. This decision can, and must, take place on both sides before we can be sure thatfield may have same values as defined in  for the negotiation has not been tampered by a man-in-the- middle."algorithm" field. Digest-qop This tampering will be detected later. 3.2. Overview of Operationsoptional parameter is defined here only for HTTP Digest  in order to prevent the bidding-down attack for the HTTP Digest qop parameter. The message flow below illustrates howcontent of the mechanismfield may have same values as defined in this document works: 1. Client ----------client list---------> Server 2. Client <---------server list---------- Server 3. Client ------(turn on security)------- Server 4. Client ----------server list---------> Server 5. Client <---------ok or error---------- Server Figure 1: Security negotiation message flow Step 1: Clients wishing to use this specification can send a list of their supported security mechanisms along the first request to for the server. Step 2: Servers wishing"qop" field. Digest-verify This optional parameter is defined here only for HTTP Digest  in order to use this specification can challengeprevent the client to performbidding-down attack for the SIP security mechanism agreement procedure.(this document). The security mechanisms and parameters supported bycontent of the server are sent alongfield is counted exactly the same way as "request-digest" in this challenge. Step 3: The client then proceeds to select except that the highest-preference security mechanism they haveSecurity-Server header field is included in common and to turn onthe selected security. Step 4: The client contactsA2 parameter. If the server again, now using"qop" directive's value is "auth" or is unspecified, then A2 is: A2 = Method ":" digest-uri-value ":" security-server If the selected security mechanism. The server's list of supported security mechanisms"qop" value is returned as"auth-int", then A2 is: A2 = Method ":" digest-uri-value ":" H(entity-body) ":" security-server All linear white spaces in the Security-Server header field MUST be replaced by a response tosingle SP before calculating or interpreting the challenge. Step 5: The server verifies its own list of security mechanismsdigest-verify parameter. Method, digest-uri-value, entity-body, and any other HTTP Digest parameter are as specified in order to ensure. Note that the original list hadthis specification does not been modified.introduce any extension or change to HTTP Digest . This procedure is stateless for servers (unlessspecification only re-uses the used securityexisting HTTP Digest mechanisms require the serverto keep some state). The client andprotect the server lists are both static (i.e., they do not and cannot change based on the input from the other side). Nodes may, however, maintain several static lists, one for each interface, for example. Between Steps 1 and 2, the server may set up a non-self-describing security mechanism if necessary. Note that with this typenegotiation of security mechanisms, the server is necessarily stateful. The client would set up the non-self-describing security mechanismmechanisms between Steps 2 and 4. 3.3. Syntax We define three newSIP header fields, namely Security-Client, Security-Server and Security-Verify. Their BNF syntax is provided below: security-client = "Security-Client" HCOLON sec-mechanism *(COMMA sec-mechanism) security-server = "Security-Server" HCOLON sec-mechanism *(COMMA sec-mechanism) security-verify = "Security-Verify" HCOLON sec-mechanism *(COMMA sec-mechanism) sec-mechanism = mechanism-name *(SEMI mech-parameters) mechanism-name = ( "digest-integrity" / "tls" / "ipsec-ike" / "ipsec-man" / "smime" / token ) mech-parameters = ( preference / algorithm / extension ) preference = "q" EQUAL qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) algorithm = "alg" EQUAL token extension = generic-param Note that qvalue is already definedentities. 2.3 Protocol Operation This section deals with the protocol details involved in the negotiation between a SIP BNF . We have copiedUA and its definitions here for completeness. The parameters described bynext-hop SIP entity. Throughout the BNF above havetext the following semantics: Mechanism-name: It identifiesnext-hop SIP entity is referred to as the security mechanism supported byfirst-hop proxy or outbound proxy. However, the client, when it appearsreader should bear in mind that a Security-Client header fields, or byuser agent server can also be the server, when it appears innext-hop for a Security-Server or inuser agent client. 2.3.1 Client Initiated If a Security-Verify header field. This specification defines five values: - "tls" for TLS . - "digest-integrity" for HTTP Digest  using additional integrity protection for the Security-Verify header field. The additional integrity protection consists ofclient ends up using the qop parameterTLS to protect a MIME body (e.g., "message/sip") that contains the Security-Verify header field. - "ipsec-ike" for IPsec with IKE . - "ipsec-man" for manually keyed IPsec without IKE. - "smime" for S/MIME . Preference: The "q" value indicates a relative preference forcontact the particular mechanism. The higher the value the more preferredserver because it has followed the mechanism is. Allrules specified in , the security mechanismsclient MUST have different "q" values. It is an error to provide two mechanisms withNOT use the same "q" value. Algorithm: An optional algorithm field for thosesecurity mechanisms which are not self-describing or which are vulnerable for bidding-down attacks (e.g., HTTP Digest). In the caseagreement procedure of this specification. If a client ends up using non-TLS connections because of HTTP Digest,the samerules apply as definedin RFC 2617  for, the "algorithm" field in HTTP Digest. 3.4. Protocol Operation This section deals withclient MAY use the protocol details involved insecurity agreement of this specification to detect DNS spoofing, or to negotiate some other security than TLS. A client wishing to use the negotiation betweensecurity agreement of this specification MUST add a SIP entity andSecurity-Client header field to a request addressed to its next-hop SIP entity. Throughoutfirst-hop proxy (i.e., the textdestination of the next-hop SIP entityrequest is referred to as the first-hop proxy or outbound proxy. However,the reader should bear in mind that a user agent server can also be the next-hop for a proxy or, in absence of proxies, for a user agent client. Note as well that a proxy can also have an outbound proxy. 3.4.1 Client Initiated A client wishing to establish some type of security with its first- hop proxy MUST add a Security-Client header field to a request addressed to this proxy (i.e., the destination of the request is the first-hop proxy). This header field containsfirst- hop proxy). This header field contains a list of all the security mechanisms that the client supports. The client SHOULD NOT add preference parameters to this list. The client MUST add both a Require and Proxy-Require header field with the value "sec-agree" to its request. The contents of the Security-Client header field ismay be used by the server to include any necessary information in its response. For example, if digest- integrity is the chosen mechanism, the server includes an HTTP authentication challenge in the response. If S/MIME is chosen, the appropriate certificate is included.A server receiving an unprotected request that contains a Require or Proxy-Require header field with the value "sec-agree" MUST challengerespond to the client with a 494 (Security Agreement Required) response. The server MUST add a Security-Server header field to this response listing the security mechanisms that the server supports. The server MUST add its list to the response even if there are no common security mechanisms in the client's and server's lists. The serverĘsserver's list MUST NOT depend on the contents of the client's list. The server MUST compare the list received in the Security-Client header field with the list to be sent in the Security-Server header field. When the client receives this response, it will choose the common security mechanism with the highest "q" value. Therefore, the server MUST add the necessary information so that the client can initiate that mechanism (e.g., a WWW-AuthenticateProxy-Authenticate header field for digest-integrity).HTTP Digest). When the client receives a response with a Security-Server header field, it MUST choose the security mechanism in the serverĘsserver's list with the highest "q" value among all the mechanisms that are known to the client. Then, it MUST initiate that particular security mechanism as described in Section 3.5. This initiation may be carried out without involving any SIP message exchange (e.g., establishing a TLS connection). If an attacker modified the Security-Client header field in the request, the server may not include in its response the information needed to establish the common security mechanism with the highest preference value (e.g., the WWW-authenticateProxy-Authenticate header field is missing). A client detecting such a lack of information in the response MUST consider the current security negotiationagreement process aborted, and MAY try to start it again by sending a new request with a Security-Client header field as described above. All the subsequent SIP requests sent by the client to that server SHOULD make use of the security mechanism initiated in the previous step. These requests MUST contain a Security-Verify header field that mirrors the serverĘsserver's list received previously in the Security-ServerSecurity- Server header field. These requests MUST also have both a Require and Proxy- Require header fields with the value "sec-agree". The server MUST check that the security mechanisms listed in the Security-Verify header field of incoming requests correspond to its static list of supported security mechanisms. Note that, following the standard SIP header field comparison rules defined in , both lists have to contain the same security mechanisms in the same order to be considered equivalent. In addition, for each particular security mechanism, its parameters in both lists need to have the same values. The server can proceed processing a particular request if, and only if, the list was not modified. If modification of the list is detected, the server MUST challengerespond to the client with a 494 (Security Agreement Required).Required) response. This response MUST include a challenge withthe server's unmodified list of supported security mechanisms. If the list was not modified, and the server is a proxy, it MUST remove the "sec-agree" value from both the Require and Proxy-Require header fields, and then remove the header fields if no values remain. Once the security has been negotiated between two SIP entities, the same SIP entities MAY use the same security when communicating with each other in different SIP roles. For example, if a UAC and its outbound proxy negotiate some security, they may try to use the same security for incoming requests (i.e., the UA will be acting as a UAS). The user of a UA SHOULD be informed about the results of the security mechanism negotiation.agreement. The user MAY decline to accept a particular security mechanism, and abort further SIP communications with the peer. 220.127.116.11.2 Server Initiated A server decides to use the security negotiationagreement described in this document based on local policy. If a server receives a request from the network interface that is configured to use this mechanism, it must check that the request has only one Via header field. If there are several Via header fields, the server is not the first-hop SIP entity, and it MUST NOT use this mechanism. For such a request, the server must return a 502 (Bad Gateway) response. A server that decides to use this negotiationagreement mechanism MUST challenge unprotected requests with one Via header field regardless of the presence or the absence of any Require, Proxy-Require or Supported header fields in incoming requests. A server that by policy requires the use of this specification and receives a request that does not have the sec-agree option tag in a Require, Proxy-Require or Supported header field MUST return a 421 (Extension Required) response. If the request had the sec-agree option tag in a Supported header field, it MUST return a 494 (Security Agreement Required) response. In both situation the server MUST also include in the response a Security-Server header field listing its capabilities and a Require header field with an option- tag "sec-agree" in it. All the Via header field entries in the response except the topmost valueThe server MUST be removed. This ensuresalso add necessary information so that the previous hop is the one processingclient can initiate the response (see example in Section 5.3).preferred security mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest). Clients that support the extension defined in this document MAY add a Supported header field with a value of "sec-agree". In addition to this, clients SHOULD add a Security-Client header field so that they can save a round trip in case the server decides to challenge the request. 3.5. Security mechanism initiation Once the client chooses2.4 Security Mechanism Initiation Once the client chooses a security mechanism from the list received in the Security-Server header field from the server, it initiates that mechanism. Different mechanisms require different initiation procedures. If TLS"tls" is chosen, the client uses the procedures of Section 8.1.2 of  toto determine the URI to be used as an input to the DNS procedures of .. However, if the URI is a sipSIP URI, it MUST treat the scheme as if it were sips, not sip. If the URI scheme is not sip, the request MUST be sent using TLS. If digest-integrity"digest" is chosen, the 494 (Security Agreement Required) response will contain an HTTP Digest authentication challenge. The client MUST use the algorithm and qop parameter to protect a MIME body (e.g., "message/sip") that containsparameters in the Security-VerifySecurity-Server header field to replace the same parameters in the request. Currently, onlyHTTP Digest challenge. The client MUST also use the qop value Ęauth-intĘ is abledigest-verify parameter to provide required protection. Note that digest alone without placing Security- Verifyprotect the Security-Server header field as specified in the body would not fulfill the minimum security requirements of this specification.2.2. To use "ipsec-ike", the client attempts to establish an IKE connection to the host part of the Request-URI in the first request to the server. If the IKE connection attempt fails, the agreement procedure MUST be considered to have failed, and MUST be terminated. Note that "ipsec-man" will only work if the communicating SIP entities know which keys and other parameters to use. It is outside the scope of this specification to describe how this information can be made known to the peers. All rules for minimum implementations, such as mandatory-to-implement algorithms, apply as defined in , , and . In both IPsec-based mechanisms, it is expected that appropriate policy entries for protecting SIP have been configured or will be created before attempting to use the security agreement procedure, and that SIP communications use port numbers and addresses according to these policy entries. It is outside the scope of this specification to describe how this information can be made known to the peers, but it could bewould typically be configured at the same time as the IKE credentials or manual SAs have been entered. To use S/MIME, the client MUST construct its request using S/MIME. The client may have received the serverĘs certificate in an S/MIME body in the 494 (Security Agreement Required) response. Note that S/MIME can only be used if the next hop SIP entity is a UA. 18.104.22.168 Duration of Security Associations Once a security mechanism has been negotiated, both the server and the client need to know until when it can be used. All the mechanisms described in this document have a different way to signalof signaling the end of a security association. When TLS is used, the termination of the connection indicates that a new negotiation is needed. IKE negotiates the duration of a security association. If the credentials provided by a client using digest-integritydigest are notno longer valid, the server will re-challengere- challenge the client. It is assumed that when IPsec-man is used, the same out-of-band mechanism used to distribute keys is used to define the duration of the security association. 22.214.171.124 Summary of Header Field Use The header fields defined in this document may be used to negotiate the security mechanisms between a UAC and other SIP entities including UAS, proxy, and registrar. Information about the use of headers in relation to SIP methods and proxy processing is summarized in Table 1. Header field where proxy ACK BYE CAN INV OPT REG _________________________________________________________________ Security-Client R ard - o - o o o Security-Server 401,407,421,494421,494 - o - o o o Security-Verify R ard - o - o o o Header field where proxy SUB NOT PRK IFO UPD MSG _________________________________________________________________ Security-Client R ard o o - o o o Security-Server 401,407,421,494421,494 o o - o o o Security-Verify R ard o o - o o o Table 1: Summary of header usage.Header Usage. The "where" column describes the request and response types in which the header field may be used. The header may not appear in other types of SIP messages. Values in the where column are: -o R: Header field may appear in requests. - 401, 407 etc.:o 421, 494: A numerical value or rangeindicates response codes with which the header field can be used. The "proxy" column describes the operations a proxy may perform on a header field: -o a: A proxy can add or concatenate the header field if not present. -o r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. -o d: A proxy can delete a header field value. The next six columns relate to the presence of a header field in a method: -o o: The header field is optional. 4.3. Backwards Compatibility The use of this extension in a network interface is a matter of local policy. Different network interfaces may follow different policies, and consequently the use of this extension may be situational by nature. UA and server implementations MUST be configurable to operate with or without this extension. A server that, by local policy, decidesthat is configured to use the negotiation mechanism defined inthis document, will notmechanism, may also accept requests from clients that use TLS based on the rules defined in . Requests from clients that do not support this extension.extension, and do not support TLS, can not be accepted. This obviously breaks interoperability with every plainsome SIP client.clients. Therefore, this extension should be used in environments where it is somehow ensured that every client implements this extension.extension or is able to use TLS. This extension may also be used in environments where insecure communication is not acceptable if the option of not being able to communicate is also accepted. 5.4. Examples The following examples illustrate the use of the mechanism defined above. 126.96.36.199 Client Initiated A UA negotiates the security mechanism to be used with its outbound proxy without knowing beforehand which mechanisms the proxy supports. The OPTIONS method can be used here to request the security capabilities of the proxy. In this way, the security can be initiated even before the first INVITE is sent via the proxy. UAC Proxy UAS | | | |----(1) OPTIONS---->| | | | | |<-----(2) 494-------| | | | | |<=======TLS========>| | | | | |----(3) INVITE----->| | | |----(4) INVITE--->| | | | | |<---(5) 200 OK----| |<---(6) 200 OK------| | | | | |------(7) ACK------>| | | |-----(8) ACK----->| | | | | | | | | | | | | Figure 2: Negotiation initiatedInitiated by the clientClient. The UAC sends an OPTIONS request to its outbound proxy, indicating at the same time that it is able to negotiate security mechanisms and that it supports TLS and digest-integrity (Step 1 of figure 1).HTTP Digest (1). The outbound proxy challengesresponds to the UAC with its own list of security mechanisms ū- IPsec and TLS (Step 2 of figure 1).(2). The only common security mechanism is TLS, so they establish a TLS connection between them (Step 3 of figure 1).them. When the connection is successfully established, the UAC sends an INVITE request over the TLS connection just established (Step 4 of figure 1).(3). This INVITE contains the serverĘsserver's security list. The server verifies it, and since it matches its static list, it processes the INVITE and forwards it to the next hop. If this example was run without Security-Server header in Step 2, the UAC would not know what kind of security the other one supports, and would be forced to error-prone trials. More seriously, if the Security-Verify was omitted in Step 4,3, the whole process would be prone for MitM attacks. An attacker could spoof "ICMP Port Unreachable" message on the trials, or remove the stronger security option from the header in Step 1, therefore substantially reducing the security. (1) OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tls Security-Client: digest-integritydigest Require: sec-agree Proxy-Require: sec-agree (2) SIP/2.0 494 Security Agreement Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2 (3) INVITE sip:proxy.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 Route: sip:email@example.com Require: sec-agree Proxy-Require: sec-agree The 200 OK response (6) for the INVITE and the ACK (7) are also sent over the TLS connection. The ACK (7)will contain the same Security-VerifySecurity- Verify header field as the INVITE (3). 188.8.131.52 Server Initiated In this example of figure 3 the client sends an INVITE towards the callee using an outbound proxy. This INVITE does not contain any Require header field. UAC Proxy UAS | | | |-----(1) INVITE---->| | | | | |<-----(2) 421-------| | | | | |------(3) ACK------>| | | | | |<=======IKE========>| | | | | |-----(4) INVITE---->| | | |----(5) INVITE--->| | | | | |<---(6) 200 OK----| |<----(7) 200 OK-----| | | | | |------(8) ACK------>| | | |-----(9) ACK----->| | | | | | | Figure 3: Server initiated security negotiationInitiated Security Negotiation. The proxy, following its local policy, challengesdoes not accept the INVITE. It returns a 421 (Extension Required) with a Security-Server header field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE it performs the key exchange and establishes a security association with the proxy. The second INVITE (4) and the ACK (8) contain a Security-Verify header field that mirrors the Security-Server header field received in the 421. The INVITE (4), the 200 OK (7) and the ACK (8) are sent using the security association that has been established. 5.3 Security Negotiation between Proxies The example in Figure 4 shows a security negotiation between two adjacent proxies. P1 forwards an(1) INVITE sip:uas.example.com SIP/2.0 (2) to P2. P2, by policy, requires that a security negotiation takes place before accepting any request. Therefore, it challenges P1 with aSIP/2.0 421 (Extension Required) response (3). P2 removes all the Via entries except the topmost one (i.e., P1) so that P1 itself processes the response rather than forwardingExtension Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2 (4) INVITE sip:uas.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 5. Security Considerations This specification is about making it possible to the UAC. This 421 response contains a Security- Server header field listing the server's capabilities and a Require header field with an option-tag "sec-agree" in it. P2 includes "TLS" and "ipsec-ike"select between various SIP security mechanisms in a secure manner. In particular, the Security-Server header field. P1 sends an ACK (4)method presented herein allow current networks using, for the response and proceedsinstance, HTTP Digest, to establishbe securely upgraded to, for instance, IPsec without requiring a TLS connection, sincesimultaneous modification in all equipment. The method presented in this specification is thesecure only security mechanism supported by P1. Onceif the TLS connection is established, session establishment proceeds normally. Messages (5), (8)weakest proposed mechanism offers at least integrity and (11) are sent usingreplay protection for the just established TLS connection. Messages (5) and (11) contain a Security- VerifySecurity-Verify header fieldfield. The security implications of this are subtle, but do have a fundamental importance in building large networks that change over time. Given that P2 removes before forwarding them tothe UAS. Note that, following normal SIP procedures, P1 uses a different branch ID for INVITE (5) thanhashes are produced also using algorithms agreed in the first unprotected messages, one it used for INVITE (2). UAC P1 P2 UAS | | | | |-(1) INVITE->| | | | |-(2) INVITE->| | | | | | | |<--(3) 421---| | | | | | | |---(4) ACK-->| | | | | | | |<====TLS====>| | | | | | | |-(5) INVITE->| | | | |-(6) INVITE->| | | | | | | |<-(7) 200 OK-| | |<-(8) 200 OK-| | |<-(9) 200 OK-| | | | | | | |--(10) ACK-->| | | | |--(11) ACK-->| | | | |--(12) ACK-->| | | | | Figure 4: Negotiation between two proxies 6. Security Considerations This specification is about making it possible to select between various SIP security mechanisms in a secure manner. In particular,could ask what the method presented here allow current networks using, for instance, Digest, to be securely upgraded to, for instance, IPsec without requiring a simultaneous modification in all equipment. The method presenteddifference in this specificationsecurity really is. Assuming integrity protection is securemandatory and only if the weakest proposed mechanism offers at least integrity protection. Attackers could trysecure algorithms are used, we still need to modifyprevent MitM attackers from modifying other parameters, such as whether encryption is provided or not. Let us first assume two peers capable of using both strong and weak security. If the server's listinitial offers are not protected in any way, any attacker can easily "downgrade" the offers by removing the strong options. This would force the two peers to use weak security between them. But if the offers are protected in some way -- such as by hashing, or repeating them later when the selected security is really on -- the situation is different. It would not be sufficient for the attacker to modify a single message. Instead, the attacker would have to modify both the offer message, as well as the message that contains the hash/ repetition. More importantly, the attacker would have to forge the weak security that is present in the second message, and would have to do so in real time between the sent offers and the later messages. Otherwise, the peers would notice that the hash is incorrect. If the attacker is able to break the weak security, the security method and/ or the algorithm should not be used. In conclusion, the security difference is making a trivial attack possible versus demanding the attacker to break algorithms. An example of where this has a serious consequence is when a network is first deployed with integrity protection (such as HTTP Digest ), and then later new devices are added that support also encryption (such as TLS ). In this situation, an insecure negotiation procedure allows attackers to trivially force even new devices to use only integrity protection. Possible attacks against the security agreement include: 1. Attackers could try to modify the server's list of security mechanisms in the first response. This would be revealed to the server when the client returns the received list using the security. 2. Attackers could also try to modify the repeated list in the second request from the client. However, if the selected security mechanism uses encryption this may not be possible, and if it uses integrity protection any modifications will be detected by the server. 3. Attackers could try to modify the client's list of security mechanisms in the first message. The client selects the security mechanism based on its own knowledge of its own capabilities and the server's list, hence the client's choice would be unaffected by any such modification. However, the server's choice could still be affected as described below: * If the modification affected the server's choice, the server and client would end up choosing different security mechanisms in Step 3 or 4 of figure 1. Since they would be unable to communicate to each other, this would be detected as a potential attack. The client would either retry or give up in this situation. * If the modification did not affect the server's choice, there's no effect. 4. Finally, attackers may also try to reply old security agreement messages. Each security mechanism must provide replay protection. In particular, HTTP Digest implementations should carefully utilize existing reply protection options such as including a time-stamp to the nonce parameter, and using nonce counters . All clients that implement this specification MUST select HTTP Digest, TLS, IPsec, or any stronger method for the protection of the second request. 6. IANA Considerations This specification defines a new mechanism-name namespace in Section 2.2 which requires a central coordinating body. The body responsible for this coordination is the Internet Assigned Numbers Authority (IANA). This document defines four mechanism-names to be initially registered, namely "digest", "tls", "ipsec-ike", and "ipsec-man". In addition to these mechanism-names, "ipsec-3gpp" mechanism-name is also registered (see Appendix A). Following the policies outlined in , further mechanism-names are allocated based on IETF Consensus. Registrations with the IANA MUST include the mechanism-name token being registered, and a pointer to a published RFC describing the details of the corresponding security mechanism. Further, the registration MUST include contact information for the party responsible for the registration. 6.1 Registration Information As this document specifies five mechanism-names, the initial IANA registration for mechanism-names will contain the information shown in Table 2. It also demonstrates the type of information maintained by the IANA. Mechanism Name Contact Reference -------------- ------- --------- digest  [RFCNNNN] tls  [RFCNNNN] ipsec-ike  [RFCNNNN] ipsec-man  [RFCNNNN] ipsec-3gpp  [RFCNNNN] People ------  Jari Arkko <Jari.Arkko@ericsson.com> Vesa Torvinen <Vesa.Torvinen@ericsson.fi> Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Aki Niemi <Aki.Niemi@nokia.com> Tao Haukka <Tao.Haukka@nokia.com> References ---------- [RFCNNNN] Arkko, et. al., "Security Mechanism Agreement for the Session Initiation Protocol", RFC NNNN, October 2002. Table2: Initial IANA registration. (Note to RFC Editor: Replace NNNN with the RFC number of this document when published.) 6.2 Registration Template To: firstname.lastname@example.org Subject: Registration of a new SIP Security Agreement mechanism Mechanism Name: (Token value conforming to the syntax described in Section 2.2.) Published Specification(s): (Descriptions of new SIP Security Agreement mechanisms require a published RFC.) Person & email address to contact for further information: (Must contain contact information for the person(s) responsible for the registration.) 6.3 Header Field Names This specification registers three new header fields, namely Security-Client, Security-Server and Security-Verify. These headers are defined by the following information, which is to be included inthe sub-registry for SIP headers under http://www.iana.org/ assignments/sip-parameters. Header Name: Security-Client Compact Form: (none) Header Name: Security-Server Compact Form: (none) Header Name: Security-Verify Compact Form: (none) 6.4 Response Codes This specification registers a new response code, namely 494 (Security Agreement Required). The response code is defined by the following information, which is to be included to the sub-registry for SIP methods and response-codes under http://www.iana.org/ assignments/sip-parameters. Response Code Number: 494 Default Reason Phrase: Security Agreement Required 6.5 Option Tags This specification defines a new option tag, namely sec-agree. The option tag is defined by the following information, which is to be included in the sub-registry for option tags under http:// www.iana.org/assignments/sip-parameters. Name: sec-agree Description: This option tag indicates support for the Security Agreement mechanism. When used in the Require, or Proxy-Require headers, it indicates that proxy servers are required to use the Security Agreement mechanism. When used in the Supported header, it indicates that the User Agent Client supports the Security Agreement mechanism. When used in the Require header in the 494 (Security Agreement Required) or 421 (Extension Required) responses, it indicates that the User Agent Client must use the Security Agreement Mechanism. 7. Contributors Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to the document. 8. Acknowledgements In addition to the contributors, the authors wish to thank Allison Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia, Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP SA3 group for interesting discussions in this problem space. Normative References  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.  Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Informative References  Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", draft-ietf-sipping-3gpp-r5-requirements-00 (work in progress), October 2002.  3rd Generation Partnership Project, "Access security for IP- based services, Release 5", TS 33.203 v5.3.0, September 2002.  Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. Authors' Addresses Jari Arkko Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland Phone: +358 40 507 9256 EMail: email@example.com Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland Phone: +358 40 723 0822 EMail: firstname.lastname@example.org Gonzalo Camarillo Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland Phone: +358 40 702 3535 EMail: email@example.com Aki Niemi Nokia P.O. Box 301 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: firstname.lastname@example.org Tao Haukka Nokia P.O. Box abc NOKIA GROUP, FIN 00045 Finland Phone: +358 40 517 0079 EMail: email@example.com Appendix A. Syntax of security mechanisms in the first response.ipsec-3gpp This would be revealed to the server whenappendix specifies the client returns the received list using the security. Attackers could also trysyntax of non-normative parameters to modify the repeated listbe used in the second request from the client. However, if the selected3GPP IP Multimedia Subsystem  with security mechanism uses encryption this may not be possible, and if it uses integrity protection any modifications will be detected by"ipsec-3gpp". The notation used in the server. Finally, attackers could tryAugmented BNF definitions is as used in SIP . mechanism-name = ( "ipsec-3gpp" ) mech-parameters = ( algorithm / protocol /mode / encrypt-algorithm / spi / port1 / port2 ) algorithm = "alg" EQUAL ( "hmac-md5-96" / "hmac-sha-1-96" ) protocol = "prot" EQUAL ( "ah" / "esp" ) mode = "mod" EQUAL ( "trans" / "tun" ) encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" ) spi = "spi" EQUAL spivalue spivalue = 10DIGIT; 0 to modify4294967295 port1 = "port1" EQUAL port port2 = "port2" EQUAL port port = 1*DIGIT The parameters described by the client's list of security mechanisms inBNF above have the first message. The client selectsfollowing semantics: Algorithm This parameter defines the security mechanism based on its own knowledgeused authentication algorithm. It may have a value of its own capabilities and"hmac-md5-96" for HMAC-MD5-96 , or "hmac-sha- 1-96" for HMAC-SHA-1-96 . The algorithm parameter is mandatory. Protocol This parameter defines the server's list, henceIPsec protocol. It may have a value of "ah" for AH , or "esp" for ESP . If no Protocol parameter is present, the client's choice wouldprotocol will be unaffectedESP by any such modification. However,default. Mode This parameter defines the server's choice could still be affected as described below: -mode in which the IPsec protocol is used. It may have a value of "trans" for transport mode, or a value of "tun" for tunneling mode. If no Mode parameter is present the modification affected the server's choice,the server and client would end up choosing different security mechanismsIPsec protocol is used in Step 3 or 4 of figure 1. Since they would be unable to communicate to each other, this would be detected astransport mode. Encrypt-algorithm This parameter defines the used encryption algorithm. It may have a potential attack. The client would either retryvalue of "des-ede3-cbc" for 3DES , or give up in this situation. -"null" for no encryption. If the modification didno Encrypt-algorithm parameter is present, encryption is not affectused. Spi Defines the server's choice, there'sSPI number used for inbound messages. Port1 Defines the port number for inbound messages. Port2 Defines the port number for outbound messages. If no effect. All clientsPort2 parameter is present port1 is also used for outbound messages. The communicating SIP entities need to know beforehand which keys to use. It is also assumed that implement this specification MUST select HTTP Digestthe underlying IPsec implementation supports selectors that allow all transport protocols supported by SIP to be protected with integrity, TLS, IPsec, or any stronger method fora single SA. The duration of security association is the protectionsame as in the expiration interval of the second request. 7. IANA Considerationscorresponding registration binding. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This specification defines three new header fields, namely Security- Client, Security-Serverdocument and Security-Verify that shouldtranslations of it may be includedcopied and furnished to others, and derivative works that comment on or otherwise explain it or assist in the registry for SIP header fields maintained by IANA. This specification defines the 'sec-agree' SIP option tag which shouldits implementation may be registeredprepared, copied, published and distributed, in IANA. This specification also defines a new SIP status code, 494 (Security Agreement Failed), which shouldwhole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be registeredmodified in IANA. 8. Acknowledgments The authors wishany way, such as by removing the copyright notice or references to thank Lee Valerius, Allison Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin Euchner, Eric Rescorla and members ofthe 3GPP SA3 groupInternet Society or other Internet organizations, except as needed for interesting discussions in this problem space. 9. Normative References  J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Protocol", Workthe purpose of developing Internet standards in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, February 2002.  S. Kent, R. Atkinson, "Security Architecturewhich case the procedures for copyrights defined in the Internet Protocol", RFC 2401, IETF, November 1998.  T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, IETF January 1999.  Franks, J. et al, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, IETF, June 1999.  B. RamsdellStandards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and Ed, "S/MIME version 3 message specification", RFC 2633, IETF, June 1999.  H. Schulzrinnewill not be revoked by the Internet Society or its successors or assigns. This document and J. Rosenberg, "SIP: Locating SIP servers", Work in Progress, draft-ietf-sip-srv-06.txt, IETF, February 2002. 10. Non-Normative References  M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirementsthe information contained herein is provided on SIP", draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, October 2001. 11. Authors's Addresses Jari Arkko Ericsson 02420 Jorvas Finland EMail: Jari.Arkko@ericsson.com Vesa Torvinen Ericsson 02420 Jorvas Finland EMail: Vesa.Torvinen@ericsson.fi Gonzalo Camarillo Ericsson 02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Tao Haukka Nokia Finland EMail: Tao.Haukka@nokia.com Sanjoy Sen Nortel Networks 2735-B Glenville Drive Richardson, TX 75082, USA EMail: firstname.lastname@example.org "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.