[-SIP-] {+Network+} Working Group [-Jari-] {+J.+} Arkko [-INTERNET-DRAFT Vesa-] {+Internet-Draft V.+} Torvinen [- Gonzalo-] {+Expires: April 28, 2003 G.+} Camarillo [-June 2002-] Ericsson [-Expires: December 2002 Tao-] {+A. Niemi T.+} Haukka Nokia [-Sanjoy Sen Nortel Networks-] {+October 28, 2002+} Security Mechanism Agreement for [-SIP Sessions-] {+the Session Initiation Protocol (SIP) draft-ietf-sip-sec-agree-05+} Status of this [-memo-] {+Memo+} This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as [-Internet-Drafts.-] {+Internet- Drafts.+} 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.txt-] {+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-] {+http://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 fields-] {+new functionality+} for negotiating the security mechanisms [-within SIP-] {+used+} between a [-SIP entity-] {+Session Initiation Protocol (SIP) user agent+} and its [-next SIP hop. A-] {+next-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, but-] {+entity. This new functionality supplements+} the [-negotiation can agree on which specific-] {+existing methods of choosing+} security [-is used. Arkko-] {+mechanisms between SIP entities. Arkko,+} et [-al-] {+al. Expires April 28, 2003+} [Page 1] [-INTERNET-DRAFT-] {+Internet-Draft+} SIP [-Sec-] {+Security+} Agreement [-June-] {+October+} 2002 [-TABLE OF CONTENTS-] {+Table of Contents+} 1. [-Introduction....................................................2-] {+Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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.1-] {+Operation . . . . . . . . . . . . . . . . . . . . . 7 2.3.1+} Client [-Initiated........................................7 3.4.2-] {+Initiated . . . . . . . . . . . . . . . . . . . . . . 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 [-the-] Security [-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......................13-] {+Considerations . . . . . . . . . . . . . . . . . . 16+} 6. [-Security Considerations........................................13 7.-] IANA [-Considerations............................................15-] {+Considerations . . . . . . . . . . . . . . . . . . . . 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............................................16-] {+References . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . . 23 Full Copyright Statement . . . . . . . . . . . . . . . . . . 25 Arkko, et al. Expires April 28, 2003 [Page 2] Internet-Draft SIP Security Agreement October 2002+} 1. Introduction Traditionally, security protocols have included facilities to agree on the used mechanisms, algorithms, and other security parameters. [-The reason for this-] {+This+} is [-that algorithm development typically uncovers problems in old algorithms and sometimes even produces new problems. Furthermore,-] {+to add flexibility, since+} different mechanisms [-and algorithms-] are {+usually+} suitable [-for-] {+to+} different [-situations. Typically, protocols also select other parameters beyond algorithms at-] {+scenarios. Also,+} the [-same time.-] {+evolution of security mechanisms often introduces new algorithms, or uncovers problems in existing ones, making negotiation of mechanisms a necessity.+} The purpose of this specification is to define [-a similar-] negotiation functionality [-in SIP [1]. SIP has some security functionality built- in (e.g. HTTP Digest authentication [4]), it can utilize secure attachments (e.g. S/MIME [5]), and it can also use underlying security protocols (e.g. IPsec/IKE [2] or TLS [3]). Some 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 number of recommended security solutions (i.e., recommend just one lower layer security protocol), we can not expect to cut down the number of items in-] {+for+} the [-whole list to one. There will still be multiple security solutions utilized by SIP. Furthermore, it-] {+Session Initiation Protocol (SIP) [1]. This negotiation+} is [-likely that new methods will appear in the future,-] {+intended+} to [-complement the methods that exist today. Chapter 2 shows that without-] {+work 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 [4] points out, authentication-] {+Authentication+} and integrity protection using multiple alternative methods and algorithms is vulnerable to Man-in-the-Middle (MitM) [-Arkko et al [Page 2] INTERNET-DRAFT SIP Sec Agreement June 2002 attacks. More seriously, it-] {+attacks (e.g., see [4]). It+} is {+also+} hard or sometimes even impossible to know whether a [-SIP peer entity-] {+specific security mechanism+} is truly [-unable-] {+unavailable+} 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 servers-] these 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 [-will-] {+is 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-] {+which necessitates+} the [-requirements-] {+need for the negotiation functionality to be available+} from [-3GPP [7]. Chapter 6 documents-] 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-] {+very beginning of deployment (e.g., see [11]). 1.2 Design Goals 1. The entities involved+} in the [-future. SIP-] security [-is developing, and is likely-] {+agreement process need+} to [-see also new solutions in the future. Deployment of large number of SIP-based consumer devices such as 3GPP terminals requires all network devices to be able 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-] {+find out exactly which+} 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, and-] {+apply,+} preferably [-find this out-] without [-too many-] {+excessive+} additional roundtrips. [-Secondly,-] {+2. The+} selection of security mechanisms [-MUST-] {+itself 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 [8].+} This allows the peers to detect if the initial, unprotected offers were tampered with. {+Arkko, et al. Expires April 28, 2003 [Page 3] Internet-Draft SIP Security Agreement October 2002 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 agreed-] {+entities involved+} in the [-first unprotected messages, one could ask what the difference in-] security [-really is. Assuming integrity protection is mandatory and only secure algorithms are used, we still-] {+agreement process+} need to [-prevent MitM attackers from modifying other parameters, such as whether encryption is provided-] {+be able to indicate success+} or [-not. Let us first assume two peers capable-] {+failure+} of [-using both strong and weak security. If-] the [-initial offers are-] {+security agreement process. 4. The security agreement process should+} not [-protected in any way,-] {+introduce+} any [-attacker can easily "downgrade" the offers Arkko et al [Page 3] INTERNET-DRAFT SIP Sec Agreement June 2002 by removing the strong options. This would force the two peers-] {+additional state+} to [-use weak security between them. But if-] {+be maintained by+} the [-offers are protected-] {+involved entities. 1.3 Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"+} in [-some way -- such-] {+this document are to be interpreted+} as [-by hashing, or repeating them later when-] {+described in BCP 14, RFC 2119 [9]. 2. Solution 2.1 Overview of Operation The message flow below illustrates how+} the [-selected security is really-] {+mechanism defined in this document works: 1. Client ----------client list---------> Server 2. Client <---------server list---------- Server 3. Client ------(turn+} on [--- the situation is different. It would not be sufficient for the attacker-] {+security)------- Server 4. Client ----------server list---------> Server 5. Client <---------ok or error---------- Server Figure 1: Security agreement message flow. Step 1: Clients wishing+} to [-modify-] {+use this specification can send+} a [-single message. Instead,-] {+list of their supported security mechanisms along+} the [-attacker would have-] {+first request+} to [-modify both the offer message, as well as the message that contains-] the [-hash/repetition. More importantly,-] {+server. Step 2: Servers wishing to use this specification can challenge+} the [-attacker would have-] {+client+} to [-forge-] {+perform+} the [-weak-] security [-that is present-] {+agreement 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 would-] {+highest-preference security mechanism they+} have [-to do so-] in [-real time between the sent offers-] {+common+} and {+to turn on+} the [-later messages. Otherwise, the peers would notice that-] {+selected security. Step 4: The client contacts+} the [-hash is incorrect. If-] {+server again, now using+} the [-attacker-] {+selected security mechanism. The server's list of supported security mechanisms+} is [-able-] {+returned as a response+} to [-break the weak security,-] the {+challenge. Arkko, et al. Expires April 28, 2003 [Page 4] Internet-Draft SIP Security Agreement October 2002 Step 5: The server verifies its own list of+} security [-method and/or-] {+mechanisms in order to ensure that+} the [-algorithm should-] {+original 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 demanding-] {+mechanisms require+} the [-attacker-] {+server+} 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 [4]),-] {+keep some state). The client+} and [-then later new devices-] {+the server lists+} are [-added that support also encryption (such as S/MIME [1]). 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 to-] {+both static (i.e., they do not and cannot change based on+} the [-SIP security negotiation problem should have-] {+input from+} the [-following properties: (a) It allows-] {+other side). Nodes may, however, maintain several static lists, one for each interface, for example. Between Steps 1 and 2,+} the [-selection-] {+server 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 allows-] the [-selection of individual algorithms and parameters when-] {+server is necessarily stateful. The client would set up+} the {+non-self-describing+} security [-functions are integrated in-] {+mechanism between Steps 2 and 4. 2.2 Syntax We define three new+} SIP [-(such as-] {+header 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., prevents-] {+Augmented BNF definitions for+} the [-bidding down attack.) (d) It is capable of running without additional roundtrips. This-] {+syntax elements in this section+} is [-important-] {+as used+} in [-the cellular environment, where link delays are relatively high,-] {+SIP [1],+} and [-an additional roundtrip could delay the call set up further. (e) It does not introduce-] any [-additional state to servers and proxies. Currently, SIP does-] {+elements+} not [-have any mechanism which fulfills all the requirements above. The basic SIP features such-] {+defined in this section are+} as [-OPTIONS-] {+defined 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 [4] are not secure for picking among-] the [-digest integrity algorithms, as-] {+documents to which it refers: 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 [-described-] {+already defined+} in the [-HTTP authentication RFC [4] itself. More seriously, they-] {+SIP BNF [1]. We+} have [-no provisions-] {+copied its definitions here+} for [-allowing encryption to be negotiated. Hence, it would Arkko-] {+completeness. Arkko,+} et [-al-] {+al. Expires April 28, 2003+} [Page [-4] INTERNET-DRAFT-] {+5] Internet-Draft+} SIP [-Sec-] {+Security+} Agreement [-June-] {+October+} 2002 [-be hard to turn on possible future encryption schemes in a secure manner. A self-describing security mechanism is a security mechanism that, when used, contains all necessary information about the method being used as well as all of its-] {+The+} parameters [-such as algorithms. A non-self-describing security mechanism is a-] {+described by the BNF above have the following semantics: Mechanism-name This token identifies the+} security mechanism [-that, when used, requires that the use of-] {+supported by+} the [-method-] {+client, when it appears in a Security-Client header field;+} or [-some of its parameters have been agreed beforehand. Most security mechanisms used with SIP are self-describing. The use of HTTP digest, as well as-] {+by+} the [-chosen algorithm is visible from-] {+server, when it appears in a Security-Server or in a Security- Verify header field. The mechanism-name tokens are registered with+} the {+IANA. This specification defines four values: * "tls" for TLS [3]. * "digest" for+} HTTP [-authentication headers.-] {+Digest [4]. * "ipsec-ike" for IPsec with IKE [2]. * "ipsec-man" for manually keyed IPsec without IKE. Preference+} The [-use of S/MIME is indicated by-] {+"q" value indicates a relative preference for+} the [-MIME headers, and-] {+particular mechanism. The higher+} the [-CMS structures inside S/MIME describe-] {+value+} the [-used algorithms. TLS is run on a separate port in SIP, and where IPsec/IKE-] {+more preferred the mechanism is. All the security mechanisms MUST have different "q" values. It+} is [-used, IKE negotiates all-] {+an error to provide two mechanisms with+} the [-necessary parameters. The-] {+same "q" value. Digest-algorithm This optional parameter is defined here+} only [-exception-] {+for HTTP Digest [4] in order+} to [-this list is-] {+prevent+} the [-use-] {+bidding-down attack for the HTTP Digest algorithm parameter. The content+} of [-manually keyed IPsec. IPsec headers do not contain information about-] the [-used algorithms. Furthermore, peers-] {+field may+} have [-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-] {+same values as defined+} in [-place, because-] {+[4] for+} the [-application can search-] {+"algorithm" field. Digest-qop 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. In-] {+HTTP Digest [4] in+} order to [-make it possible to negotiate both self-describing and non-self-describing security mechanisms, we need another requirement on-] {+prevent+} the [-security agreement scheme: (f)-] {+bidding-down attack for the HTTP Digest qop parameter.+} The [-security agreement scheme must allow both sides to decide on-] {+content 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 that-] {+field may have same values as defined in [4] for+} the [-negotiation has not been tampered by a man-in-the- middle.-] {+"qop" field. Digest-verify+} This [-tampering will be detected later. 3.2. Overview of Operations The message flow below illustrates how the mechanism-] {+optional parameter is+} defined {+here only for HTTP Digest [4]+} 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 the server. Step 2: Servers wishing-] {+order+} to [-use this specification can challenge-] {+prevent+} the [-client to perform-] {+bidding-down attack for+} the {+SIP+} security {+mechanism+} agreement [-procedure.-] {+(this document).+} The [-security Arkko-] {+content of the field is counted exactly the same way as "request-digest" in [4] except that the Security-Server header field is included in the A2 parameter. If the "qop" directive's value is "auth" or is unspecified, then A2 is: A2 = Method ":" digest-uri-value ":" security-server If the "qop" value is "auth-int", then A2 is: Arkko,+} et [-al-] {+al. Expires April 28, 2003+} [Page [-5] INTERNET-DRAFT-] {+6] Internet-Draft+} SIP [-Sec-] {+Security+} Agreement [-June-] {+October+} 2002 [-mechanisms and parameters supported-] {+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 single SP before calculating or interpreting+} the [-server-] {+digest-verify parameter. Method, digest-uri-value, entity-body, and any other HTTP Digest parameter+} are [-sent along-] {+as specified+} in {+[4]. Note that+} this [-challenge. Step 3: The client then proceeds-] {+specification does not introduce any extension or change+} to [-select-] {+HTTP Digest [4]. This specification only re-uses+} the [-highest-preference security mechanism they have in common and-] {+existing HTTP Digest mechanisms+} to [-turn on the selected security. Step 4: The client contacts the server again, now using-] {+protect+} the [-selected security mechanism. The server's list-] {+negotiation+} of [-supported-] security mechanisms {+between SIP entities. 2.3 Protocol Operation This section deals with the protocol details involved in the negotiation between a SIP UA and its next-hop SIP entity. Throughout the text the next-hop SIP entity+} is [-returned-] {+referred to+} as {+the first-hop proxy or outbound proxy. However, the reader should bear in mind that+} a [-response-] {+user agent server can also be the next-hop for a user agent client. 2.3.1 Client Initiated If a client ends up using TLS+} to {+contact+} the [-challenge. Step 5: The-] server [-verifies its own list of security mechanisms-] {+because it has followed the rules specified+} in [-order to ensure that-] {+[5],+} the [-original list had not been modified. This procedure is stateless for servers (unless-] {+client MUST NOT use+} the [-used-] security [-mechanisms require-] {+agreement procedure of this specification. If a client ends up using non-TLS connections because of+} the [-server-] {+rules in [5], the client MAY use the security agreement of this specification+} to [-keep-] {+detect DNS spoofing, or to negotiate+} some [-state). The-] {+other security than TLS. A+} client [-and-] {+wishing to use+} the [-server lists are both static-] {+security agreement of this specification MUST add a Security-Client header field to a request addressed to its first-hop proxy+} (i.e., [-they do not and cannot change based on-] the [-input from-] {+destination of+} the [-other side). Nodes may, however, maintain several static lists, one for each interface, for example. Between Steps 1 and 2,-] {+request is+} the [-server may set up-] {+first- hop proxy). This header field contains+} a [-non-self-describing security mechanism if necessary. Note that with this type-] {+list+} of {+all the+} security [-mechanisms,-] {+mechanisms that+} the [-server is necessarily stateful.-] {+client supports.+} The client [-would set up the non-self-describing security mechanism between Steps 2 and 4. 3.3. Syntax We define three new SIP 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 )-] {+SHOULD NOT add+} preference [-= "q" EQUAL qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) algorithm = "alg" EQUAL token extension = generic-param Note that qvalue is already defined in-] {+parameters to this list. The client MUST add both a Require and Proxy-Require header field with+} the [-SIP BNF [1]. We have copied-] {+value "sec-agree" to+} its [-definitions here for completeness.-] {+request.+} The [-parameters described by the BNF above have the following semantics: Arkko et al [Page 6] INTERNET-DRAFT SIP Sec Agreement June 2002 Mechanism-name: It identifies the security mechanism supported by-] {+contents of+} the [-client, when it appears in a-] Security-Client header [-fields, or-] {+field may be used+} by the [-server, when it appears-] {+server to include any necessary information+} in {+its response. A server receiving an unprotected request that contains+} a [-Security-Server-] {+Require+} or [-in a Security-Verify header field. This specification defines five values: - "tls" for TLS [3]. - "digest-integrity" for HTTP Digest [4] using additional integrity protection for the Security-Verify-] {+Proxy-Require+} header [-field. The additional integrity protection consists of using-] {+field with+} the [-qop parameter-] {+value "sec-agree" MUST respond+} to [-protect a MIME body (e.g., "message/sip") that contains-] the [-Security-Verify header field. - "ipsec-ike" for IPsec-] {+client+} with [-IKE [2]. - "ipsec-man" for manually keyed IPsec without IKE. - "smime" for S/MIME [5]. Preference: The "q" value indicates-] a [-relative preference for the particular mechanism.-] {+494 (Security Agreement Required) response.+} The [-higher the value the more preferred the mechanism is. All-] {+server MUST add a Security-Server header field to this response listing+} the security mechanisms {+that the server supports. The server Arkko, et al. Expires April 28, 2003 [Page 7] Internet-Draft SIP Security Agreement October 2002+} MUST [-have different "q" values. It is an error-] {+add its list+} to [-provide two mechanisms with-] the [-same "q" value. Algorithm: An optional algorithm field for those-] {+response even if there are no common+} security mechanisms [-which are not self-describing or which are vulnerable for bidding-down attacks (e.g., HTTP Digest). In-] {+in+} the [-case-] {+client's and server's lists. The server's list MUST NOT depend on the contents+} of [-HTTP Digest,-] the [-same rules apply as defined-] {+client's list. The server MUST compare the list received+} in [-RFC 2617 [4] for-] the [-"algorithm"-] {+Security-Client header+} field [-in HTTP Digest. 3.4. Protocol Operation This section deals-] with the [-protocol details involved-] {+list to be sent+} in the [-negotiation between a SIP entity and its next-hop SIP entity. Throughout-] {+Security-Server header field. When+} the [-text-] {+client receives this response, it will choose+} the [-next-hop SIP entity is referred to as-] {+common security mechanism with+} the [-first-hop proxy or outbound proxy. However,-] {+highest "q" value. Therefore,+} the [-reader should bear in mind that a user agent-] server [-can also be-] {+MUST add+} the [-next-hop for-] {+necessary information so that the client can initiate that mechanism (e.g.,+} a [-proxy or, in absence of proxies,-] {+Proxy-Authenticate header field+} for {+HTTP Digest). When the client receives+} a [-user agent client. Note as well that-] {+response with+} 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-] {+Security-Server+} header [-field to a request addressed to this proxy (i.e., the destination of-] {+field, it MUST choose+} the [-request is-] {+security mechanism in+} the [-first-hop proxy). This header field contains a-] {+server's+} list [-of-] {+with the highest "q" value among+} all the [-security-] mechanisms that [-the client supports. The client SHOULD NOT add preference parameters-] {+are known+} to [-this list. The client-] {+the client. Then, it+} MUST [-add both-] {+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 [-Require and Proxy-Require header field with-] {+TLS connection). If an attacker modified+} the [-value "sec-agree" to its request. The-] Security-Client header field [-is used by-] {+in the request,+} the server [-to-] {+may not+} include [-any necessary information-] in its [-response. For example, if digest- integrity is-] {+response+} the [-chosen mechanism,-] {+information needed to establish+} the [-server includes an HTTP authentication challenge in-] {+common security mechanism with+} the [-response. If S/MIME is chosen,-] {+highest preference value (e.g.,+} the [-appropriate certificate-] {+Proxy-Authenticate header field+} is [-included. Arkko et al [Page 7] INTERNET-DRAFT SIP Sec Agreement June 2002-] {+missing).+} A [-server receiving an unprotected request that contains-] {+client detecting such+} a [-Require or Proxy-Require header field with-] {+lack of information in+} the [-value "sec-agree"-] {+response+} MUST [-challenge-] {+consider+} the [-client with-] {+current security agreement process aborted, and MAY try to start it again by sending+} a [-494 (Security Agreement Required) response. The server MUST add-] {+new request with+} a [-Security-Server-] {+Security-Client+} header field {+as described above. All the subsequent SIP requests sent by the client+} to [-this response listing-] {+that server SHOULD make use of+} the security [-mechanisms that-] {+mechanism initiated in+} the [-server supports. The server-] {+previous step. These requests+} MUST [-add its list to the response even if there are no common security mechanisms in-] {+contain a Security-Verify header field that mirrors+} the [-client's and-] server's [-lists. The serverĘs-] list [-MUST NOT depend on-] {+received previously in+} the [-contents of-] {+Security- Server header field. These requests MUST also have both a Require and Proxy- Require header fields with+} the [-client's list.-] {+value "sec-agree".+} The server MUST [-compare-] {+check that+} the [-list received-] {+security mechanisms listed+} in the [-Security-Client-] {+Security-Verify+} header field [-with the list-] {+of incoming requests correspond+} to [-be sent in-] {+its static list of supported security mechanisms. Note that, following+} the [-Security-Server-] {+standard SIP+} header [-field. When the client receives this response, it will choose-] {+field comparison rules defined in [1], both lists have to contain+} the [-common-] {+same+} security [-mechanism with-] {+mechanisms in+} the [-highest "q" value. Therefore,-] {+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 [-MUST add the necessary information so that the client-] can [-initiate that mechanism (e.g.,-] {+proceed processing+} a [-WWW-Authenticate header field for digest-integrity). When-] {+particular request if, and only if, the list was not modified. If modification of the list is Arkko, et al. Expires April 28, 2003 [Page 8] Internet-Draft SIP Security Agreement October 2002 detected, the server MUST respond to+} the client [-receives a response-] with a [-Security-Server header field, it-] {+494 (Security Agreement Required) response. This response+} MUST [-choose-] {+include+} the {+server's unmodified list of supported+} security [-mechanism in-] {+mechanisms. If+} the [-serverĘs-] list [-with the highest "q" value among all the mechanisms that are known to-] {+was not modified, and+} the [-client. Then,-] {+server is a proxy,+} 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-] {+remove+} the [-Security-Client-] {+"sec-agree" value from both the Require and Proxy-Require+} header [-field in-] {+fields, and then remove+} the [-request,-] {+header fields if no values remain. Once+} the [-server may not include in its response-] {+security has been negotiated between two SIP entities,+} the [-information needed to establish-] {+same SIP entities MAY use+} the [-common-] {+same+} security [-mechanism-] {+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 [-highest preference value (e.g.,-] {+same security for incoming requests (i.e.,+} the [-WWW-authenticate header field is missing). A client detecting such-] {+UA will be acting as+} a [-lack-] {+UAS). The user+} of [-information in-] {+a UA SHOULD be informed about+} the [-response MUST consider-] {+results of+} the [-current-] security [-negotiation process aborted, and-] {+mechanism agreement. The user+} MAY [-try-] {+decline+} to [-start it again by sending a new request with-] {+accept+} a [-Security-Client header field as described above. All the subsequent-] {+particular security mechanism, and abort further+} SIP [-requests sent by-] {+communications with+} the [-client to that-] {+peer. 2.3.2 Server Initiated A+} server [-SHOULD make-] {+decides to+} use [-of-] the security [-mechanism initiated-] {+agreement described+} in [-the previous step. These requests MUST contain-] {+this document based on local policy. If+} a [-Security-Verify header field that mirrors-] {+server receives a request from+} the [-serverĘs list received previously in-] {+network interface that is configured to use this mechanism, it must check that+} the [-Security-Server-] {+request has only one Via+} header field. [-These requests MUST also have both a Require and Proxy- Require-] {+If there are several Via+} header [-fields with-] {+fields,+} the [-value "sec-agree". The-] server [-MUST check that-] {+is not+} the [-security mechanisms listed in-] {+first-hop SIP entity, and it MUST NOT use this mechanism. For such a request,+} the [-Security-Verify header field of incoming requests correspond-] {+server must return a 502 (Bad Gateway) response. A server that decides+} to [-its static list of supported security mechanisms. Note that, following the standard SIP-] {+use this agreement mechanism MUST challenge unprotected requests with one Via+} header field [-comparison rules defined in [1], both lists have to contain-] {+regardless of+} the [-same security mechanisms in-] {+presence or+} the [-same order to be considered equivalent. In addition, for each particular security mechanism, its parameters-] {+absence of any Require, Proxy-Require or Supported header fields+} in [-both lists need to have the same values. The-] {+incoming requests. A+} server [-can proceed processing-] {+that by policy requires the use of this specification and receives+} a [-particular-] request [-if, and only if, the list was-] {+that does+} not [-modified.-] {+have the sec-agree option tag in a Require, Proxy-Require or Supported header field MUST return a 421 (Extension Required) response.+} If [-modification of-] the [-list is detected,-] {+request had+} the [-server-] {+sec-agree option tag in a Supported header field, it+} MUST [-challenge the client with-] {+return+} a 494 (Security Agreement [-Required). This response-] {+Required) response. In both situation the server+} MUST {+also+} include [-a challenge with server's unmodified list of supported security mechanisms. If-] {+in+} the [-Arkko et al [Page 8] INTERNET-DRAFT SIP Sec Agreement June 2002 list was not modified,-] {+response a Security-Server header field listing its capabilities+} 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-] {+field+} with [-each other-] {+an option- tag "sec-agree"+} 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).-] {+it.+} The [-user of a UA SHOULD be informed about-] {+server MUST also add necessary information so that+} the [-results of-] {+client can initiate+} the {+preferred+} security mechanism [-negotiation. The user MAY decline to accept-] {+(e.g.,+} a [-particular security mechanism, and abort further SIP communications with the peer. 3.4.2 Server Initiated A server decides to use the security negotiation described in this document based on local policy. A server that decides to use this negotiation MUST challenge unprotected requests regardless of the presence or the absence of any Require, Proxy-Require or Supported-] {+Proxy-Authenticate+} header [-fields in incoming requests. A server that by policy requires the use of this specification and receives a request-] {+field for HTTP Digest). Clients+} that [-does not have-] {+support+} the [-sec-agree option tag-] {+extension defined+} in {+this document MAY add+} a [-Require, Proxy-Require or-] Supported header field [-MUST return-] {+with+} a [-421 (Extension Required) response. If the request had-] {+value of "sec-agree". Arkko, et al. Expires April 28, 2003 [Page 9] Internet-Draft SIP Security Agreement October 2002 2.4 Security Mechanism Initiation Once+} the [-sec-agree option tag in a Supported header field, it MUST return-] {+client chooses+} a [-494 (Security Agreement Required) response. In both situation-] {+security mechanism from+} 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 value MUST be removed. This ensures that the previous hop is the one processing the response (see example in Section 5.3). 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 chooses a security mechanism from the list received-] {+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 [-[1] to-] {+[1]to+} determine the URI to be used as an input to the DNS procedures of [-[6].-] {+[5].+} However, if the URI is a [-sip-] {+SIP+} 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. [-Arkko et al [Page 9] INTERNET-DRAFT SIP Sec Agreement June 2002-] 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 contains-] {+parameters in+} the [-Security-Verify-] {+Security-Server+} header field {+to replace the same parameters+} in the [-request. Currently, only-] {+HTTP Digest challenge. The client MUST also use+} the [-qop value Ęauth-intĘ is able-] {+digest-verify parameter+} to [-provide required protection. Note that digest alone without placing Security- Verify-] {+protect 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 [2], [6], and [7].+} 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 be-] {+would+} 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. 3.6.-] {+2.5+} 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 signal-] {+of signaling+} the end of a security association. When TLS is used, the termination of the connection indicates that a new negotiation is {+Arkko, et al. Expires April 28, 2003 [Page 10] Internet-Draft SIP Security Agreement October 2002+} needed. IKE negotiates the duration of a security association. If the credentials provided by a client using [-digest-integrity-] {+digest+} are [-not-] {+no+} longer valid, the server will [-re-challenge-] {+re- 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. [-3.7.-] {+2.6+} 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 [-Arkko et al [Page 10] INTERNET-DRAFT SIP Sec Agreement June 2002-] _________________________________________________________________ Security-Client R ard - o - o o o Security-Server [-401,407,421,494-] {+421,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,494-] {+421,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 range-] indicates 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. [---] {+Arkko, et al. Expires April 28, 2003 [Page 11] Internet-Draft SIP Security Agreement October 2002 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, decides-] {+that is configured+} to use [-the negotiation mechanism defined in-] this [-document, will not-] {+mechanism, may also+} accept requests from clients that {+use TLS based on the rules defined in [5]. 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 plain-] {+some+} 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. [-Arkko et al [Page 11] INTERNET-DRAFT SIP Sec Agreement June 2002 5.-] {+4.+} Examples The following examples illustrate the use of the mechanism defined above. [-5.1.-] {+4.1+} 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. Arkko, et al. Expires April 28, 2003 [Page 12] Internet-Draft SIP Security Agreement October 2002+} 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 [-initiated-] {+Initiated+} by the [-client-] {+Client.+} 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 [-challenges-] {+responds 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Ęs-] {+server'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 [-Arkko et al [Page 12] INTERNET-DRAFT SIP Sec Agreement June 2002-] stronger security option from the header in Step 1, therefore substantially reducing the security. {+Arkko, et al. Expires April 28, 2003 [Page 13] Internet-Draft SIP Security Agreement October 2002+} (1) OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tls Security-Client: [-digest-integrity-] {+digest+} 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:callee@domain.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-Verify-] {+Security- Verify+} header field as the INVITE (3). [-5.2.-] {+4.2+} 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. {+Arkko, et al. Expires April 28, 2003 [Page 14] Internet-Draft SIP Security Agreement October 2002+} 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 negotiation Arkko et al [Page 13] INTERNET-DRAFT SIP Sec Agreement June 2002-] {+Initiated Security Negotiation.+} The proxy, following its local policy, [-challenges-] {+does 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 a 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 forwarding it to the UAC. This-] {+SIP/2.0+} 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" in the Security-Server header field. P1 sends an ACK-] {+Extension Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2+} (4) [-for the response and proceeds to establish a TLS connection, since this is the only security mechanism supported by P1. Once the TLS connection is established, session establishment proceeds normally. Messages (5), (8) and (11) are sent using the just established TLS connection. Messages (5) and (11) contain a Security- Verify header field that P2 removes before forwarding them to the UAS. Note that, following normal SIP procedures, P1 uses a different branch ID for-] INVITE [-(5) than the 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 Arkko-] {+sip:uas.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 Arkko,+} et [-al-] {+al. Expires April 28, 2003+} [Page [-14] INTERNET-DRAFT-] {+15] Internet-Draft+} SIP [-Sec-] {+Security+} Agreement [-June-] {+October+} 2002 [-6.-] {+5.+} Security Considerations This specification is about making it possible to select between various SIP security mechanisms in a secure manner. In particular, the method presented [-here-] {+herein+} allow current networks using, for instance, {+HTTP+} Digest, to be securely upgraded to, for instance, IPsec without requiring a simultaneous modification in all equipment. The method presented in this specification is secure only if the weakest proposed mechanism offers at least integrity [-protection. Attackers could try to modify-] {+and replay protection for+} the [-server's list of-] {+Security-Verify header field. The+} security [-mechanisms-] {+implications of this are subtle, but do have a fundamental importance+} in {+building large networks that change over time. Given that+} the [-first response. This would be revealed to the server when the client returns the received list-] {+hashes are produced also+} using {+algorithms agreed in+} the [-security. Attackers-] {+first unprotected messages, one+} could [-also try to modify-] {+ask what+} the [-repeated list-] {+difference+} in [-the second request from the client. However, if the selected-] security [-mechanism uses encryption this may not be possible, and if it uses-] {+really is. Assuming+} integrity protection {+is mandatory and only secure algorithms are used, we still need to prevent 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 initial offers are not protected in+} any [-modifications will be detected-] {+way, any attacker can easily "downgrade" the offers+} by {+removing+} the [-server. Finally, attackers could try to modify-] {+strong options. This would force+} the [-client's list of-] {+two peers to use weak+} security [-mechanisms in-] {+between them. But if+} the [-first message. The client selects-] {+offers are protected in some way -- such as by hashing, or repeating them later when+} the {+selected+} security [-mechanism based-] {+is really+} on [-its own knowledge of its own capabilities and the server's list, hence-] {+--+} the [-client's choice-] {+situation is different. It+} would {+not+} be [-unaffected by any such modification. However,-] {+sufficient for+} the [-server's choice could still be affected-] {+attacker to modify a single message. Instead, the attacker would have to modify both the offer message, as well+} as [-described below: - If-] the [-modification affected-] {+message that contains+} the [-server's choice,-] {+hash/ repetition. More importantly,+} the [-server and client-] {+attacker+} would [-end up choosing different-] {+have to forge the weak+} security [-mechanisms-] {+that is present+} in [-Step 3 or 4 of figure 1. Since they-] {+the second message, and+} would [-be unable to communicate-] {+have+} to [-each other, this would be detected as a potential attack. The client would either retry or give up-] {+do so+} in [-this situation. --] {+real time between the sent offers and the later messages. Otherwise, the peers would notice that the hash is incorrect.+} If the [-modification did-] {+attacker is able to break the weak security, the security method and/ or the algorithm should+} not [-affect-] {+be used. In conclusion,+} the [-server's choice, there's no effect. All clients that implement-] {+security difference is making a trivial attack possible versus demanding the attacker to break algorithms. An example of where+} this [-specification MUST select-] {+has a serious consequence is when a network is first deployed with integrity protection (such as+} HTTP Digest [-with integrity, TLS, IPsec, or any stronger method for-] {+[4]), and then later new devices are added that support also encryption (such as TLS [3]). In this situation, an insecure negotiation procedure allows attackers to trivially force even new devices to use only integrity protection. Possible attacks against+} the [-protection-] {+security agreement include: 1. Attackers could try to modify the server's list+} of {+security mechanisms in+} the [-second request. 7. IANA Considerations-] {+first response.+} This [-specification defines three new header fields, namely Security- Client, Security-Server and Security-Verify that should-] {+would+} be [-included in-] {+revealed to+} the [-registry for-] {+Arkko, et al. Expires April 28, 2003 [Page 16] Internet-Draft+} SIP [-header fields maintained by IANA. This specification defines-] {+Security Agreement October 2002 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 [4]. 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 Arkko, et al. Expires April 28, 2003 [Page 17] Internet-Draft SIP Security Agreement October 2002 [10], 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 [-'sec-agree' SIP option tag which should be registered in-] IANA. {+Mechanism Name Contact Reference -------------- ------- --------- digest [1] [RFCNNNN] tls [1] [RFCNNNN] ipsec-ike [1] [RFCNNNN] ipsec-man [1] [RFCNNNN] ipsec-3gpp [1] [RFCNNNN] People ------ [1] Jari Arkko Vesa Torvinen Gonzalo Camarillo Aki Niemi Tao Haukka 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.) Arkko, et al. Expires April 28, 2003 [Page 18] Internet-Draft SIP Security Agreement October 2002 6.2 Registration Template To: ietf-sip-sec-agree-mechanism-name@iana.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. Arkko, et al. Expires April 28, 2003 [Page 19] Internet-Draft SIP Security Agreement October 2002 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 [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] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January Arkko, et al. Expires April 28, 2003 [Page 20] Internet-Draft SIP Security Agreement October 2002 1999. [4] 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. [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Informative References [11] 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. [12] 3rd Generation Partnership Project, "Access security for IP- based services, Release 5", TS 33.203 v5.3.0, September 2002. [13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [15] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. Arkko, et al. Expires April 28, 2003 [Page 21] Internet-Draft SIP Security Agreement October 2002 Authors' Addresses Jari Arkko Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland Phone: +358 40 507 9256 EMail: jari.arkko@ericsson.com Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland Phone: +358 40 723 0822 EMail: vesa.torvinen@ericsson.fi Gonzalo Camarillo Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland Phone: +358 40 702 3535 EMail: gonzalo.camarillo@ericsson.com Aki Niemi Nokia P.O. Box 301 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Arkko, et al. Expires April 28, 2003 [Page 22] Internet-Draft SIP Security Agreement October 2002 Tao Haukka Nokia P.O. Box abc NOKIA GROUP, FIN 00045 Finland Phone: +358 40 517 0079 EMail: tao.haukka@nokia.com Appendix A. Syntax of ipsec-3gpp This appendix specifies the syntax of non-normative parameters to be used in 3GPP IP Multimedia Subsystem [12] with security mechanism "ipsec-3gpp". The notation used in the Augmented BNF definitions is as used in SIP [1]. 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 4294967295 port1 = "port1" EQUAL port port2 = "port2" EQUAL port port = 1*DIGIT The parameters described by the BNF above have the following semantics: Algorithm+} This [-specification also-] {+parameter+} defines {+the used authentication algorithm. It may have+} a [-new-] {+value of "hmac-md5-96" for HMAC-MD5-96 [13], or "hmac-sha- 1-96" for HMAC-SHA-1-96 [14]. The algorithm parameter is mandatory. Protocol This parameter defines the IPsec protocol. It may have a value of "ah" for AH [6], or "esp" for ESP [7]. If no Protocol parameter is present, the protocol will be ESP by default. Mode Arkko, et al. Expires April 28, 2003 [Page 23] Internet-Draft+} SIP [-status code, 494 (Security-] {+Security+} Agreement [-Failed),-] {+October 2002 This parameter defines the mode in+} which [-should-] {+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 the IPsec protocol is used in transport mode. Encrypt-algorithm This parameter defines the used encryption algorithm. It may have a value of "des-ede3-cbc" for 3DES [15], or "null" for no encryption. If no Encrypt-algorithm parameter is present, encryption is not used. Spi Defines the SPI number used for inbound messages. Port1 Defines the port number for inbound messages. Port2 Defines the port number for outbound messages. If no Port2 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 the underlying IPsec implementation supports selectors that allow all transport protocols supported by SIP to+} be [-registered-] {+protected with a single SA. The duration of security association is the same as+} in [-IANA. 8. Acknowledgments Arkko-] {+the expiration interval of the corresponding registration binding. Arkko,+} et [-al-] {+al. Expires April 28, 2003+} [Page [-15] INTERNET-DRAFT-] {+24] Internet-Draft+} SIP [-Sec-] {+Security+} Agreement [-June-] {+October+} 2002 {+Full Copyright Statement Copyright (C)+} The [-authors wish 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-] {+Internet Society (2002). All Rights Reserved. This document and translations of it may be copied+} and [-members-] {+furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction+} of {+any kind, provided that+} the [-3GPP SA3 group for interesting discussions in-] {+above copyright notice and+} this [-problem space. 9. Normative References [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Protocol", Work-] {+paragraph are included on all such copies and derivative works. However, this document itself may not be modified+} in [-Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, February 2002. [2] S. Kent, R. Atkinson, "Security Architecture-] {+any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed+} for the {+purpose of developing+} Internet [-Protocol", RFC 2401, IETF, November 1998. [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, IETF January 1999. [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, IETF, June 1999. [5] B. Ramsdell-] {+standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual+} and [-Ed, "S/MIME version 3 message specification", RFC 2633, IETF, June 1999. [6] H. Schulzrinne-] {+will 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 [7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements-] {+the 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 Arkko et al [Page 16] INTERNET-DRAFT SIP Sec Agreement June 2002 Tao Haukka Nokia Finland EMail: Tao.Haukka@nokia.com Sanjoy Sen Nortel Networks 2735-B Glenville Drive Richardson, TX 75082, USA EMail: sanjoy@nort