draft-ietf-sip-sec-agree-04.txt   draft-ietf-sip-sec-agree-05.txt 
SIP Working Group Jari Arkko Network Working Group J. Arkko
INTERNET-DRAFT Vesa Torvinen Internet-Draft V. Torvinen
<draft-ietf-sip-sec-agree-04.txt> Gonzalo Camarillo Expires: April 28, 2003 G. Camarillo
June 2002 Ericsson Ericsson
Expires: December 2002 Tao Haukka A. Niemi
T. Haukka
Nokia Nokia
Sanjoy Sen October 28, 2002
Nortel Networks
Security Mechanism Agreement for SIP Sessions Security Mechanism Agreement for the Session Initiation Protocol
(SIP)
draft-ietf-sip-sec-agree-05
Status of this memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/lid-abstracts.txt www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at 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 This Internet-Draft will expire on April 28, 2003.
should be directed to the authors.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
SIP has a number of security mechanisms. Some of them have been built This document defines new functionality for negotiating the security
in to the SIP protocol, such as HTTP authentication or secure mechanisms used between a Session Initiation Protocol (SIP) user
attachments. These mechanisms have even alternative algorithms and agent and its next-hop SIP entity. This new functionality
parameters. SIP does not currently provide any mechanism for supplements the existing methods of choosing security mechanisms
selecting which security mechanisms to use between two entities. In between SIP entities.
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 SIP entity
and its next SIP hop. 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 security is used.
TABLE OF CONTENTS Table of Contents
1. Introduction....................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Problem.....................................................3 1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution........................................................4 1.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Requirements...............................................4 1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Overview of Operations.....................................5 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Syntax.....................................................6 2.1 Overview of Operation . . . . . . . . . . . . . . . . . . . 4
3.4. Protocol Operation.........................................7 2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4.1 Client Initiated........................................7 2.3 Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
3.4.2 Server Initiated........................................8 2.3.1 Client Initiated . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Security Mechanism Initiation..............................9 2.3.2 Server Initiated . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Duration of the Security Association......................10 2.4 Security Mechanism Initiation . . . . . . . . . . . . . . . 10
3.7. Summary of Header Field Use...............................10 2.5 Duration of Security Associations . . . . . . . . . . . . . 10
4. Backwards Compatibility........................................11 2.6 Summary of Header Field Use . . . . . . . . . . . . . . . . 11
5. Examples.......................................................11 3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 12
5.1. Client Initiated..........................................10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Server Initiated..........................................12 4.1 Client Initiated . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Security Negotiation between Proxies......................13 4.2 Server Initiated . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations........................................13 5. Security Considerations . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations............................................15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments................................................15 6.1 Registration Information . . . . . . . . . . . . . . . . . . 18
9. Normative References...........................................15 6.2 Registration Template . . . . . . . . . . . . . . . . . . . 19
10. Non-Normative References.......................................16 6.3 Header Field Names . . . . . . . . . . . . . . . . . . . . . 19
11. AuthorsĘs Addresses............................................16 6.4 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 19
6.5 Option Tags . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Traditionally, security protocols have included facilities to agree Traditionally, security protocols have included facilities to agree
on the used mechanisms, algorithms, and other security parameters. on the used mechanisms, algorithms, and other security parameters.
The reason for this is that algorithm development typically uncovers This is to add flexibility, since different mechanisms are usually
problems in old algorithms and sometimes even produces new problems. suitable to different scenarios. Also, the evolution of security
Furthermore, different mechanisms and algorithms are suitable for mechanisms often introduces new algorithms, or uncovers problems in
different situations. Typically, protocols also select other existing ones, making negotiation of mechanisms a necessity.
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 (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 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 2 shows that without a secured method to choose between The purpose of this specification is to define negotiation
security mechanisms and/or their parameters, SIP is vulnerable to functionality for the Session Initiation Protocol (SIP) [1]. This
certain attacks. As the HTTP authentication RFC [4] points out, negotiation is intended to work only between a UA and its first-hop
authentication and integrity protection using multiple alternative SIP entity.
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 [7].
Chapter 6 documents the proposed solution, and chapter 7 gives some 1.1 Motivations
demonstrative examples.
2. Problem Description Without a secured method to choose between security mechanisms and/or
their parameters, SIP is vulnerable to certain attacks.
Authentication and integrity protection using multiple alternative
methods and algorithms is vulnerable to Man-in-the-Middle (MitM)
attacks (e.g., see [4]).
SIP has alternative security mechanisms such as HTTP authentication It is also hard or sometimes even impossible to know whether a
with integrity protection, lower layer security protocols, and specific security mechanism is truly unavailable to a SIP peer
S/MIME. It is likely that their use will continue in the future. SIP entity, or if in fact a MitM attack is in action.
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 In certain small networks these issues are not very relevant, as the
terminals requires all network devices to be able to accommodate administrators of such networks can deploy appropriate software
past, current and future mechanisms; there is no possibility for versions and set up policies for using exactly the right type of
instantaneous change since the new solutions are coming gradually in security. However, SIP is also expected to be deployed to hundreds
as new standards and product releases occur. It is sometimes even of millions of small devices with little or no possibilities for
impossible to upgrade some of the devices without getting completely coordinated security policies, let alone software upgrades, which
new hardware. necessitates the need for the negotiation functionality to be
available from the very beginning of deployment (e.g., see [11]).
So, the basic security problem that such a large SIP-based network 1.2 Design Goals
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 1. The entities involved in the security agreement process need to
preferably find this out without too many additional roundtrips. find out exactly which security mechanisms to apply, preferably
without excessive additional roundtrips.
Secondly, selection of security mechanisms MUST be secure. 2. The selection of security mechanisms itself needs to be secure.
Traditionally, all security protocols use a secure form of Traditionally, all security protocols use a secure form of
negotiation. For instance, after establishing mutual keys through negotiation. For instance, after establishing mutual keys
Diffie-Hellman, IKE sends hashes of the previously sent data -- through Diffie-Hellman, IKE sends hashes of the previously sent
including the offered crypto mechanisms. This allows the peers to data including the offered crypto mechanisms [8]. This allows
detect if the initial, unprotected offers were tampered with. the peers to detect if the initial, unprotected offers were
tampered with.
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
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.
3. Solution
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 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 next-hop security negotiation.
(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 link delays are
relatively high, 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 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
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 HTTP
authentication RFC [4] 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
parameters have been agreed beforehand.
Most security mechanisms used with SIP are self-describing. The use 3. The entities involved in the security agreement process need to
of HTTP digest, as well as the chosen algorithm is visible from the be able to indicate success or failure of the security agreement
HTTP authentication headers. The use of S/MIME is indicated by the process.
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. 4. The security agreement process should not introduce any
IPsec headers do not contain information about the used algorithms. additional state to be maintained by the involved entities.
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 1.3 Conventions
non-self-describing security mechanisms, we need another requirement
on the security agreement scheme:
(f) The security agreement scheme must allow both sides to decide on The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
the desired security mechanism before it is actually used. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [9].
This decision can, and must, take place on both sides before we can 2. Solution
be sure that the negotiation has not been tampered by a man-in-the-
middle. This tampering will be detected later.
3.2. Overview of Operations 2.1 Overview of Operation
The message flow below illustrates how the mechanism defined in this The message flow below illustrates how the mechanism defined in this
document works: document works:
1. Client ----------client list---------> Server 1. Client ----------client list---------> Server
2. Client <---------server list---------- Server 2. Client <---------server list---------- Server
3. Client ------(turn on security)------- Server 3. Client ------(turn on security)------- Server
4. Client ----------server list---------> Server 4. Client ----------server list---------> Server
5. Client <---------ok or error---------- Server 5. Client <---------ok or error---------- Server
Figure 1: Security negotiation message flow Figure 1: Security agreement message flow.
Step 1: Clients wishing to use this specification can send a list of Step 1: Clients wishing to use this specification can send a list of
their supported security mechanisms along the first request to the their supported security mechanisms along the first request to the
server. server.
Step 2: Servers wishing to use this specification can challenge the Step 2: Servers wishing to use this specification can challenge the
client to perform the security agreement procedure. The security client to perform the security agreement procedure. The security
mechanisms and parameters supported by the server are sent along in mechanisms and parameters supported by the server are sent along
this challenge. in this challenge.
Step 3: The client then proceeds to select the highest-preference Step 3: The client then proceeds to select the highest-preference
security mechanism they have in common and to turn on the selected security mechanism they have in common and to turn on the selected
security. security.
Step 4: The client contacts the server again, now using the selected Step 4: The client contacts the server again, now using the selected
security mechanism. The server's list of supported security security mechanism. The server's list of supported security
mechanisms is returned as a response to the challenge. mechanisms is returned as a response to the challenge.
Step 5: The server verifies its own list of security mechanisms in Step 5: The server verifies its own list of security mechanisms in
order to ensure that the original list had not been modified. order to ensure that the original list had not been modified.
This procedure is stateless for servers (unless the used security This procedure is stateless for servers (unless the used security
mechanisms require the server to keep some state). mechanisms require the server to keep some state).
The client and the server lists are both static (i.e., they do not The client and the server lists are both static (i.e., they do not
and cannot change based on the input from the other side). Nodes may, and cannot change based on the input from the other side). Nodes
however, maintain several static lists, one for each interface, for may, however, maintain several static lists, one for each interface,
example. for example.
Between Steps 1 and 2, the server may set up a non-self-describing Between Steps 1 and 2, the server may set up a non-self-describing
security mechanism if necessary. Note that with this type of security security mechanism if necessary. Note that with this type of
mechanisms, the server is necessarily stateful. The client would set security mechanisms, the server is necessarily stateful. The client
up the non-self-describing security mechanism between Steps 2 and 4. would set up the non-self-describing security mechanism between Steps
2 and 4.
3.3. Syntax 2.2 Syntax
We define three new SIP header fields, namely Security-Client, We define three new SIP header fields, namely Security-Client,
Security-Server and Security-Verify. Their BNF syntax is provided Security-Server and Security-Verify. The notation used in the
below: Augmented BNF definitions for the syntax elements in this section is
as used in SIP [1], and any elements not defined in this section are
as defined in SIP and the documents to which it refers:
security-client = "Security-Client" HCOLON security-client = "Security-Client" HCOLON
sec-mechanism *(COMMA sec-mechanism) sec-mechanism *(COMMA sec-mechanism)
security-server = "Security-Server" HCOLON security-server = "Security-Server" HCOLON
sec-mechanism *(COMMA sec-mechanism) sec-mechanism *(COMMA sec-mechanism)
security-verify = "Security-Verify" HCOLON security-verify = "Security-Verify" HCOLON
sec-mechanism *(COMMA sec-mechanism) sec-mechanism *(COMMA sec-mechanism)
sec-mechanism = mechanism-name *(SEMI mech-parameters) sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest-integrity" / "tls" / "ipsec-ike" / mechanism-name = ( "digest" / "tls" / "ipsec-ike" /
"ipsec-man" / "smime" / token ) "ipsec-man" / token )
mech-parameters = ( preference / algorithm / extension ) mech-parameters = ( preference / digest-algorithm /
digest-qop / digest-verify / extension )
preference = "q" EQUAL qvalue preference = "q" EQUAL qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
algorithm = "alg" EQUAL token digest-algorithm = "d-alg" EQUAL token
digest-qop = "d-qop" EQUAL token
digest-verify = LDQUOT 32LHEX RDQUOT
extension = generic-param extension = generic-param
Note that qvalue is already defined in the SIP BNF [1]. We have Note that qvalue is already defined in the SIP BNF [1]. We have
copied its definitions here for completeness. copied its definitions here for completeness.
The parameters described by the BNF above have the following The parameters described by the BNF above have the following
semantics: semantics:
Mechanism-name: It identifies the security mechanism supported by Mechanism-name
the client, when it appears in a Security-Client header fields, or This token identifies the security mechanism supported by the
by the server, when it appears in a Security-Server or in a client, when it appears in a Security-Client header field; or by
Security-Verify header field. This specification defines five the server, when it appears in a Security-Server or in a Security-
values: Verify header field. The mechanism-name tokens are registered
with the IANA. This specification defines four values:
- "tls" for TLS [3]. * "tls" for TLS [3].
- "digest-integrity" for HTTP Digest [4] using additional
integrity protection for the Security-Verify header field. The
additional integrity protection consists of using the qop
parameter to protect a MIME body (e.g., "message/sip") that
contains the Security-Verify header field.
- "ipsec-ike" for IPsec 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 * "digest" for HTTP Digest [4].
particular mechanism. The higher the value the more preferred the
mechanism is. All the security mechanisms MUST have different "q"
values. It is an error to provide two mechanisms with the same "q"
value.
Algorithm: An optional algorithm field for those security * "ipsec-ike" for IPsec with IKE [2].
mechanisms which are not self-describing or which are vulnerable
for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP
Digest, the same rules apply as defined in RFC 2617 [4] for the
"algorithm" field in HTTP Digest.
3.4. Protocol Operation * "ipsec-man" for manually keyed IPsec without IKE.
Preference
The "q" value indicates a relative preference for the particular
mechanism. The higher the value the more preferred the mechanism
is. All the security mechanisms MUST have different "q" values.
It is an error to provide two mechanisms with the same "q" value.
Digest-algorithm
This optional parameter is defined here only for HTTP Digest [4]
in order to prevent the bidding-down attack for the HTTP Digest
algorithm parameter. The content of the field may have same
values as defined in [4] for the "algorithm" field.
Digest-qop
This optional parameter is defined here only for HTTP Digest [4]
in order to prevent the bidding-down attack for the HTTP Digest
qop parameter. The content of the field may have same values as
defined in [4] for the "qop" field.
Digest-verify
This optional parameter is defined here only for HTTP Digest [4]
in order to prevent the bidding-down attack for the SIP security
mechanism agreement (this document). The 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:
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
digest-verify parameter. Method, digest-uri-value, entity-body,
and any other HTTP Digest parameter are as specified in [4].
Note that this specification does not introduce any extension or
change to HTTP Digest [4]. This specification only re-uses the
existing HTTP Digest mechanisms to protect the negotiation of
security mechanisms between SIP entities.
2.3 Protocol Operation
This section deals with the protocol details involved in the This section deals with the protocol details involved in the
negotiation between a SIP entity and its next-hop SIP entity. negotiation between a SIP UA and its next-hop SIP entity. Throughout
Throughout the text the next-hop SIP entity is referred to as the the text the next-hop SIP entity is referred to as the first-hop
first-hop proxy or outbound proxy. However, the reader should bear in proxy or outbound proxy. However, the reader should bear in mind
mind that a user agent server can also be the next-hop for a proxy that a user agent server can also be the next-hop for a user agent
or, in absence of proxies, for a user agent client. Note as well that client.
a proxy can also have an outbound proxy.
3.4.1 Client Initiated 2.3.1 Client Initiated
A client wishing to establish some type of security with its first- If a client ends up using TLS to contact the server because it has
hop proxy MUST add a Security-Client header field to a request followed the rules specified in [5], the client MUST NOT use the
addressed to this proxy (i.e., the destination of the request is the security agreement procedure of this specification. If a client ends
first-hop proxy). This header field contains a list of all the up using non-TLS connections because of the rules in [5], the client
security mechanisms that the client supports. The client SHOULD NOT MAY use the security agreement of this specification to detect DNS
add preference parameters to this list. The client MUST add both a spoofing, or to negotiate some other security than TLS.
A client wishing to use the security agreement of this specification
MUST add a Security-Client header field to a request addressed to its
first-hop proxy (i.e., the destination of the request is the first-
hop proxy). This header field contains a list of all the security
mechanisms that the client supports. The client SHOULD NOT add
preference parameters to this list. The client MUST add both a
Require and Proxy-Require header field with the value "sec-agree" to Require and Proxy-Require header field with the value "sec-agree" to
its request. its request.
The Security-Client header field is used by the server to include any The contents of the Security-Client header field may be used by the
necessary information in its response. For example, if digest- server to include any necessary information in its response.
integrity is the chosen mechanism, the server includes an HTTP
authentication challenge in the response. If S/MIME is chosen, the
appropriate certificate is included.
A server receiving an unprotected request that contains a Require or A server receiving an unprotected request that contains a Require or
Proxy-Require header field with the value "sec-agree" MUST challenge Proxy-Require header field with the value "sec-agree" MUST respond to
the client with a 494 (Security Agreement Required) response. The the client with a 494 (Security Agreement Required) response. The
server MUST add a Security-Server header field to this response server MUST add a Security-Server header field to this response
listing the security mechanisms that the server supports. The server listing the security mechanisms that the server supports. The server
MUST add its list to the response even if there are no common MUST add its list to the response even if there are no common
security mechanisms in the client's and server's lists. The serverĘs security mechanisms in the client's and server's lists. The server's
list MUST NOT depend on the contents of the client's list. list MUST NOT depend on the contents of the client's list.
The server MUST compare the list received in the Security-Client The server MUST compare the list received in the Security-Client
header field with the list to be sent in the Security-Server header header field with the list to be sent in the Security-Server header
field. When the client receives this response, it will choose the field. When the client receives this response, it will choose the
common security mechanism with the highest "q" value. Therefore, the common security mechanism with the highest "q" value. Therefore, the
server MUST add the necessary information so that the client can server MUST add the necessary information so that the client can
initiate that mechanism (e.g., a WWW-Authenticate header field for initiate that mechanism (e.g., a Proxy-Authenticate header field for
digest-integrity). HTTP Digest).
When the client receives a response with a Security-Server header When the client receives a response with a Security-Server header
field, it MUST choose the security mechanism in the serverĘs list field, it MUST choose the security mechanism in the server's list
with the highest "q" value among all the mechanisms that are known to with the highest "q" value among all the mechanisms that are known to
the client. Then, it MUST initiate that particular security mechanism the client. Then, it MUST initiate that particular security
as described in Section 3.5. This initiation may be carried out mechanism as described in Section 3.5. This initiation may be
without involving any SIP message exchange (e.g., establishing a TLS carried out without involving any SIP message exchange (e.g.,
connection). establishing a TLS connection).
If an attacker modified the Security-Client header field in the If an attacker modified the Security-Client header field in the
request, the server may not include in its response the information request, the server may not include in its response the information
needed to establish the common security mechanism with the highest needed to establish the common security mechanism with the highest
preference value (e.g., the WWW-authenticate header field is preference value (e.g., the Proxy-Authenticate header field is
missing). A client detecting such a lack of information in the missing). A client detecting such a lack of information in the
response MUST consider the current security negotiation process response MUST consider the current security agreement process
aborted, and MAY try to start it again by sending a new request with aborted, and MAY try to start it again by sending a new request with
a Security-Client header field as described above. a Security-Client header field as described above.
All the subsequent SIP requests sent by the client to that server All the subsequent SIP requests sent by the client to that server
SHOULD make use of the security mechanism initiated in the previous SHOULD make use of the security mechanism initiated in the previous
step. These requests MUST contain a Security-Verify header field that step. These requests MUST contain a Security-Verify header field
mirrors the serverĘs list received previously in the Security-Server that mirrors the server's list received previously in the Security-
header field. These requests MUST also have both a Require and Proxy- Server header field. These requests MUST also have both a Require
Require header fields with the value "sec-agree". and Proxy- Require header fields with the value "sec-agree".
The server MUST check that the security mechanisms listed in the The server MUST check that the security mechanisms listed in the
Security-Verify header field of incoming requests correspond to its Security-Verify header field of incoming requests correspond to its
static list of supported security mechanisms. static list of supported security mechanisms.
Note that, following the standard SIP header field comparison rules Note that, following the standard SIP header field comparison
defined in [1], both lists have to contain the same security rules defined in [1], both lists have to contain the same security
mechanisms in the same order to be considered equivalent. In mechanisms in the same order to be considered equivalent. In
addition, for each particular security mechanism, its parameters in addition, for each particular security mechanism, its parameters
both lists need to have the same values. in both lists need to have the same values.
The server can proceed processing a particular request if, and only The server can proceed processing a particular request if, and only
if, the list was not modified. If modification of the list is if, the list was not modified. If modification of the list is
detected, the server MUST challenge the client with a 494 (Security detected, the server MUST respond to the client with a 494 (Security
Agreement Required). This response MUST include a challenge with Agreement Required) response. This response MUST include the
server's unmodified list of supported security mechanisms. If the server's unmodified list of supported security mechanisms. If the
list was not modified, and the server is a proxy, it MUST remove the list was not modified, and the server is a proxy, it MUST remove the
"sec-agree" value from both the Require and Proxy-Require header "sec-agree" value from both the Require and Proxy-Require header
fields, and then remove the header fields if no values remain. fields, and then remove the header fields if no values remain.
Once the security has been negotiated between two SIP entities, the Once the security has been negotiated between two SIP entities, the
same SIP entities MAY use the same security when communicating with same SIP entities MAY use the same security when communicating with
each other in different SIP roles. For example, if a UAC and its each other in different SIP roles. For example, if a UAC and its
outbound proxy negotiate some security, they may try to use the same 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 security for incoming requests (i.e., the UA will be acting as a
UAS). UAS).
The user of a UA SHOULD be informed about the results of the security The user of a UA SHOULD be informed about the results of the security
mechanism negotiation. The user MAY decline to accept a particular mechanism agreement. The user MAY decline to accept a particular
security mechanism, and abort further SIP communications with the security mechanism, and abort further SIP communications with the
peer. peer.
3.4.2 Server Initiated 2.3.2 Server Initiated
A server decides to use the security negotiation described in this A server decides to use the security agreement described in this
document based on local policy. A server that decides to use this document based on local policy. If a server receives a request from
negotiation MUST challenge unprotected requests regardless of the the network interface that is configured to use this mechanism, it
must check that the request has only one Via header field. If there
are several Via header fields, the server is not the first-hop SIP
entity, and it MUST NOT use this mechanism. For such a request, the
server must return a 502 (Bad Gateway) response.
A server that decides to use this agreement mechanism MUST challenge
unprotected requests with one Via header field regardless of the
presence or the absence of any Require, Proxy-Require or Supported presence or the absence of any Require, Proxy-Require or Supported
header fields in incoming requests. header fields in incoming requests.
A server that by policy requires the use of this specification and A server that by policy requires the use of this specification and
receives a request that does not have the sec-agree option tag in a receives a request that does not have the sec-agree option tag in a
Require, Proxy-Require or Supported header field MUST return a 421 Require, Proxy-Require or Supported header field MUST return a 421
(Extension Required) response. If the request had the sec-agree (Extension Required) response. If the request had the sec-agree
option tag in a Supported header field, it MUST return a 494 option tag in a Supported header field, it MUST return a 494
(Security Agreement Required) response. In both situation the server (Security Agreement Required) response. In both situation the server
MUST also include in the response a Security-Server header field MUST also include in the response a Security-Server header field
listing its capabilities and a Require header field with an option- listing its capabilities and a Require header field with an option-
tag "sec-agree" in it. All the Via header field entries in the tag "sec-agree" in it. The server MUST also add necessary
response except the topmost value MUST be removed. This ensures that information so that the client can initiate the preferred security
the previous hop is the one processing the response (see example in mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest).
Section 5.3).
Clients that support the extension defined in this document MAY add a Clients that support the extension defined in this document MAY add a
Supported header field with a value of "sec-agree". In addition to Supported header field with a value of "sec-agree".
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 2.4 Security Mechanism Initiation
Once the client chooses a security mechanism from the list received Once the client chooses a security mechanism from the list received
in the Security-Server header field from the server, it initiates in the Security-Server header field from the server, it initiates
that mechanism. Different mechanisms require different initiation that mechanism. Different mechanisms require different initiation
procedures. procedures.
If TLS is chosen, the client uses the procedures of Section 8.1.2 of If "tls" is chosen, the client uses the procedures of Section 8.1.2
[1] to determine the URI to be used as an input to the DNS procedures of [1]to determine the URI to be used as an input to the DNS
of [6]. However, if the URI is a sip URI, it MUST treat the scheme as procedures of [5]. However, if the URI is a SIP URI, it MUST treat
if it were sips, not sip. If the URI scheme is not sip, the request the scheme as if it were sips, not sip. If the URI scheme is not
MUST be sent using TLS. sip, the request MUST be sent using TLS.
If digest-integrity is chosen, the 494 (Security Agreement Required) If "digest" is chosen, the 494 (Security Agreement Required) response
response will contain an HTTP Digest authentication challenge. The will contain an HTTP Digest authentication challenge. The client
client MUST use the qop parameter to protect a MIME body (e.g., MUST use the algorithm and qop parameters in the Security-Server
"message/sip") that contains the Security-Verify header field in the header field to replace the same parameters in the HTTP Digest
request. Currently, only the qop value Ęauth-intĘ is able to provide challenge. The client MUST also use the digest-verify parameter to
required protection. Note that digest alone without placing Security- protect the Security-Server header field as specified in 2.2.
Verify header in the body would not fulfill the minimum security
requirements of this specification.
To use "ipsec-ike", the client attempts to establish an IKE To use "ipsec-ike", the client attempts to establish an IKE
connection to the host part of the Request-URI in the first request connection to the host part of the Request-URI in the first request
to the server. If the IKE connection attempt fails, the agreement to the server. If the IKE connection attempt fails, the agreement
procedure MUST be considered to have failed, and MUST be terminated. procedure MUST be considered to have failed, and MUST be terminated.
Note that "ipsec-man" will only work if the communicating SIP Note that "ipsec-man" will only work if the communicating SIP
entities know which keys and other parameters to use. It is outside entities know which keys and other parameters to use. It is outside
the scope of this specification to describe how this information can the scope of this specification to describe how this information can
be made known to the peers. 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 In both IPsec-based mechanisms, it is expected that appropriate
policy entries for protecting SIP have been configured or will be policy entries for protecting SIP have been configured or will be
created before attempting to use the security agreement procedure, created before attempting to use the security agreement procedure,
and that SIP communications use port numbers and addresses according and that SIP communications use port numbers and addresses according
to these policy entries. It is outside the scope of this to these policy entries. It is outside the scope of this
specification to describe how this information can be made known to specification to describe how this information can be made known to
the peers, but it could be typically configured at the same time as the peers, but it would typically be configured at the same time as
the IKE credentials or manual SAs have been entered. the IKE credentials or manual SAs have been entered.
To use S/MIME, the client MUST construct its request using S/MIME. 2.5 Duration of Security Associations
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. Duration of Security Associations
Once a security mechanism has been negotiated, both the server and 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 the client need to know until when it can be used. All the
described in this document have a different way to signal the end of mechanisms described in this document have a different way of
a security association. When TLS is used, the termination of the signaling the end of a security association. When TLS is used, the
connection indicates that a new negotiation is needed. IKE negotiates termination of the connection indicates that a new negotiation is
the duration of a security association. If the credentials provided needed. IKE negotiates the duration of a security association. If
by a client using digest-integrity are not longer valid, the server the credentials provided by a client using digest are no longer
will re-challenge the client. It is assumed that when IPsec-man is valid, the server will re- challenge the client. It is assumed that
used, the same out-of-band mechanism used to distribute keys is used when IPsec-man is used, the same out-of-band mechanism used to
to define the duration of the security association. distribute keys is used to define the duration of the security
association.
3.7. Summary of Header Field Use 2.6 Summary of Header Field Use
The header fields defined in this document may be used to negotiate The header fields defined in this document may be used to negotiate
the security mechanisms between a UAC and other SIP entities the security mechanisms between a UAC and other SIP entities
including UAS, proxy, and registrar. Information about the use of including UAS, proxy, and registrar. Information about the use of
headers in relation to SIP methods and proxy processing is summarized headers in relation to SIP methods and proxy processing is summarized
in Table 1. in Table 1.
Header field where proxy ACK BYE CAN INV OPT REG Header field where proxy ACK BYE CAN INV OPT REG
_________________________________________________________________ _________________________________________________________________
Security-Client R ard - o - o o o Security-Client R ard - o - o o o
Security-Server 401,407,421,494 - o - o o o Security-Server 421,494 - o - o o o
Security-Verify R ard - o - o o o Security-Verify R ard - o - o o o
Header field where proxy SUB NOT PRK IFO UPD MSG Header field where proxy SUB NOT PRK IFO UPD MSG
_________________________________________________________________ _________________________________________________________________
Security-Client R ard o o - o o o Security-Client R ard o o - o o o
Security-Server 401,407,421,494 o o - o o o Security-Server 421,494 o o - o o o
Security-Verify R ard o o - o o o Security-Verify R ard o o - o o o
Table 1: Summary of header usage. Table 1: Summary of Header Usage.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field may be used. The header may not appear in other the header field may be used. The header may not appear in other
types of SIP messages. Values in the where column are: types of SIP messages. Values in the where column are:
- R: Header field may appear in requests. o R: Header field may appear in requests.
- 401, 407 etc.: A numerical value or range indicates response codes o 421, 494: A numerical value indicates response codes with which
with which the header field can be used. the header field can be used.
The "proxy" column describes the operations a proxy may perform on a The "proxy" column describes the operations a proxy may perform on a
header field: header field:
- a: A proxy can add or concatenate the header field if not present. o a: A proxy can add or concatenate the header field if not present.
- r: A proxy must be able to read the header field, and thus this o r: A proxy must be able to read the header field, and thus this
header field cannot be encrypted. header field cannot be encrypted.
- d: A proxy can delete a header field value. o d: A proxy can delete a header field value.
The next six columns relate to the presence of a header field in a The next six columns relate to the presence of a header field in a
method: method:
- o: The header field is optional. o o: The header field is optional.
4. Backwards Compatibility 3. Backwards Compatibility
A server that, by local policy, decides to use the negotiation The use of this extension in a network interface is a matter of local
mechanism defined in this document, will not accept requests from policy. Different network interfaces may follow different policies,
clients that do not support this extension. This obviously breaks and consequently the use of this extension may be situational by
interoperability with every plain SIP client. Therefore, this nature. UA and server implementations MUST be configurable to
extension should be used in environments where it is somehow ensured operate with or without this extension.
that every client implements this extension. This extension may also
be used in environments where insecure communication is not
acceptable if the option of not being able to communicate is also
accepted.
5. Examples A server that is configured to use this 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, and do not
support TLS, can not be accepted. This obviously breaks
interoperability with some SIP clients. Therefore, this extension
should be used in environments where it is somehow ensured that every
client implements this 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.
4. Examples
The following examples illustrate the use of the mechanism defined The following examples illustrate the use of the mechanism defined
above. above.
5.1. Client Initiated 4.1 Client Initiated
A UA negotiates the security mechanism to be used with its outbound A UA negotiates the security mechanism to be used with its outbound
proxy without knowing beforehand which mechanisms the proxy supports. proxy without knowing beforehand which mechanisms the proxy supports.
The OPTIONS method can be used here to request the security
capabilities of the proxy. In this way, the security can be
initiated even before the first INVITE is sent via the proxy.
UAC Proxy UAS UAC Proxy UAS
| | | | | |
|----(1) OPTIONS---->| | |----(1) OPTIONS---->| |
| | | | | |
|<-----(2) 494-------| | |<-----(2) 494-------| |
| | | | | |
|<=======TLS========>| | |<=======TLS========>| |
| | | | | |
|----(3) INVITE----->| | |----(3) INVITE----->| |
| |----(4) INVITE--->| | |----(4) INVITE--->|
| | | | | |
skipping to change at page 12, line 37 skipping to change at page 13, line 26
| |<---(5) 200 OK----| | |<---(5) 200 OK----|
|<---(6) 200 OK------| | |<---(6) 200 OK------| |
| | | | | |
|------(7) ACK------>| | |------(7) ACK------>| |
| |-----(8) ACK----->| | |-----(8) ACK----->|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
Figure 2: Negotiation initiated by the client Figure 2: Negotiation Initiated by the Client.
The UAC sends an OPTIONS request to its outbound proxy, indicating The UAC sends an OPTIONS request to its outbound proxy, indicating at
that it is able to negotiate security mechanisms and that it supports the same time that it is able to negotiate security mechanisms and
TLS and digest-integrity (Step 1 of figure 1). The outbound proxy that it supports TLS and HTTP Digest (1).
challenges the UAC with its own list of security mechanisms ū IPsec
and TLS (Step 2 of figure 1). The only common security mechanism is The outbound proxy responds to the UAC with its own list of security
TLS, so they establish a TLS connection between them (Step 3 of mechanisms - IPsec and TLS (2). The only common security mechanism
figure 1). When the connection is successfully established, the UAC is TLS, so they establish a TLS connection between them. When the
sends an INVITE over the TLS connection just established (Step 4 of connection is successfully established, the UAC sends an INVITE
figure 1). This INVITE contains the serverĘs security list. The request over the TLS connection just established (3). This INVITE
server verifies it, and since it matches its static list, it contains the server's security list. The server verifies it, and
processes the INVITE and forwards it to the next hop. 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 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 UAC would not know what kind of security the other one supports, and
would be forced to error-prone trials. would be forced to error-prone trials.
More seriously, if the Security-Verify was omitted in Step 4, the More seriously, if the Security-Verify was omitted in Step 3, the
whole process would be prone for MitM attacks. An attacker could whole process would be prone for MitM attacks. An attacker could
spoof "ICMP Port Unreachable" message on the trials, or remove the spoof "ICMP Port Unreachable" message on the trials, or remove the
stronger security option from the header in Step 1, therefore stronger security option from the header in Step 1, therefore
substantially reducing the security. substantially reducing the security.
(1) OPTIONS sip:proxy.example.com SIP/2.0 (1) OPTIONS sip:proxy.example.com SIP/2.0
Security-Client: tls Security-Client: tls
Security-Client: digest-integrity Security-Client: digest
Require: sec-agree Require: sec-agree
Proxy-Require: sec-agree Proxy-Require: sec-agree
(2) SIP/2.0 494 Security Agreement Required (2) SIP/2.0 494 Security Agreement Required
Security-Server: ipsec-ike;q=0.1 Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2 Security-Server: tls;q=0.2
(3) INVITE sip:proxy.example.com SIP/2.0 (3) INVITE sip:proxy.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1 Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2 Security-Verify: tls;q=0.2
Route: sip:callee@domain.com Route: sip:callee@domain.com
Require: sec-agree Require: sec-agree
Proxy-Require: sec-agree Proxy-Require: sec-agree
The 200 OK response for the INVITE and the ACK are also sent over the The 200 OK response (6) for the INVITE and the ACK (7) are also sent
TLS connection. The ACK (7) will contain the same Security-Verify over the TLS connection. The ACK will contain the same Security-
header field as the INVITE (3). Verify header field as the INVITE (3).
5.2. Server Initiated 4.2 Server Initiated
In this example of figure 3 the client sends an INVITE towards the In this example of figure 3 the client sends an INVITE towards the
callee using an outbound proxy. This INVITE does not contain any callee using an outbound proxy. This INVITE does not contain any
Require header field. Require header field.
UAC Proxy UAS UAC Proxy UAS
| | | | | |
|-----(1) INVITE---->| | |-----(1) INVITE---->| |
| | | | | |
|<-----(2) 421-------| | |<-----(2) 421-------| |
| | | | | |
|------(3) ACK------>| | |------(3) ACK------>| |
| | | | | |
|<=======IKE========>| | |<=======IKE========>| |
| | | | | |
|-----(4) INVITE---->| | |-----(4) INVITE---->| |
skipping to change at page 13, line 56 skipping to change at page 15, line 26
| |----(5) INVITE--->| | |----(5) INVITE--->|
| | | | | |
| |<---(6) 200 OK----| | |<---(6) 200 OK----|
|<----(7) 200 OK-----| | |<----(7) 200 OK-----| |
| | | | | |
|------(8) ACK------>| | |------(8) ACK------>| |
| |-----(9) ACK----->| | |-----(9) ACK----->|
| | | | | |
| | | | | |
Figure 3: Server initiated security negotiation Figure 3: Server Initiated Security Negotiation.
The proxy, following its local policy, challenges the INVITE. It
returns a 421 (Extension Required) with a Security-Server header The proxy, following its local policy, 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 field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE
it performs the key exchange and establishes a security association it performs the key exchange and establishes a security association
with the proxy. The second INVITE (4) and the ACK (8) contain a with the proxy.
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 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.
The example in Figure 4 shows a security negotiation between two (1) INVITE sip:uas.example.com SIP/2.0
adjacent proxies. P1 forwards an INVITE (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 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
(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 (2) SIP/2.0 421 Extension Required
| | | | Security-Server: ipsec-ike;q=0.1
|-(1) INVITE->| | | Security-Server: tls;q=0.2
| |-(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 (4) INVITE sip:uas.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
6. Security Considerations 5. Security Considerations
This specification is about making it possible to select between This specification is about making it possible to select between
various SIP security mechanisms in a secure manner. In particular, various SIP security mechanisms in a secure manner. In particular,
the method presented here allow current networks using, for instance, the method presented herein allow current networks using, for
Digest, to be securely upgraded to, for instance, IPsec without instance, HTTP Digest, to be securely upgraded to, for instance,
requiring a simultaneous modification in all equipment. The method IPsec without requiring a simultaneous modification in all equipment.
presented in this specification is secure only if the weakest The method presented in this specification is secure only if the
proposed mechanism offers at least integrity protection. weakest proposed mechanism offers at least integrity and replay
protection for the Security-Verify header field.
Attackers could try to modify the server's list of security 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
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 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 security agreement include:
1. Attackers could try to modify the server's list of security
mechanisms in the first response. This would be revealed to the mechanisms in the first response. This would be revealed to the
server when the client returns the received list using the security. server when the client returns the received list using the
security.
Attackers could also try to modify the repeated list in the second 2. Attackers could also try to modify the repeated list in the
request from the client. However, if the selected security mechanism second request from the client. However, if the selected
uses encryption this may not be possible, and if it uses integrity security mechanism uses encryption this may not be possible, and
protection any modifications will be detected by the server. 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 3. Attackers could try to modify the client's list of security
mechanisms in the first message. The client selects the security mechanisms in the first message. The client selects the security
mechanism based on its own knowledge of its own capabilities and the mechanism based on its own knowledge of its own capabilities and
server's list, hence the client's choice would be unaffected by any the server's list, hence the client's choice would be unaffected
such modification. However, the server's choice could still be by any such modification. However, the server's choice could
affected as described below: still be affected as described below:
- If the modification affected the server's choice, the server and * If the modification affected the server's choice, the server
client would end up choosing different security mechanisms in Step 3 and client would end up choosing different security mechanisms
or 4 of figure 1. Since they would be unable to communicate to each in Step 3 or 4 of figure 1. Since they would be unable to
other, this would be detected as a potential attack. The client would communicate to each other, this would be detected as a
either retry or give up in this situation. 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 * If the modification did not affect the server's choice,
effect. there's no effect.
All clients that implement this specification MUST select HTTP Digest 4. Finally, attackers may also try to reply old security agreement
with integrity, TLS, IPsec, or any stronger method for the protection messages. Each security mechanism must provide replay
of the second request. 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].
7. IANA Considerations All clients that implement this specification MUST select HTTP
Digest, TLS, IPsec, or any stronger method for the protection of the
second request.
This specification defines three new header fields, namely Security- 6. IANA Considerations
Client, Security-Server and Security-Verify that should be included
in the registry for SIP header fields maintained by IANA.
This specification defines the 'sec-agree' SIP option tag which This specification defines a new mechanism-name namespace in Section
should be registered in IANA. 2.2 which requires a central coordinating body. The body responsible
for this coordination is the Internet Assigned Numbers Authority
(IANA).
This specification also defines a new SIP status code, 494 (Security This document defines four mechanism-names to be initially
Agreement Failed), which should be registered in IANA. 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
[10], further mechanism-names are allocated based on IETF Consensus.
8. Acknowledgments Registrations with the IANA MUST include the mechanism-name token
The authors wish to thank Lee Valerius, Allison Mankin, Rolf Blom, being registered, and a pointer to a published RFC describing the
James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister details of the corresponding security mechanism. Further, the
Boman, David Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri registration MUST include contact information for the party
Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP SA3 responsible for the registration.
group for interesting discussions in this problem space.
9. Normative References 6.1 Registration Information
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. As this document specifies five mechanism-names, the initial IANA
Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation registration for mechanism-names will contain the information shown
Protocol", Work in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, in Table 2. It also demonstrates the type of information maintained
February 2002. by the IANA.
[2] S. Kent, R. Atkinson, "Security Architecture for the Internet Mechanism Name Contact Reference
Protocol", RFC 2401, IETF, November 1998. -------------- ------- ---------
digest [1] [RFCNNNN]
tls [1] [RFCNNNN]
ipsec-ike [1] [RFCNNNN]
ipsec-man [1] [RFCNNNN]
ipsec-3gpp [1] [RFCNNNN]
[3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, People
IETF January 1999. ------
[1] Jari Arkko <Jari.Arkko@ericsson.com>
Vesa Torvinen <Vesa.Torvinen@ericsson.fi>
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Aki Niemi <Aki.Niemi@nokia.com>
Tao Haukka <Tao.Haukka@nokia.com>
[4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access References
Authentication", RFC 2617, IETF, June 1999. ----------
[RFCNNNN] Arkko, et. al., "Security Mechanism Agreement for the
Session Initiation Protocol", RFC NNNN, October 2002.
[5] B. Ramsdell and Ed, "S/MIME version 3 message specification", RFC Table2: Initial IANA registration.
2633, IETF, June 1999.
[6] H. Schulzrinne and J. Rosenberg, "SIP: Locating SIP servers", (Note to RFC Editor: Replace NNNN with the RFC number of this
Work in Progress, draft-ietf-sip-srv-06.txt, IETF, February 2002. document when published.)
10. Non-Normative References 6.2 Registration Template
[7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. To: ietf-sip-sec-agree-mechanism-name@iana.org
Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", Subject: Registration of a new SIP Security Agreement mechanism
draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF,
October 2001.
11. Authors's Addresses Mechanism Name:
(Token value conforming to the syntax described in
Section 2.2.)
Published Specification(s):
(Descriptions of new SIP Security Agreement mechanisms
require a published RFC.)
Person & email address to contact for further information:
(Must contain contact information for the person(s)
responsible for the registration.)
6.3 Header Field Names
This specification registers three new header fields, namely
Security-Client, Security-Server and Security-Verify. These headers
are defined by the following information, which is to be included
inthe sub-registry for SIP headers under http://www.iana.org/
assignments/sip-parameters.
Header Name: Security-Client
Compact Form: (none)
Header Name: Security-Server
Compact Form: (none)
Header Name: Security-Verify
Compact Form: (none)
6.4 Response Codes
This specification registers a new response code, namely 494
(Security Agreement Required). The response code is defined by the
following information, which is to be included to the sub-registry
for SIP methods and response-codes under http://www.iana.org/
assignments/sip-parameters.
Response Code Number: 494
Default Reason Phrase: Security Agreement Required
6.5 Option Tags
This specification defines a new option tag, namely sec-agree. The
option tag is defined by the following information, which is to be
included in the sub-registry for option tags under http://
www.iana.org/assignments/sip-parameters.
Name: sec-agree
Description: This option tag indicates support for the Security
Agreement mechanism. When used in the Require, or
Proxy-Require headers, it indicates that proxy servers
are required to use the Security Agreement mechanism.
When used in the Supported header, it indicates that
the User Agent Client supports the Security Agreement
mechanism. When used in the Require header in the 494
(Security Agreement Required) or 421 (Extension Required)
responses, it indicates that the User Agent Client must
use the Security Agreement Mechanism.
7. Contributors
Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to
the document.
8. Acknowledgements
In addition to the contributors, the authors wish to thank Allison
Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh,
Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia,
Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP
SA3 group for interesting discussions in this problem space.
Normative References
[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
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.
Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
02420 Jorvas Hirsalantie 1
Jorvas, FIN 02420
Finland Finland
EMail: Jari.Arkko@ericsson.com
Phone: +358 40 507 9256
EMail: jari.arkko@ericsson.com
Vesa Torvinen Vesa Torvinen
Ericsson Ericsson
02420 Jorvas Joukahaisenkatu 1
Turku, FIN 20520
Finland Finland
EMail: Vesa.Torvinen@ericsson.fi
Phone: +358 40 723 0822
EMail: vesa.torvinen@ericsson.fi
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
02420 Jorvas Hirsalantie 1
Jorvas, FIN 02420
Finland Finland
EMail: Gonzalo.Camarillo@ericsson.com
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
Tao Haukka Tao Haukka
Nokia Nokia
P.O. Box abc
NOKIA GROUP, FIN 00045
Finland Finland
EMail: Tao.Haukka@nokia.com
Sanjoy Sen Phone: +358 40 517 0079
Nortel Networks EMail: tao.haukka@nokia.com
2735-B Glenville Drive
Richardson, TX 75082, USA Appendix A. Syntax of ipsec-3gpp
EMail: sanjoy@nortelnetworks.com
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 parameter defines the used authentication algorithm. It may
have a 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
This parameter defines the mode in which the IPsec protocol is
used. It may have a value of "trans" for transport mode, or a
value of "tun" for tunneling mode. If no Mode parameter is
present the 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 protected with a single SA. The duration of security
association is the same as in the expiration interval of the
corresponding registration binding.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and 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 above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in 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 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 will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/