--- 1/draft-ietf-sip-sec-agree-00.txt 2006-02-05 01:46:12.000000000 +0100
+++ 2/draft-ietf-sip-sec-agree-01.txt 2006-02-05 01:46:12.000000000 +0100
@@ -1,809 +1,872 @@
SIP Working Group Jari Arkko
INTERNET-DRAFT Vesa Torvinen
- Ericsson
- April 2002 Tao Haukka
+ Gonzalo Camarillo
+May 2002 Ericsson
+Expires: December 2002 Tao Haukka
Nokia
Sanjoy Sen
- Lee Valerius
Nortel Networks
Security Mechanism Agreement for SIP Sessions
-1. Status of this Memo
+Status of this memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026. Internet-Drafts are working docu¡
- ments of the Internet Engineering Task Force (IETF), its areas, and
- its working groups. Note that other groups may also distribute work¡
- ing documents as Internet-Drafts.
+ 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 are draft documents valid for a maximum of six months
- and may be updated, replaced, or made obsolete 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.
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or cite them other than as "work in progress".
- The list of current Internet-Drafts may be found at
- http://www.ietf.org/ietf/1id-abstracts.txt
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/lid-abstracts.txt
- The list of Internet-Draft Shadow Directories may be found at
- http://www.ietf.org/shadow.html.
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
- The distribution of this memo is unlimited. It is filed as , and expires October, 2002. Please send
- comments to the author or to SIPPING or SIP working group.
+ This document is an individual submission to the IETF. Comments
+ should be directed to the authors.
-2. Abstract
+Abstract
- SIP has a number of security mechanisms for hop-by-hop and end-to-end
- protection. Some of the security mechanisms have been built in to the
- SIP protocol, such as HTTP authentication or secure attachments. In
- these mechanisms there are even alternative algorithms and parameters.
- Currently it isn't possible to select which security mechanisms to use
- over a connection. In particular, even if some mechanisms such as
- OPTIONS were used to make this selection, the selection would be vul¡
- nerable against the Bidding-Down attack. This document defines a
- header for negotiating the security mechanisms within SIP. A SIP
- entity applying this mechanism must always require some minimum secu¡
- rity (i.e. integrity protection) from all communicating parties in
- order to secure the negotiation, but the negotiation can agree on
- which specific minimum security is used.
+ 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 over a connection. 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 for
+ negotiating the security mechanisms within SIP between a user agent
+ client and its next hop SIP entity. A 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 the negotiation can agree on which specific minimum
+ security is used.
-3. Contents
+TABLE OF CONTENTS
- 1. Status of this Memo..................................1
- 2. Abstract.............................................1
- 3. Contents.............................................2
- 4. Introduction.........................................2
- 5. The Problem..........................................3
- 6. Solution.............................................4
- 6.1. Requirements.........................................4
- 6.2. Different Mechanisms.................................5
- 6.3. Overview of Operations...............................5
- 6.4. Header descriptions..................................7
- 7. Summary of header usage..............................9
- 8. Backwards Compatibility..............................10
- 9. Examples.............................................10
- 9.1. Selecting Between New and Old Mechanisms.............10
- 9.2. Selections Along the Path............................11
- 10. Security Considerations..............................13
- 11. IANA Considerations..................................13
- 12. Modifications........................................14
- 13. Acknowledgments......................................15
+ 1. Introduction....................................................2
+ 2. The Problem.....................................................3
+ 3. Solution........................................................4
+ 3.1. Requirements...............................................4
+ 3.2. Overview of Operations.....................................5
+ 3.3. Syntax.....................................................6
+ 3.4. Protocol Operation.........................................7
+ 3.4.1 Client Initiated........................................7
+ 3.4.2 Server Initiated........................................8
+ 3.5. Security Mechanism Initiation..............................9
+ 3.6. Duration of the Security Association......................10
+ 3.7. Summary of Header Field Use...............................10
+ 4. Backwards Compatibility........................................11
+ 5. Examples.......................................................11
+ 5.1. Client Initiated..........................................10
+ 5.2. Server Initiated..........................................12
+ 6. Security Considerations........................................13
+ 7. IANA Considerations............................................14
+ 8. Modifications..................................................14
+ 9. Acknowledgments................................................15
+ 10. Normative References...........................................15
+ 11. Non-Normative References.......................................15
+ 12. Authors’s Addresses............................................16
-4. Introduction
+1. Introduction
- Traditionally, security protocols have included facilities to agree on
- the used mechanisms, algorithms, and other security parameters. The
- reason for this is that experience has shown that e.g. algorithm
- development uncovers problems in old algorithms and produces new ones.
- Furthermore, different mechanisms and algorithms are suitable for dif¡
- ferent situations. Typically, protocols also select other parameters
- beyond algorithms at the same time.
+ Traditionally, security protocols have included facilities to agree
+ on the used mechanisms, algorithms, and other security parameters.
+ The reason for this is that experience has shown that algorithm
+ development uncovers problems in old algorithms and produces new
+ ones. Furthermore, different mechanisms and algorithms are suitable
+ for different situations. Typically, protocols also select other
+ parameters beyond algorithms at the same time.
The purpose of this specification is to define a similar negotiation
- functionality in SIP [1]. SIP has some security functionality built-in
- such as HTTP Digest authentication [4], secure attachments such as
+ functionality in SIP [1]. SIP has some security functionality built-
+ in such as HTTP Digest authentication [4], secure attachments such as
S/MIME [5], and can also use underlying security protocols such as
- IPSec/IKE [2] or TLS [3]. Some of the built-in security functionality
+ 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 (e.g. recommend just one
- lower layer security protocol), we can not expect to cut down the num¡
- ber of items in the whole list to one. There will still be multiple
- security solutions utilized by SIP. Furthermore, it is likely that new
- methods will appear in the future, to complete the methods that exist
- today.
+ 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 the whole list to one. There will still be
+ multiple security solutions utilized by SIP. Furthermore, it is
+ likely that new methods will appear in the future, to complement the
+ methods that exist today.
- Chapter 5 shows that without a secured method to choose between secu¡
- rity mechanisms and/or their parameters, SIP is vulnerable to certain
- attacks. As the HTTP authentication RFC [4] points out, authentication
- and integrity protection using multiple alternative methods and algo¡
- rithms is vulnerable to Man-in-the-Middle (MITM) attacks. More seri¡
- ously, it is hard or sometimes even impossible to know whether a SIP
- peer entity is truly unable to perform e.g. Digest, TLS, or S/MIME,
- or if a MITM attack is in action. In small networks consisting of
- workstations and servers these issues are not very relevant, as the
- administrators can deploy appropriate software versions and set up
- policies for using exactly the right type of security. However, SIP
- will soon 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 [6].
+ Chapter 2 shows that 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 and integrity protection using multiple alternative
+ methods and algorithms is vulnerable to Man-in-the-Middle (MitM)
+ attacks. More seriously, it is hard or sometimes even impossible to
+ know whether a SIP peer entity is truly unable to perform (e.g.,
+ Digest, TLS, or S/MIME) or if a MitM attack is in action. In small
+ networks consisting of workstations and servers these issues are not
+ very relevant, as the administrators can deploy appropriate software
+ versions and set up policies for using exactly the right type of
+ security. However, SIP will 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 [6].
Chapter 6 documents the proposed solution, and chapter 7 gives some
demonstrative examples.
-5. The Problem
+2. Problem Description
- SIP has alternative security mechanisms such as HTTP authentication /
- integrity protection, lower layer security protocols, and S/MIME. It
- is likely that their use will continue in the future. SIP security is
- developing, and is likely to see also new solutions in the future.
+ 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 in the future. SIP
+ security is developing, and is likely 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 possiblity for instanta¡
- neous 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 hard¡
- ware.
+ 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 security mechanisms get selected? It
- would be desirable to take advantage of new mechanisms as they become
- available in products.
+ 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, and
preferably find this out without too many additional roundtrips.
- Secondly, selection of security mechanisms MUST be secure. Tradition¡
- ally, 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. This allows the peers to detect if the initial,
- unprotected offers were tampered with.
+ Secondly, selection of security mechanisms MUST 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. This allows the peers to
+ detect if the initial, unprotected offers were tampered with.
- The security implications of this are subtle, but do have a fundamen¡
- tal importance in building large networks that change over time. Given
- that the hashes are produced also using algorithms agreed 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 need to prevent MITM attackers from mod¡
- ifying 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 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 hash¡
- ing, 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 incor¡
- rect. If the attacker is able to break the weak security, the security
- method and/or the algorithm should not be used.
+ 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
+ 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 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 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 pos¡
- sible 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 [4]), and then
- later new devices 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.
+ 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 [4]),
+ and then later new devices 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.
-6. Solution
+3. Solution
-6.1. Requirements
+3.1 Requirements
The solution to the SIP security negotiation problem should have the
following properties:
(a) It allows the selection of security mechanisms, such as lower
- layer security protocols or secure attachments. It also allows the
- selection of individual algorithms and parameters when the security
- functions are integrated in SIP (such as in the case of HTTP authenti¡
- cation or secure attachments).
+ layer security protocols or HTTP digest. It also allows the selection
+ of individual algorithms and parameters when the security functions
+ are integrated in SIP (such as in the case of HTTP authentication).
- (b) It allows both end-to-end and hop-by-hop negotiation.
+ (b) It allows first-hop security negotiation.
- (c) It is secure, e.g. prevents the bidding down attack.
+ (c) It is secure (i.e., prevents the bidding down attack.)
(d) It is capable of running without additional roundtrips. This is
important in the cellular environment, where an additional roundtrip
could delay the call set up for 1000-1500 ms.
- (e) It does not introduce any additional state to servers and proxies.
+ (e) It does not introduce any additional state to servers and
+ proxies.
Currently, SIP does not have any mechanism which fulfills all the
requirements above. The basic SIP features such as OPTIONS and
- Require, Supported headers are capable of informing peers about vari¡
- ous 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 is described in the RFC itself. More
- seriously, they have no provisions for allowing encryption to be nego¡
- tiated. Hence, it would be hard to turn on possible future encryption
- schemes in a secure manner.
-
-6.2. Different Mechanisms
+ 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 is described in the RFC
+ itself. More seriously, they have no provisions for allowing
+ encryption to be negotiated. Hence, it would 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 parameters such as algorithms.
- A non-self-describing security mechanism is a security mechanism that,
- when used, requires that the use of the method or some of its parame¡
- ters have been agreed beforehand.
+ A non-self-describing security mechanism is a security mechanism
+ that, when used, requires that the use of the method 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 the chosen algorithm is visible from the
HTTP authentication headers. The use of S/MIME is indicated by the
MIME headers, and the CMS structures inside S/MIME describe the used
algorithms. TLS is run on a separate port in SIP, and where IPsec/IKE
is used, IKE negotiates all the necessary parameters.
The only exception to this list is the use of manually keyed IPsec.
IPsec headers do not contain information about the used algorithms.
Furthermore, peers 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 in place, because the
application can search for a Security Association (or create a new
one) after having received a message that contains S/MIME.
In order to make it possible to negotiate both self-describing and
- non-self-describing security mechanisms, the security agreement scheme
- must allow both sides to decide on 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 the negotiation has not been
- tampered by a man-in-the-middle. This tampering will be detected
- later.
+ non-self-describing security mechanisms, we need another requirement
+ on the security agreement scheme:
-6.3. Overview of Operations
+ (f) the security agreement scheme must allow both sides to decide on
+ the desired security mechanism before it is actually used.
- This specification uses the following approach. The clients and
- servers offer their lists of supported security mechanisms and parame¡
- ters in the first, unprotected messages. They then proceed to turn on
- the selected security, and finally repeat some information under this
- security in order to ensure that the first exchanged lists had not
- been modified. This procedure is stateless for servers (unless the
- used security mechanisms require the server to keep some state).
+ This decision can, and must, take place on both sides before we can
+ be sure that the negotiation has not been tampered by a man-in-the-
+ middle. This tampering will be detected later.
- The client and the server lists are both static i.e. they do not and
- can not change based on the input from the other side. Nodes MAY, how¡
- ever, maintain several static lists, one for each interface, for exam¡
- ple.
+3.2. Overview of Operations
+
+ The message flow below illustrates how the mechanism defined in this
+ document works:
1. Client ----------client list---------> Server
2. Client Server
5. Client Server:
+ 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:
- OPTIONS server SIP/2.0
- Security-Mechanism: to=sip:server.example.com,
- from=sip:client.example.com,
- mech=tls
+ - R: Header field may appear in requests.
- 2. Server -> Client:
+ - 401, 407 etc.: A numerical value or range indicates response codes
+ with which the header field can be used.
- 200 OK
- Security-Mechanism: to=sip:client.example.com,
- from=sip:server.example.com,
- mech=smime;pref=1, mech=tls;pref=2
+ The "proxy" column describes the operations a proxy may perform on a
+ header field:
- 3. Security handshake at a lower layer i.e. TLS
+ - a: A proxy can add or concatenate the header field if not present.
- 4. Client -> Server:
+ - r: A proxy must be able to read the header field, and thus this
+ header field cannot be encrypted.
- INVITE server SIP/2.0
- Security-Mechanism: to=sip:client.example.com,
- from=sip:server.example.com,
- mech=smime;pref=1, mech=tls;pref=2
+ - d: A proxy can delete a header field value.
- 5. Server -> Client:
+ The next six columns relate to the presence of a header field in a
+ method:
- 200 OK
+ - o: The header field is optional.
- In the example we have omitted the returned values of Security-Mecha¡
- nism in replies for clarity. Typically in SIP the servers do not
- remove header fields as they answer, they only add new headers.
+4. Backwards Compatibility
- If this example was run without Security-Mechanism in Step 2, the
- client would not know what kind of security the other one supports,
- and would be forced to error-prone trials.
+ A server that, by local policy, decides to use the negotiation
+ mechanism defined in this document, will not accept requests from
+ clients that do not support this extension. This obviously breaks
+ interoperability with every plain SIP client. Therefore, this
+ extension should only be used in closed environments where it is
+ ensured somehow that every client implements this extension.
- More seriously, if the Security-Mechanism was omitted in Step 4, 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.
+5. Examples
-9.2. Selections Along the Path
+ The following examples illustrate the use of the mechanism defined
+ above.
- This example attempts to show how selections can be made between a
- client and the first-hop proxy while the actual SIP messages are still
- destinated to a server further on in the network. This example demon¡
- strates how we can securely agree on the security mechanism between
- the client and its first hop proxy, without adding roundtrips.
+5.1. Client Initiated
- In this example, the client sends a REGISTER request to its registrar.
- At the same time, the client negotiates the security with a different
- first hop proxy. There are three alternative security solutions: a)
- TLS, b) IPsec/IKE, and c) HTTP Digest.
+ A UA negotiates the security mechanism to be used with its outbound
+ proxy without knowing beforehand which mechanisms the proxy supports.
- The example starts by a client coming to a new network and learning
- the address of the local proxy. The proxy is of an upgraded version,
- so it supports all security mechanisms. The client supports alterna¡
- tives b) and c). The client also knows the address of the registrar.
- We assume that some trust has already been established between the
- client and the home, and between the client and the proxy. Perhaps
- this trust is in the form of the nodes belonging under the same PKI,
- or having distributed shared secrets beforehand.
+ UAC Proxy UAS
- In Step 1 the client contacts the proxy using a REGISTER message. We
- omit the details of the communications with the home server in this
- discussion, but the proxy forwards the messages onwards in Step 2. In
- Step 3, the registrar responds with an end-to-end HTTP Digest authen¡
- tication challenge. Using the same response, the proxy adds an indica¡
- tion that it supports TLS with HTTP Digest, IPsec/IKE, and plain HTTP
- Digest. In Step 4, the client selects the first method it supports
- (IPsec/IKE in this case), the protection is turned on. In Step 5, the
- client sends the next round of REGISTER messages to the registrar.
- This message includes the repetition of the original security capabil¡
- ities of the proxy. The proxy verifies this list, and forwards the
- request to the registrar. In Step 7, the registrar responds with a 200
- OK.
+ | | |
+ |----(1) OPTIONS---->| |
+ | | |
+ || |
+ | | |
+ |----(3) INVITE----->| |
+ | |----(4) INVITE--->|
+ | | |
+ | || |
+ | |-----(8) ACK----->|
+ | | |
+ | | |
+ | | |
+ | | |
- 1. Client -> Proxy:
+ Figure 2: Negotiation initiated by the client
- REGISTER server SIP/2.0
- Security-Mechanism: to=sip:proxy.example.com,
- from=sip:client.example.com,
- mech=ipsec-ike, mech=digest;alg=MD5
+ The UAC sends an OPTIONS request to its outbound proxy, indicating
+ that it is able to negotiate security mechanisms and that it supports
+ TLS and digest-integrity (Step 1 of figure 1). The outbound proxy
+ challenges the UAC with its own list of security mechanisms – IPsec
+ and TLS (Step 2 of figure 1). The only common security mechanism is
+ TLS, so they establish a TLS connection between them (Step 3 of
+ figure 1). When the connection is successfully established, the UAC
+ sends an INVITE over the TLS connection just established (Step 4 of
+ figure 1). This INVITE contains the 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.
- 2. Proxy communicates with the Server.
+ 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.
- 3. Proxy -> Client:
+ More seriously, if the Security-verify was omitted in Step 4, 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.
- 401 Authentication Required
- (HTTP Digest challenge from the registrar to the client)
- Security-Mechanism: to=sip:client.example.com,
- from=sip:proxy.example.com,
- mech=tls;pref=1, mech=ipsec-ike;pref=2,
- mech=digest;pref=3;alg=MD5
+ (1) OPTIONS proxy.example.com
+ Security-Client: tls;q=0.1
+ Security-Client: digest-integrity;q=0.2
+ Require: sec-agree
- 4. Security handshake at a lower layer i.e. IPsec/IKE
+ (2) 494 (Security Agreement Required)
+ Security-Server: ipsec-ike;q=0.1
+ Security-Server: tls;q=0.2
- 5. Client -> Proxy:
+ (3) INVITE proxy.example.com
+ Security-Verify: ipsec-ike;q=0.1
+ Security-Verify: tls;q=0.2
+ Route: callee@domain.com
- REGISTER server SIP/2.0
- Security-Mechanism: to=sip:client.example.com,
- from=sip:proxy.example.com,
- mech=tls;pref=1, mech=ipsec-ike;pref=2,
- mech=digest;pref=3;alg=MD5
+ The 200 OK response for the INVITE and the ACK are also sent over the
+ TLS connection. The ACK (7) will contain the same Security-Verify
+ header field as the INVITE (3).
- 6. Proxy communicates with the Server.
+5.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.
- 7. Proxy -> Client:
+ UAC Proxy UAS
- 200 OK
+ | | |
+ |-----(1) INVITE---->| |
+ | | |
+ || |
+ | | |
+ |<=======IKE========>| |
+ | | |
+ |-----(4) INVITE---->| |
+ | |----(5) INVITE--->|
+ | | |
+ | || |
+ | |-----(9) ACK----->|
+ | | |
+ | | |
- As in the previous example, if this was run without Security-Mechanism
- in Step 3, the client would not know what kind of algorithms the
- server supports. In this example we demonstrate also the need for the
- client to send its own mechanism list in Step 1. If this wasn't known
- to the proxy when it responds in Step 3, it could not have provided a
- suitable HTTP Digest challenge because at that point the proxy would
- not have known if the client supports that.
+ Figure 3: Server initiated security negotiation
- As in the previous example, removing the repetition of the Security-
- Mechanism header in Step 5 would open the system to MITM attacks.
+ The proxy, following its local policy, challenges 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 (6) and the ACK
+ (8) are sent using the security association that has been
+ established.
-10. Security Considerations
+6. Security Considerations
- This specification is about making it possible to select between vari¡
- ous SIP security mechanisms in a secure manner. In particular, the
- method presented here allow current networks using e.g. Digest later
- securely upgrade to e.g. S/MIME without requiring a simultaneous modi¡
- fication in all equipment. The method presented in this specification
- is secure only if the weakest proposed mechanism offers at least
- integrity protection.
+ This specification is about making it possible to select between
+ various SIP security mechanisms in a secure manner. In particular,
+ 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
+ presented in this specification is secure only if the weakest
+ proposed mechanism offers at least integrity protection.
- 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.
+ 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.
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.
Finally, attackers could try to modify the client's list of security
- mechanisms in the first message. The client selects the security mech¡
- anism based on its own knowledge of its own capabilities and the
+ 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.) 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.
+ 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.
- All clients that implement this specification MUST select HTTP Digest,
- S/MIME, TLS, IPsec, or any stronger method for the protection of the
- second request. If HTTP Digest is used alone, the security agreement
- headers MUST be protected. This can be done with HTTP Digest if com¡
- bined with MIME/SIP tunneling, for example.
+ All clients that implement this specification MUST select HTTP Digest
+ with integrity, TLS, IPsec, or any stronger method for the protection
+ of the second request. If HTTP Digest is used alone, the security
+ agreement headers MUST be protected. This can be done with HTTP
+ Digest if combined with MIME/SIP tunneling, for example.
-11. IANA Considerations
+7. IANA Considerations
- This specification defines 'sec-agree' option tag which should be reg¡
- istered in IANA. The option-tag 'sec-agree' can be used in header
- related to the SIP compatibility mechanisms for extensions (e.g.
- Require and Supported).
+ This specification defines the 'sec-agree' SIP option tag which
+ should be registered in IANA.
- This specification also defines a new error code, 494 (Security Agree¡
- ment Failed), which should be registered in IANA.
+ This specification also defines a new SIP status code, 494 (Security
+ Agreement Failed), which should be registered in IANA.
-12. Modifications
+8. Modifications
- The draft-sip-sec-agree-00.txt version of this specification intro¡
- duced the following modifications:
+ The draft-sip-sec-agree-01.txt version of this specification
+ introduced the following modifications:
+
+ - Scope narrowed down to first-hop negotiation.
+
+ - Fixed syntax of header fields.
+
+ The draft-sip-sec-agree-00.txt version of this specification
+ introduced the following modifications:
- Many editorial changes, restructuring and clarifications.
- - Motivation section has been shortened since this is now a WG item.
+ - Motivation section has been shortened since this is now a WG
+ item.
- - Clarified that the solution requires always some base level of secu¡
- rity (i.e. integrity) in order to work. Even 'the weak security' must
- not be broken.
+ - Clarified that the solution requires always some base level of
+ security (i.e. integrity) in order to work. Even 'the weak
+ security' must not be broken.
- - Text related to alternative solutions shortened and moved to a new
- place.
+ - Text related to alternative solutions shortened and moved to a
+ new place.
- - New rules for possible error and special cases has been added, e.g.
- for the case in which an non-adjacent SIP entities try to negotiate
- hop-by-hop security mechanisms.
+ - New rules for possible error and special cases has been added,
+ (e.g., for the case in which an non-adjacent SIP entities try to
+ negotiate hop-by-hop security mechanisms).
- - Syntax of the header redesigned. Wanted to get rid of the semantics
- related to the relative position of a header component in the header
- (e.g. first parameters defines the 'from-uri', second the 'to-uri',
- and third the first supported security mechanism). The option tags are
- now used to identify the Security Agreement extension, not the indi¡
- vidual security mechanisms.
+ - Syntax of the header redesigned. Wanted to get rid of the
+ semantics related to the relative position of a header component in
+ the header e.g., first parameters defines the 'from-uri', second
+ the 'to-uri', and third the first supported security mechanism).
+ The option tags are now used to identify the Security Agreement
+ extension, not the individual security mechanisms.
- The semantics of the header slightly changed: the AND operator
- between the indivicual mechanisms is removed because it is really need
- with HTTP Digest only. And even in this case, the negotiation is not
- needed beforehand if some underlying security is used.
+ between the indivicual mechanisms is removed because it is really
+ need with HTTP Digest only. And even in this case, the negotiation
+ is not needed beforehand if some underlying security is used.
- - Options for HTTP Digest algorithms and manually keyed IPsec added.
+ - Options for HTTP Digest algorithms and manually keyed IPsec
+ added.
- Explicit rules were added to all mechanisms on how they should be
used, such as TLS to be run on port 5061 etc.
- References to Enhanced HTTP Digest removed.
- Example related to 3GPP generalized.
The draft-arkko-sip-sec-agree-01.txt version of this specification
introduced the following modifications:
- Reversed approach to make servers stateless
- - Removed discussion of the use of this for Digest algorithm selec¡
- tion, since Enhanced Digest already has bidding-down protection
+ - Removed discussion of the use of this for Digest algorithm
+ selection, since Enhanced Digest already has bidding-down
+ protection
- - Renamed org.iana.sip.digest to org.iana.sip.edigest and removed the
- parameters, as we can rely on Enhanced Digest to perform the algorithm
- selection.
+ - Renamed org.iana.sip.digest to org.iana.sip.edigest and removed
+ the parameters, as we can rely on Enhanced Digest to perform the
+ algorithm selection.
- Removed agreements for full paths.
- Simplified syntax
-13. Acknowledgments
-
- The authors wish to thank 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 of the 3GPP SA3 group for interesting discussions in this
- problem space.
+9. Acknowledgments
- 14. Normative References
+ The authors wish to thank Lee Valerius, 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 of the 3GPP SA3 group for
+ interesting discussions in this problem space.
- [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peter¡
- son, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Pro¡
- tocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF,
+10. Normative References
+ [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
+ Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation
+ Protocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF,
February 2002.
- [2] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro¡
- tocol", RFC 2401, IETF, November 1998.
+ [2] S. Kent, R. Atkinson, "Security Architecture for the 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 and Ed, "S/MIME version 3 message specification," RFC
2633, IETF, June 1999.
- 15. Non-Normative References
+11. Non-Normative References
[6] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A.
Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP",
- draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, October
- 2001.
+ draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF,
+ October 2001.
- 16. Author's Address
+12. Authors's Addresses
- Jari Arkko, Vesa Torvinen
+ Jari Arkko
Ericsson
02420 Jorvas
Finland
- EMail: Jari.Arkko@ericsson.com, Vesa.Torvinen@ericsson.fi
+ 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: sanjoy@nortelnetworks.com
-
- Lee Valerius
- Nortel Networks
- 2201 Lakeside Blvd
- Richards, TX 75082, USA
- EMail: valerius@nortelnetworks.com