draft-ietf-sip-sec-agree-00.txt   draft-ietf-sip-sec-agree-01.txt 
SIP Working Group Jari Arkko SIP Working Group Jari Arkko
INTERNET-DRAFT Vesa Torvinen INTERNET-DRAFT Vesa Torvinen
<draft-ietf-sip-sec-agree-00.txt> Ericsson <draft-ietf-sip-sec-agree-01.txt> Gonzalo Camarillo
April 2002 Tao Haukka May 2002 Ericsson
Expires: December 2002 Tao Haukka
Nokia Nokia
Sanjoy Sen Sanjoy Sen
Lee Valerius
Nortel Networks Nortel Networks
Security Mechanism Agreement for SIP Sessions 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 This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. Internet-Drafts are working docu¡ all provisions of Section 10 of RFC2026.
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work¡ Internet-Drafts are working documents of the Internet Engineering
ing documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at and may be updated, replaced, or obsoleted by other documents at any
any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress. material or cite them other than as "work in progress".
The list of current Internet-Drafts may be found at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories may be found at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. It is filed as <draft- This document is an individual submission to the IETF. Comments
ietf-sip-sec-agree-00.txt>, and expires October, 2002. Please send should be directed to the authors.
comments to the author or to SIPPING or SIP working group.
2. Abstract Abstract
SIP has a number of security mechanisms for hop-by-hop and end-to-end SIP has a number of security mechanisms. Some of them have been built
protection. Some of the security mechanisms have been built in to the in to the SIP protocol, such as HTTP authentication or secure
SIP protocol, such as HTTP authentication or secure attachments. In attachments. These mechanisms have even alternative algorithms and
these mechanisms there are even alternative algorithms and parameters. parameters. SIP does not currently provide any mechanism for
Currently it isn't possible to select which security mechanisms to use selecting which security mechanisms to use over a connection. In
over a connection. In particular, even if some mechanisms such as particular, even if some mechanisms such as OPTIONS were used to make
OPTIONS were used to make this selection, the selection would be vul¡ this selection, the selection would be vulnerable against the
nerable against the Bidding-Down attack. This document defines a Bidding-Down attack. This document defines three header fields for
header for negotiating the security mechanisms within SIP. A SIP negotiating the security mechanisms within SIP between a user agent
entity applying this mechanism must always require some minimum secu¡ client and its next hop SIP entity. A SIP entity applying this
rity (i.e. integrity protection) from all communicating parties in mechanism must always require some minimum security (i.e. integrity
order to secure the negotiation, but the negotiation can agree on protection) from all communicating parties in order to secure the
which specific minimum security is used. negotiation, but the negotiation can agree on which specific minimum
security is used.
3. Contents TABLE OF CONTENTS
1. Status of this Memo..................................1 1. Introduction....................................................2
2. Abstract.............................................1 2. The Problem.....................................................3
3. Contents.............................................2 3. Solution........................................................4
4. Introduction.........................................2 3.1. Requirements...............................................4
5. The Problem..........................................3 3.2. Overview of Operations.....................................5
6. Solution.............................................4 3.3. Syntax.....................................................6
6.1. Requirements.........................................4 3.4. Protocol Operation.........................................7
6.2. Different Mechanisms.................................5 3.4.1 Client Initiated........................................7
6.3. Overview of Operations...............................5 3.4.2 Server Initiated........................................8
6.4. Header descriptions..................................7 3.5. Security Mechanism Initiation..............................9
7. Summary of header usage..............................9 3.6. Duration of the Security Association......................10
8. Backwards Compatibility..............................10 3.7. Summary of Header Field Use...............................10
9. Examples.............................................10 4. Backwards Compatibility........................................11
9.1. Selecting Between New and Old Mechanisms.............10 5. Examples.......................................................11
9.2. Selections Along the Path............................11 5.1. Client Initiated..........................................10
10. Security Considerations..............................13 5.2. Server Initiated..........................................12
11. IANA Considerations..................................13 6. Security Considerations........................................13
12. Modifications........................................14 7. IANA Considerations............................................14
13. Acknowledgments......................................15 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 Traditionally, security protocols have included facilities to agree
the used mechanisms, algorithms, and other security parameters. The on the used mechanisms, algorithms, and other security parameters.
reason for this is that experience has shown that e.g. algorithm The reason for this is that experience has shown that algorithm
development uncovers problems in old algorithms and produces new ones. development uncovers problems in old algorithms and produces new
Furthermore, different mechanisms and algorithms are suitable for dif¡ ones. Furthermore, different mechanisms and algorithms are suitable
ferent situations. Typically, protocols also select other parameters for different situations. Typically, protocols also select other
beyond algorithms at the same time. parameters beyond algorithms at the same time.
The purpose of this specification is to define a similar negotiation The purpose of this specification is to define a similar negotiation
functionality in SIP [1]. SIP has some security functionality built-in functionality in SIP [1]. SIP has some security functionality built-
such as HTTP Digest authentication [4], secure attachments such as in such as HTTP Digest authentication [4], secure attachments such as
S/MIME [5], and can also use underlying security protocols 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 allows also alternative algorithms and other parameters. While some
work within the SIP Working Group has been looking towards reducing work within the SIP Working Group has been looking towards reducing
the number of recommended security solutions (e.g. recommend just one the number of recommended security solutions (i.e., recommend just
lower layer security protocol), we can not expect to cut down the num¡ one lower layer security protocol), we can not expect to cut down the
ber of items in the whole list to one. There will still be multiple number of items in the whole list to one. There will still be
security solutions utilized by SIP. Furthermore, it is likely that new multiple security solutions utilized by SIP. Furthermore, it is
methods will appear in the future, to complete the methods that exist likely that new methods will appear in the future, to complement the
today. methods that exist today.
Chapter 5 shows that without a secured method to choose between secu¡ Chapter 2 shows that without a secured method to choose between
rity mechanisms and/or their parameters, SIP is vulnerable to certain security mechanisms and/or their parameters, SIP is vulnerable to
attacks. As the HTTP authentication RFC [4] points out, authentication certain attacks. As the HTTP authentication RFC [4] points out,
and integrity protection using multiple alternative methods and algo¡ authentication and integrity protection using multiple alternative
rithms is vulnerable to Man-in-the-Middle (MITM) attacks. More seri¡ methods and algorithms is vulnerable to Man-in-the-Middle (MitM)
ously, it is hard or sometimes even impossible to know whether a SIP attacks. More seriously, it is hard or sometimes even impossible to
peer entity is truly unable to perform e.g. Digest, TLS, or S/MIME, know whether a SIP peer entity is truly unable to perform (e.g.,
or if a MITM attack is in action. In small networks consisting of Digest, TLS, or S/MIME) or if a MitM attack is in action. In small
workstations and servers these issues are not very relevant, as the networks consisting of workstations and servers these issues are not
administrators can deploy appropriate software versions and set up very relevant, as the administrators can deploy appropriate software
policies for using exactly the right type of security. However, SIP versions and set up policies for using exactly the right type of
will soon be deployed to hundreds of millions of small devices with security. However, SIP will be deployed to hundreds of millions of
little or no possibilities for coordinated security policies, let small devices with little or no possibilities for coordinated
alone software upgrades, and this makes these issues much worse. This security policies, let alone software upgrades, and this makes these
conclusion is also supported by the requirements from 3GPP [6]. 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 Chapter 6 documents the proposed solution, and chapter 7 gives some
demonstrative examples. demonstrative examples.
5. The Problem 2. Problem Description
SIP has alternative security mechanisms such as HTTP authentication / SIP has alternative security mechanisms such as HTTP authentication
integrity protection, lower layer security protocols, and S/MIME. It with integrity protection, lower layer security protocols, and
is likely that their use will continue in the future. SIP security is S/MIME. It is likely that their use will continue in the future. SIP
developing, and is likely to see also new solutions in the future. 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 Deployment of large number of SIP-based consumer devices such as 3GPP
terminals requires all network devices to be able to accommodate past, terminals requires all network devices to be able to accommodate
current and future mechanisms; there is no possiblity for instanta¡ past, current and future mechanisms; there is no possibility for
neous change since the new solutions are coming gradually in as new instantaneous change since the new solutions are coming gradually in
standards and product releases occur. It is sometimes even impossible as new standards and product releases occur. It is sometimes even
to upgrade some of the devices without getting completely new hard¡ impossible to upgrade some of the devices without getting completely
ware. new hardware.
So, the basic security problem that such a large SIP-based network So, the basic security problem that such a large SIP-based network
must consider, would be on how do security mechanisms get selected? It must consider, would be on how do security mechanisms get selected?
would be desirable to take advantage of new mechanisms as they become It would be desirable to take advantage of new mechanisms as they
available in products. become available in products.
Firstly, we need to know somehow what security should be applied, and Firstly, we need to know somehow what security should be applied, and
preferably find this out without too many additional roundtrips. preferably find this out without too many additional roundtrips.
Secondly, selection of security mechanisms MUST be secure. Tradition¡ Secondly, selection of security mechanisms MUST be secure.
ally, all security protocols use a secure form of negotiation. For Traditionally, all security protocols use a secure form of
instance, after establishing mutual keys through Diffie-Hellman, IKE negotiation. For instance, after establishing mutual keys through
sends hashes of the previously sent data -- including the offered Diffie-Hellman, IKE sends hashes of the previously sent data --
crypto mechanisms. This allows the peers to detect if the initial, including the offered crypto mechanisms. This allows the peers to
unprotected offers were tampered with. detect if the initial, unprotected offers were tampered with.
The security implications of this are subtle, but do have a fundamen¡ The security implications of this are subtle, but do have a
tal importance in building large networks that change over time. Given fundamental importance in building large networks that change over
that the hashes are produced also using algorithms agreed in the first time. Given that the hashes are produced also using algorithms agreed
unprotected messages, one could ask what the difference in security in the first unprotected messages, one could ask what the difference
really is. Assuming integrity protection is mandatory and only secure in security really is. Assuming integrity protection is mandatory and
algorithms are used, we still need to prevent MITM attackers from mod¡ only secure algorithms are used, we still need to prevent MitM
ifying other parameters, such as whether encryption is provided or attackers from modifying other parameters, such as whether encryption
not. Let us first assume two peers capable of using both strong and is provided or not. Let us first assume two peers capable of using
weak security. If the initial offers are not protected in any way, any both strong and weak security. If the initial offers are not
attacker can easily "downgrade" the offers by removing the strong protected in any way, any attacker can easily "downgrade" the offers
options. This would force the two peers to use weak security between by removing the strong options. This would force the two peers to use
them. But if the offers are protected in some way -- such as by hash¡ weak security between them. But if the offers are protected in some
ing, or repeating them later when the selected security is really on way -- such as by hashing, or repeating them later when the selected
-- the situation is different. It would not be sufficient for the security is really on -- the situation is different. It would not be
attacker to modify a single message. Instead, the attacker would have sufficient for the attacker to modify a single message. Instead, the
to modify both the offer message, as well as the message that contains attacker would have to modify both the offer message, as well as the
the hash/repetition. More importantly, the attacker would have to message that contains the hash/repetition. More importantly, the
forge the weak security that is present in the second message, and attacker would have to forge the weak security that is present in the
would have to do so in real time between the sent offers and the later second message, and would have to do so in real time between the sent
messages. Otherwise, the peers would notice that the hash is incor¡ offers and the later messages. Otherwise, the peers would notice that
rect. If the attacker is able to break the weak security, the security the hash is incorrect. If the attacker is able to break the weak
method and/or the algorithm should not be used. security, the security method and/or the algorithm should not be
used.
In conclusion, the security difference is making a trivial attack pos¡ In conclusion, the security difference is making a trivial attack
sible versus demanding the attacker to break algorithms. An example of possible versus demanding the attacker to break algorithms. An
where this has a serious consequence is when a network is first example of where this has a serious consequence is when a network is
deployed with integrity protection (such as HTTP Digest [4]), and then first deployed with integrity protection (such as HTTP Digest [4]),
later new devices are added that support also encryption (such as and then later new devices are added that support also encryption
S/MIME [1]). In this situation, an insecure negotiation procedure (such as S/MIME [1]). In this situation, an insecure negotiation
allows attackers to trivially force even new devices to use only procedure allows attackers to trivially force even new devices to use
integrity protection. only integrity protection.
6. Solution 3. Solution
6.1. Requirements 3.1 Requirements
The solution to the SIP security negotiation problem should have the The solution to the SIP security negotiation problem should have the
following properties: following properties:
(a) It allows the selection of security mechanisms, such as lower (a) It allows the selection of security mechanisms, such as lower
layer security protocols or secure attachments. It also allows the layer security protocols or HTTP digest. It also allows the selection
selection of individual algorithms and parameters when the security of individual algorithms and parameters when the security functions
functions are integrated in SIP (such as in the case of HTTP authenti¡ are integrated in SIP (such as in the case of HTTP authentication).
cation or secure attachments).
(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 (d) It is capable of running without additional roundtrips. This is
important in the cellular environment, where an additional roundtrip important in the cellular environment, where an additional roundtrip
could delay the call set up for 1000-1500 ms. 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 Currently, SIP does not have any mechanism which fulfills all the
requirements above. The basic SIP features such as OPTIONS and requirements above. The basic SIP features such as OPTIONS and
Require, Supported headers are capable of informing peers about vari¡ Require, Supported headers are capable of informing peers about
ous capabilities including security mechanisms. However, the straight¡ various capabilities including security mechanisms. However, the
forward use of these features can not guarantee a secured agreement. straight forward use of these features can not guarantee a secured
HTTP Digest algorithm lists [4] are not secure for picking among the agreement. HTTP Digest algorithm lists [4] are not secure for picking
digest integrity algorithms, as is described in the RFC itself. More among the digest integrity algorithms, as is described in the RFC
seriously, they have no provisions for allowing encryption to be nego¡ itself. More seriously, they have no provisions for allowing
tiated. Hence, it would be hard to turn on possible future encryption encryption to be negotiated. Hence, it would be hard to turn on
schemes in a secure manner. possible future encryption schemes in a secure manner.
6.2. Different Mechanisms
A self-describing security mechanism is a security mechanism that, A self-describing security mechanism is a security mechanism that,
when used, contains all necessary information about the method being when used, contains all necessary information about the method being
used as well as all of its parameters such as algorithms. used as well as all of its parameters such as algorithms.
A non-self-describing security mechanism is a security mechanism that, A non-self-describing security mechanism is a security mechanism
when used, requires that the use of the method or some of its parame¡ that, when used, requires that the use of the method or some of its
ters have been agreed beforehand. parameters have been agreed beforehand.
Most security mechanisms used with SIP are self-describing. The use Most security mechanisms used with SIP are self-describing. The use
of HTTP digest, as well as the chosen algorithm is visible from the 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 HTTP authentication headers. The use of S/MIME is indicated by the
MIME headers, and the CMS structures inside S/MIME describe the used 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 algorithms. TLS is run on a separate port in SIP, and where IPsec/IKE
is used, IKE negotiates all the necessary parameters. is used, IKE negotiates all the necessary parameters.
The only exception to this list is the use of manually keyed IPsec. The only exception to this list is the use of manually keyed IPsec.
IPsec headers do not contain information about the used algorithms. IPsec headers do not contain information about the used algorithms.
Furthermore, peers have to set up IPsec Security Associations before Furthermore, peers have to set up IPsec Security Associations before
they can be used to receive traffic. In contrast S/MIME can be they can be used to receive traffic. In contrast S/MIME can be
received even if no Security Association was in place, because the received even if no Security Association was in place, because the
application can search for a Security Association (or create a new application can search for a Security Association (or create a new
one) after having received a message that contains S/MIME. one) after having received a message that contains S/MIME.
In order to make it possible to negotiate both self-describing and In order to make it possible to negotiate both self-describing and
non-self-describing security mechanisms, the security agreement scheme non-self-describing security mechanisms, we need another requirement
must allow both sides to decide on the desired security mechanism on the security agreement scheme:
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.
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 This decision can, and must, take place on both sides before we can
servers offer their lists of supported security mechanisms and parame¡ be sure that the negotiation has not been tampered by a man-in-the-
ters in the first, unprotected messages. They then proceed to turn on middle. This tampering will be detected later.
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).
The client and the server lists are both static i.e. they do not and 3.2. Overview of Operations
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¡ The message flow below illustrates how the mechanism defined in this
ple. 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
The steps are explained below:
- Step 1: The client MUST announce a list of supported security mecha¡ Figure 1: Security negotiation message flow
nisms in their fist request. The client SHOULD also add the option-tag
'sec-agree' to the Supported header.
- Step 2: The server MUST announce a list of supported security mecha¡ Step 1: Clients wishing to use this specification can send a list of
nisms in their first response. The server MUST add its list to the their supported security mechanisms along the first request to the
response even if there were no common security mechanisms in the server.
client's and server's lists, and the list MUST NOT depend on the con¡
tents of the client's list. The list MUST also be added regardless of
any potential error codes in the response.
An error has occurred if the client list is not present in the request Step 2: Servers wishing to use this specification can challenge the
of Step 1, this request is not OPTIONS, and the server's policy client to perform the security agreement procedure. The security
requires the use of this specification. This error will be reported by mechanisms and parameters supported by the server are sent along in
returning 421 (Extension Required). In this case the server MUST also this challenge.
include a Require header with an option-tag 'sec-agree' in its
response.
- Step 3: The peers MUST initiate the security mechanism, if necessary Step 3: The client then proceeds to select the highest-preference
to carry this outside the request in Step 4. For instance, TLS should security mechanism they have in common and to turn on the selected
be turned on at this stage. security.
- Step 4: The client MUST select and use the first matching security Step 4: The client contacts the server again, now using the selected
mechanism from the server's list. The client MUST also repeat the security mechanism. The server's list of supported security
server's list. mechanisms is returned as a response to the challenge.
- Step 5: The server MUST check that the server list sent in the Step 5: The server verifies its own list of security mechanisms in
secured message in Step 4 corresponds to its static list of supported order to ensure that the original list had not been modified.
security mechanisms. The server MUST send a positive answer or pro¡
ceed to execute the requested operation if and only if the list was
not modified. If modification of the list is detected, the server
MUST return a 494 (Security Agreement Failed) response or disconnect.
The 494 response MUST include server's unmodified list of supported
security mechanisms. The server MUST NOT copy any Security-Mechanism
header from the request in Step 4 to the 494 response in Step 5.
The server MAY decide to use a security mechanism between Steps 1 and This procedure is stateless for servers (unless the used security
2 but it MUST do so before processing request in Step 4. The client mechanisms require the server to keep some state).
MUST decide to use a security mechanism between Steps 2 and 3.
Between Steps 1 and 2, the server MAY set up a non-self-describing 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,
however, maintain several static lists, one for each interface, for
example.
Between Steps 1 and 2, the server may set up a non-self-describing
security mechanism if necessary. Note that with this type of security security mechanism if necessary. Note that with this type of security
mechanisms, the server is necessarily stateful. Between Steps 2 and 4, mechanisms, the server is necessarily stateful. The client would set
the client MAY set up a non-self-describing security mechanism. up the non-self-describing security mechanism between Steps 2 and 4.
Note that non-adjacent SIP entities can not use hop-by-hop security 3.3. Syntax
mechanisms such as TLS or IPsec. If a client receives a list of hop-
by-hop security mechanisms from a server several hops away, it MUST
NOT try to use these mechanisms with the first hop proxy. The client
MAY try to contact the server directly leaving the proxies in between
away.
Once the security has been negotiated between two SIP entities, the We define three new SIP header fields, namely Security-Client,
same SIP entities MAY use the same security when communicating with Security-Server and Security-Verify. Their BNF syntax is provided
each other in different SIP roles. For example, if a UAC in a end-user below:
equipment and a UAS in a proxy negotiate some security, they may try
to use the same security for terminating requests.
The results of the security mechanism negotiation MAY be informed to security-client = "Security-Client" HCOLON
the user of an UAC or an UAS. The user MAY decline to accept a partic¡ sec-mechanism *(COMMA sec-mechanism)
ular security mechanism, and abort further SIP communications with the security-server = "Security-Server" HCOLON
peer. sec-mechanism *(COMMA sec-mechanism)
security-verify = "Security-Verify" HCOLON
sec-mechanism *(COMMA sec-mechanism)
sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest-integrity" / "tls" / "ipsec-ike" /
"ipsec-man" / "smime" / token )
mech-parameters = ( preference / algorithm / extension )
preference = “q” EQUAL qvalue
qvalue = ( “0” [ “.” 0*3DIGIT ] )
/ ( “1” [ “.” 0*3(“0”) ] )
algorithm = "alg" EQUAL token
extension = generic-param
One SIP request MAY include several independent list. Only one list Note that qvalue is already defined in the SIP BNF [1]. We have
SHOULD be used between two SIP entities. This allows a negotiation of copied its definitions here for completeness.
the first-hop security mechanism while at the same time running e.g. a
REGISTER with Digest authentication to a server some hops away.
6.4. Header descriptions The parameters described by the BNF above have the following
semantics:
The Security-Mechanism header indicates who wants security towards Mechanism-name: It identifies the security mechanism supported by
whom, and what kind of security. The security features are repre¡ the client, when it appears in a security-client header fields, or
sented using the header syntax described below. by the server, when it appears in a security-server header field.
This specification defines six values:
The following ABNF describes the syntax of this header and extends - "tls" for TLS [3].
section 25.1 in [1]: - "digest-integrity" for HTTP Digest [4] using additional
integrity protection (i.e., the qop parameter) for 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].
"Security-Mechanism" HCOLON to-uri from-uri mechanism-list Preference: The "q" value indicates a relative preference for the
particular mechanism. The higher the value the more preferred the
mechanism is.
to-uri = "to" EQUAL sip-uri COMMA Algorithm: An optional algorithm field for those security
from-uri = "from" EQUAL sip-uri COMMA mechanisms which are not self-describing or which are vulnerable
mechanism-list = 1*(COMMA mechanism [SEMI preference] for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP
[SEMI algorithm] [SEMI params]) Digest, the same rules apply as defined in [4] for the "algorithm"
mechanism = "mech" EQUAL ( "digest" / "tls" / "ipsec-ike" / field in HTTP Digest.
"ipsec-man" / "smime" / token )
preference = "pref" EQUAL preference-value
algorithm = "alg" EQUAL algorithm-value
params = parameter *[SEMI parameter]
parameter = param-name EQUAL param-value
param-name = token
param-value = token / quoted-string
The meaning of these fields is as follows: 3.4. Protocol Operation
to-uri Indicates the desired receiver of the information. This section deals with the protocol details involved in the
The value of this field should be a SIP URI. When negotiation between a user agent client and its next-hop SIP entity.
sent by a client, the value would typically (but Throughout the text the next-hop SIP entity is referred to as the
not necessarily) contain just the host and port first-hop proxy or outbound proxy. However, the reader should bear in
number parts. mind that a user agent server can also be the next-hop for a user
agent client in the absence of proxies. Note as well that a proxy can
also have an outbound proxy.
from-uri Indicates the sender of the security agreement 3.4.1 Client Initiated
information. The value of this is also a SIP URI.
When sent by a client, the value would typically
(but not necessarily) include a username part.
mechanism The security mechanism supported by the SIP entity A client wishing to establish some type of security with its first-
identified in the from-uri. hop proxy SHOULD add a Security-Client header field to a request
addressed to this proxy (i.e., the destination of the request is the
first-hop proxy). This header field 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 also add a
Require header field with the value "sec-agree" to its request.
This specification defines six values: The Security-Client header field is used by the server to include any
necessary information in its response. For example, if digest-
integrity is the chosen mechanism, the server includes a WWW-
Authenticate header in the response. If S/MIME is chosen, the
appropriate certificate is included. If the security mechanisms
supported by the client do not need any further information to be
established (e.g., TLS) the client MAY choose not to include the
Security-Client header field in its request.
- "tls" for TLS [3], A server receiving a request that contains a Require header field
- "digest" for HTTP Digest [4], with the value "sec-agree" MUST challenge the client with a 494
- "ipsec-ike" for IPsec with IKE [2], (Security Agreement Required) response. The server MUST add a
- "ipsec-man" for manually keyed IPsec without IKE, Security-Server header field to this response listing the security
- "smime" for S/MIME [5], and mechanisms that the server supports. The server MUST add its list to
- token for extensions the response even if there are no common 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.
To use TLS, the client MUST contact the server side on The server MUST compare the list received in the Security-Client
port 5061. If this connection attempt fails, the header field with the list to be sent in the Security-Server header
security agreement procedure MUST be considered to have field. When the client receives this response, it will choose the
failed, and MUST be terminated. common security mechanism with the higher preference value.
Therefore, the server MUST add the necessary information so that the
client can initiate that mechanism (e.g., a WWW-Authenticate header
field for digest-integrity).
To use HTTP Digest, it alone does not fulfill the When the client receives a response with a Security-Server header
minimum security requirements of this specification. In field, it SHOULD choose the security mechanism in the server’s list
order to use HTTP Digest securely, some variant of MIME with the highest "q" value among all the mechanisms that are known to
tunneling SHOULD be used to force the Security-Mechanism the client. Then, it MUST initiate that particular security mechanism
header to be integrity protected in the MIME body. Also, as described in Section 3.5. This initiation may be carried out
if the server decides that the first matching mechanism without involving any SIP message exchange (e.g., establishing a TLS
is HTTP digest in Step 2 of Section 6.3, the server connection).
SHOULD include a HTTP authentication challenge in its
response. However, HTTP Digest need not to be negotiated
if some underlying security is used (e.g. TLS or
IPsec). The proxy/server can always challenge the client
after some security mechanism is already in place.
To use either "ipsec-ike" or "ipsec-man", the client and All the subsequent SIP requests sent by the client SHOULD make use of
the server MUST request their IPsec implementations to the security mechanism initiated in the previous step. These requests
protect all further communications between the same IP MUST contain a Security-Verify header field that mirrors the server’s
addresses and ports which where used in in the first list received previously in the Security-Server header field. This
request from the client and first response from the request MAY use SIP loose routing mechanism (i.e., Route header
server. If the IKE connection attempt fails, the fields) to traverse the proxy, but its final destination may be
agreement procedure MUST be considered to have failed, different than the proxy. In this case, the request SHOULD NOT
and MUST be terminated. Clients and servers SHOULD include a Require header field with the value "sec-agree".
terminate the IPsec protection when it is no longer
used.
Note also that "ipsec-man" will only work if the For example, the first request was an OPTIONS request directly
communicating SIP entities know which keys and other addressed to the proxy and the second request is an INVITE that
parameters to use. It is outside the scope of this will traverse the proxy but that is addressed to a real user (see
specification to describe how this information can be example in section 4.1).
made known to the peers.
To use S/MIME, the client MUST construct its request in The server MUST check that the security mechanisms listed in the
Step 4 (see 6.3) using S/MIME. If the server sees that Security-Verify header field of incoming requests correspond to its
S/MIME is the selected mechanism in Step 2, it MAY send static list of supported security mechanisms. The server can proceed
its own certificate within an S/MIME body in the processing a particular request if, and only if, the list was not
response of Step 2. modified. If modification of the list is detected, the server MUST
challenge the client with a 494 (Security Agreement Required). This
response MUST include a challenge with server's unmodified list of
supported security mechanisms.
preference A positive integer identifying the preferred order of Once the security has been negotiated between two SIP entities, the
the mechanisms. Servers MUST use preference numbers in same SIP entities MAY use the same security when communicating with
their lists to identify the preferred order of the each other in different SIP roles. For example, if a UAC and its
security mechanisms. Clients MUST NOT use preference outbound proxy negotiate some security, they may try to use the same
numbers in their lists. security for incoming requests (i.e., the UA will be acting as a
UAS).
algorithm An optional algorithm field for those security The user of a UA MAY be informed about the results of the security
mechanisms which are not self-describing or which are mechanism negotiation. The user MAY decline to accept a particular
vulnerable for bidding-down attacks (e.g. HTTP Digest). security mechanism, and abort further SIP communications with the
In the case of HTTP Digest, the same rules apply as peer.
defined in [4] for the "algorithm" field in HTTP
Digest.
params An optional field that allows future extensions. Any 3.4.2 Server Initiated
unrecognized directive MUST be ignored.
Multiple instances of the same header field can appear A server decides to use the security negotiation described in this
in SIP messages. Typically, the client inserts its own document based on local policy. A server that decides to use this
Security-Mechanism header when it sends a request, and negotiation MUST challenge requests regardless of the presence or the
the server/proxy adds its own to the response. The absence of any Require or Supported header fields in incoming
parameters are in all cases set in an appropriate manner requests.
to indicate in the "to-uri" paremeter the party who
inserted the header. Or rather -- since the client is
copying some of the server's responses -- whose security
capabilities the header applies to.
7. Summary of header usage A server that by policy requires the use of this specification and
receives a request that does not have the sec-agree option tag in a
Require or Supported header field MUST return a 421 (Extension
Required) response. If the request had the sec-agree option tag in a
Supported header field, it MUST return a 494 (Security Agreement
Required) response. In both situation the server MUST also include in
the response a Security-Server header field listing its capabilities
and a Require header field with an option-tag 'sec-agree' in it. All
the Via header field entries in the response except the topmost value
MUST be removed.
The Security-Mechanism header may be used to negotiate the security Clients that support the extension defined in this document MAY add a
mechanisms between various SIP entities including UAC, UAS, proxy, and Supported header field with a value of "sec-agree". In addition to
registrar. Information about the use of Security-Mechanism header in this, clients SHOULD add a Security-Client header field so that they
relation to SIP methods and proxy processing is summarized in Table 1. can save a round trip in case the server decides to challenge the
request.
Header field where proxy ACK BYE CAN INV OPT REG 3.5. Security mechanism initiation
_________________________________________________________________
Security-Mechanism R ar - - - c c c
Security-Mechanism 2xx a - - - c c c
Security-Mechanism 401,407,421,494 a - - - c c c
Table 1: Summary of header usage. Once the client chooses a security mechanism from the list received
in the Security-Server header field from the server, it initiates
that mechanism. Different mechanisms require different initiation
procedures.
The "where" column describes the request and response types in which If TLS is chosen, the client MUST contact the server using the host
the header field may be used. The header may not appear in other types part of the Request-URI in the first request to the server as the
of SIP messages. Values in the where column are: destination of the connection (note that this may involve using
standard SIP DNS procedures to locate a server). If this connection
attempt fails, the security agreement procedure MUST be considered to
have failed, and MUST be terminated.
- R: Header field may appear in requests. If digest-integrity is chosen, the 494 (Security Agreement Required)
response will contain an HTTP authentication challenge. The client
MUST use the qos parameter possibly together with some variant of
MIME tunneling so that the Security-Verify header field in the
request is integrity protected in the MIME body. Note that digest
alone would not fulfill the minimum security requirements of this
specification.
- 2xx, 401, etc.: A numerical value or range indicates response codes To use "ipsec-ike", the client attempts to establish an IKE
with which the header field can be used. connection to the host part of the Request-URI in the first request
to the server. If the IKE connection attempt fails, the agreement
procedure MUST be considered to have failed, and MUST be terminated.
The "proxy" column describes the operations a proxy may perform on a Note that "ipsec-man" will only work if the communicating SIP
header field: entities know which keys and other parameters to use. It is outside
the scope of this specification to describe how this information can
be made known to the peers.
- a: A proxy can add or concatenate the header field if not present. In both IPsec-based mechanisms, it is expected that appropriate
policy entries for protecting SIP have been configured or will be
created before attempting to use the security agreement procedure,
and that SIP communications use port numbers and addresses according
to these policy entries. It is outside the scope of this
specification to describe how this information can be made known to
the peers, but it could be typically configured at the same time as
the IKE credentials or manual SAs have been entered.
- r: A proxy must be able to read the header field, and thus this To use S/MIME, the client MUST construct its request using S/MIME.
header field cannot be encrypted. The client may have received the server’s certificate in an S/MIME
body in the 494 (Security Agreement Required) response.
The next six columns relate to the presence of a header field in a 3.6. Duration of Security Associations
method:
- c: Conditional; requirements on the header field depend on the con¡ Once a security mechanism has been negotiated, both the server and
text of the message. the client need to know until when it can be used. All the mechanisms
described in this document have a different way to signal the end of
a security association. When TLS is used, the termination of the
connection indicates that a new negotiation is needed. IKE negotiates
the duration of a security association. If the credentials provided
by a client using digest-integrity are not longer valid, the server
will re-challenge the client. It is assumed that when IPsec-man is
used, the same out-of-band mechanism used to distribute keys is used
to define the duration of the security association.
8. Backwards Compatibility 3.7. Summary of Header Field Use
SIP entities which support this specification but whose policy does The header fields defined in this document may be used to negotiate
not require its use, SHOULD only start using it if so required by the the security mechanisms between a UAC and other SIP entities
peer. Such SIP entities can thus communicate with other SIP entities including UAS, proxy, and registrar. Information about the use of
even if they do not support this specification. headers in relation to SIP methods and proxy processing is summarized
in Table 1.
SIP entities that support this specification and have a policy which Header field where proxy ACK BYE CAN INV OPT REG
requires its use MUST insert the Supported and Require headers as
described in this specification. This makes communications possible
only with nodes that support this specification. The OPTIONS method
can still be used with any node.
Note that the use of this specification together with the Proxy- _________________________________________________________________
Require header demands the support of this specification from all SIP Security-Client R ard - o - o o o
entities along the path. Security-Server 401,407,421,494 - o - o o o
Security-Verify R ard - o - o o o
9. Examples Header field where proxy SUB NOT PRK IFO UPD MSG
9.1. Selecting Between New and Old Mechanisms _________________________________________________________________
Security-Client R ard o o - o o o
Security-Server 401,407,421,494 o o - o o o
Security-Verify R ard o o - o o o
In this example we demonstrate the use of the framework for securing a Table 1: Summary of header usage.
hop using some security mechanism, without knowing beforehand which
methods the server supports. We assume that the client is not willing
to reveal any information on what it intends to do, so it uses OPTIONS
in the first message that is sent in the clear. The example starts by
a client sending a message to the server, indicating that it is of the
new variant that supports TLS in Step 1. In Step 2, the server
responds that with it own list of security mechanisms -- S/MIME or TLS
in this case -- and the peers start only common security service i.e.
TLS at Step 3. In Step 4, the client resends the server's Security-
Mechanism header, which the server verifies, and responds with 200 OK.
1. 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 - R: Header field may appear in requests.
Security-Mechanism: to=sip:server.example.com,
from=sip:client.example.com,
mech=tls
2. Server -> Client: - 401, 407 etc.: A numerical value or range indicates response codes
with which the header field can be used.
200 OK The "proxy" column describes the operations a proxy may perform on a
Security-Mechanism: to=sip:client.example.com, header field:
from=sip:server.example.com,
mech=smime;pref=1, mech=tls;pref=2
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 - d: A proxy can delete a header field value.
Security-Mechanism: to=sip:client.example.com,
from=sip:server.example.com,
mech=smime;pref=1, mech=tls;pref=2
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¡ 4. Backwards Compatibility
nism in replies for clarity. Typically in SIP the servers do not
remove header fields as they answer, they only add new headers.
If this example was run without Security-Mechanism in Step 2, the A server that, by local policy, decides to use the negotiation
client would not know what kind of security the other one supports, mechanism defined in this document, will not accept requests from
and would be forced to error-prone trials. 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 5. Examples
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.
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 5.1. Client Initiated
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.
In this example, the client sends a REGISTER request to its registrar. A UA negotiates the security mechanism to be used with its outbound
At the same time, the client negotiates the security with a different proxy without knowing beforehand which mechanisms the proxy supports.
first hop proxy. There are three alternative security solutions: a)
TLS, b) IPsec/IKE, and c) HTTP Digest.
The example starts by a client coming to a new network and learning UAC Proxy UAS
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.
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 |----(1) OPTIONS---->| |
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¡ |<-----(2) 494-------| |
tication challenge. Using the same response, the proxy adds an indica¡ | | |
tion that it supports TLS with HTTP Digest, IPsec/IKE, and plain HTTP |<=======TLS========>| |
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 |----(3) INVITE----->| |
client sends the next round of REGISTER messages to the registrar. | |----(4) INVITE--->|
This message includes the repetition of the original security capabil¡ | | |
ities of the proxy. The proxy verifies this list, and forwards the | |<---(5) 200 OK----|
request to the registrar. In Step 7, the registrar responds with a 200 |<---(6) 200 OK------| |
OK. | | |
|------(7) ACK------>| |
| |-----(8) ACK----->|
| | |
| | |
| | |
| | |
1. Client -> Proxy: Figure 2: Negotiation initiated by the client
REGISTER server SIP/2.0 The UAC sends an OPTIONS request to its outbound proxy, indicating
Security-Mechanism: to=sip:proxy.example.com, that it is able to negotiate security mechanisms and that it supports
from=sip:client.example.com, TLS and digest-integrity (Step 1 of figure 1). The outbound proxy
mech=ipsec-ike, mech=digest;alg=MD5 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 (1) OPTIONS proxy.example.com
(HTTP Digest challenge from the registrar to the client) Security-Client: tls;q=0.1
Security-Mechanism: to=sip:client.example.com, Security-Client: digest-integrity;q=0.2
from=sip:proxy.example.com, Require: sec-agree
mech=tls;pref=1, mech=ipsec-ike;pref=2,
mech=digest;pref=3;alg=MD5
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 The 200 OK response for the INVITE and the ACK are also sent over the
Security-Mechanism: to=sip:client.example.com, TLS connection. The ACK (7) will contain the same Security-Verify
from=sip:proxy.example.com, header field as the INVITE (3).
mech=tls;pref=1, mech=ipsec-ike;pref=2,
mech=digest;pref=3;alg=MD5
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---->| |
| | |
|<-----(2) 421-------| |
| | |
|------(3) ACK------>| |
| | |
|<=======IKE========>| |
| | |
|-----(4) INVITE---->| |
| |----(5) INVITE--->|
| | |
| |<---(7) 200 OK----|
|<----(6) 200 OK-----| |
| | |
|------(8) ACK------>| |
| |-----(9) ACK----->|
| | |
| | |
As in the previous example, if this was run without Security-Mechanism Figure 3: Server initiated security negotiation
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.
As in the previous example, removing the repetition of the Security- The proxy, following its local policy, challenges the INVITE. It
Mechanism header in Step 5 would open the system to MITM attacks. 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¡ This specification is about making it possible to select between
ous SIP security mechanisms in a secure manner. In particular, the various SIP security mechanisms in a secure manner. In particular,
method presented here allow current networks using e.g. Digest later the method presented here allow current networks using, for instance,
securely upgrade to e.g. S/MIME without requiring a simultaneous modi¡ Digest, to be securely upgraded to, for instance, IPsec without
fication in all equipment. The method presented in this specification requiring a simultaneous modification in all equipment. The method
is secure only if the weakest proposed mechanism offers at least presented in this specification is secure only if the weakest
integrity protection. proposed mechanism offers at least integrity protection.
Attackers could try to modify the server's list of security mechanisms Attackers could try to modify the server's list of security
in the first response. This would be revealed to the server when the mechanisms in the first response. This would be revealed to 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 Attackers could also try to modify the repeated list in the second
request from the client. However, if the selected security mechanism request from the client. However, if the selected security mechanism
uses encryption this may not be possible, and if it uses integrity uses encryption this may not be possible, and if it uses integrity
protection any modifications will be detected by the server. protection any modifications will be detected by the server.
Finally, attackers could try to modify the client's list of security Finally, attackers could try to modify the client's list of security
mechanisms in the first message. The client selects the security mech¡ mechanisms in the first message. The client selects the security
anism based on its own knowledge of its own capabilities and the 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 server's list, hence the client's choice would be unaffected by any
such modification. However, the server's choice could still be such modification. However, the server's choice could still be
affected as described below: 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 and
client would end up choosing different security mechanisms in Step 3 client would end up choosing different security mechanisms in Step 3
or 4.) Since they would be unable to communicate to each other, this or 4 of figure 1. Since they would be unable to communicate to each
would be detected as a potential attack. The client would either retry other, this would be detected as a potential attack. The client would
or give up in this situation. 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, there's no
effect. effect.
All clients that implement this specification MUST select HTTP Digest, All clients that implement this specification MUST select HTTP Digest
S/MIME, TLS, IPsec, or any stronger method for the protection of the with integrity, TLS, IPsec, or any stronger method for the protection
second request. If HTTP Digest is used alone, the security agreement of the second request. If HTTP Digest is used alone, the security
headers MUST be protected. This can be done with HTTP Digest if com¡ agreement headers MUST be protected. This can be done with HTTP
bined with MIME/SIP tunneling, for example. 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¡ This specification defines the 'sec-agree' SIP option tag which
istered in IANA. The option-tag 'sec-agree' can be used in header should be registered in IANA.
related to the SIP compatibility mechanisms for extensions (e.g.
Require and Supported).
This specification also defines a new error code, 494 (Security Agree¡ This specification also defines a new SIP status code, 494 (Security
ment Failed), which should be registered in IANA. Agreement Failed), which should be registered in IANA.
12. Modifications 8. Modifications
The draft-sip-sec-agree-00.txt version of this specification intro¡ The draft-sip-sec-agree-01.txt version of this specification
duced the following modifications: 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. - 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¡ - Clarified that the solution requires always some base level of
rity (i.e. integrity) in order to work. Even 'the weak security' must security (i.e. integrity) in order to work. Even 'the weak
not be broken. security' must not be broken.
- Text related to alternative solutions shortened and moved to a new - Text related to alternative solutions shortened and moved to a
place. new place.
- New rules for possible error and special cases has been added, e.g. - New rules for possible error and special cases has been added,
for the case in which an non-adjacent SIP entities try to negotiate (e.g., for the case in which an non-adjacent SIP entities try to
hop-by-hop security mechanisms. negotiate hop-by-hop security mechanisms).
- Syntax of the header redesigned. Wanted to get rid of the semantics - Syntax of the header redesigned. Wanted to get rid of the
related to the relative position of a header component in the header semantics related to the relative position of a header component in
(e.g. first parameters defines the 'from-uri', second the 'to-uri', the header e.g., first parameters defines the 'from-uri', second
and third the first supported security mechanism). The option tags are the 'to-uri', and third the first supported security mechanism).
now used to identify the Security Agreement extension, not the indi¡ The option tags are now used to identify the Security Agreement
vidual security mechanisms. extension, not the individual security mechanisms.
- The semantics of the header slightly changed: the AND operator - The semantics of the header slightly changed: the AND operator
between the indivicual mechanisms is removed because it is really need between the indivicual mechanisms is removed because it is really
with HTTP Digest only. And even in this case, the negotiation is not need with HTTP Digest only. And even in this case, the negotiation
needed beforehand if some underlying security is used. 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 - Explicit rules were added to all mechanisms on how they should be
used, such as TLS to be run on port 5061 etc. used, such as TLS to be run on port 5061 etc.
- References to Enhanced HTTP Digest removed. - References to Enhanced HTTP Digest removed.
- Example related to 3GPP generalized. - Example related to 3GPP generalized.
The draft-arkko-sip-sec-agree-01.txt version of this specification The draft-arkko-sip-sec-agree-01.txt version of this specification
introduced the following modifications: introduced the following modifications:
- Reversed approach to make servers stateless - Reversed approach to make servers stateless
- Removed discussion of the use of this for Digest algorithm selec¡ - Removed discussion of the use of this for Digest algorithm
tion, since Enhanced Digest already has bidding-down protection selection, since Enhanced Digest already has bidding-down
protection
- Renamed org.iana.sip.digest to org.iana.sip.edigest and removed the - Renamed org.iana.sip.digest to org.iana.sip.edigest and removed
parameters, as we can rely on Enhanced Digest to perform the algorithm the parameters, as we can rely on Enhanced Digest to perform the
selection. algorithm selection.
- Removed agreements for full paths. - Removed agreements for full paths.
- Simplified syntax - Simplified syntax
13. Acknowledgments 9. 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.
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¡ 10. Normative References
son, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Pro¡ [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
tocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation
Protocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF,
February 2002. February 2002.
[2] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro¡ [2] S. Kent, R. Atkinson, "Security Architecture for the Internet
tocol", RFC 2401, IETF, November 1998. Protocol", RFC 2401, IETF, November 1998.
[3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
IETF January 1999. IETF January 1999.
[4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, IETF, June 1999. Authentication", RFC 2617, IETF, June 1999.
[5] B. Ramsdell and Ed, "S/MIME version 3 message specification," RFC [5] B. Ramsdell and Ed, "S/MIME version 3 message specification," RFC
2633, IETF, June 1999. 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. [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", Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP",
draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, October draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF,
2001. October 2001.
16. Author's Address 12. Authors's Addresses
Jari Arkko, Vesa Torvinen Jari Arkko
Ericsson Ericsson
02420 Jorvas 02420 Jorvas
Finland 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 Tao Haukka
Nokia Nokia
Finland Finland
EMail: Tao.Haukka@nokia.com EMail: Tao.Haukka@nokia.com
Sanjoy Sen Sanjoy Sen
Nortel Networks Nortel Networks
2735-B Glenville Drive 2735-B Glenville Drive
Richardson, TX 75082, USA Richardson, TX 75082, USA
EMail: sanjoy@nortelnetworks.com EMail: sanjoy@nortelnetworks.com
Lee Valerius
Nortel Networks
2201 Lakeside Blvd
Richards, TX 75082, USA
EMail: valerius@nortelnetworks.com
 End of changes. 

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