draft-ietf-sip-sec-agree-01.txt   draft-ietf-sip-sec-agree-02.txt 
SIP Working Group Jari Arkko SIP Working Group Jari Arkko
INTERNET-DRAFT Vesa Torvinen INTERNET-DRAFT Vesa Torvinen
<draft-ietf-sip-sec-agree-01.txt> Gonzalo Camarillo <draft-ietf-sip-sec-agree-02.txt> Gonzalo Camarillo
May 2002 Ericsson May 2002 Ericsson
Expires: December 2002 Tao Haukka Expires: December 2002 Tao Haukka
Nokia Nokia
Sanjoy Sen Sanjoy Sen
Nortel Networks Nortel Networks
Security Mechanism Agreement for SIP Sessions Security Mechanism Agreement for SIP Sessions
Status of this memo Status of this memo
skipping to change at page 1, line 43 skipping to change at page 1, line 43
This document is an individual submission to the IETF. Comments This document is an individual submission to the IETF. Comments
should be directed to the authors. should be directed to the authors.
Abstract Abstract
SIP has a number of security mechanisms. Some of them have been built SIP has a number of security mechanisms. Some of them have been built
in to the SIP protocol, such as HTTP authentication or secure in to the SIP protocol, such as HTTP authentication or secure
attachments. These mechanisms have even alternative algorithms and attachments. These mechanisms have even alternative algorithms and
parameters. SIP does not currently provide any mechanism for parameters. SIP does not currently provide any mechanism for
selecting which security mechanisms to use over a connection. In selecting which security mechanisms to use between two entities. In
particular, even if some mechanisms such as OPTIONS were used to make particular, even if some mechanisms such as OPTIONS were used to make
this selection, the selection would be vulnerable against the this selection, the selection would be vulnerable against the
Bidding-Down attack. This document defines three header fields for Bidding-Down attack. This document defines three header fields for
negotiating the security mechanisms within SIP between a user agent negotiating the security mechanisms within SIP between a SIP entity
client and its next hop SIP entity. A SIP entity applying this and its next SIP hop. A SIP entity applying this mechanism must
mechanism must always require some minimum security (i.e. integrity always require some minimum security (i.e. integrity protection) from
protection) from all communicating parties in order to secure the all communicating parties in order to secure the negotiation, but the
negotiation, but the negotiation can agree on which specific minimum negotiation can agree on which specific minimum security is used.
security is used.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction....................................................2 1. Introduction....................................................2
2. The Problem.....................................................3 2. The Problem.....................................................3
3. Solution........................................................4 3. Solution........................................................4
3.1. Requirements...............................................4 3.1. Requirements...............................................4
3.2. Overview of Operations.....................................5 3.2. Overview of Operations.....................................5
3.3. Syntax.....................................................6 3.3. Syntax.....................................................6
3.4. Protocol Operation.........................................7 3.4. Protocol Operation.........................................7
3.4.1 Client Initiated........................................7 3.4.1 Client Initiated........................................7
3.4.2 Server Initiated........................................8 3.4.2 Server Initiated........................................8
3.5. Security Mechanism Initiation..............................9 3.5. Security Mechanism Initiation..............................9
3.6. Duration of the Security Association......................10 3.6. Duration of the Security Association......................10
3.7. Summary of Header Field Use...............................10 3.7. Summary of Header Field Use...............................10
4. Backwards Compatibility........................................11 4. Backwards Compatibility........................................11
5. Examples.......................................................11 5. Examples.......................................................11
5.1. Client Initiated..........................................10 5.1. Client Initiated..........................................10
5.2. Server Initiated..........................................12 5.2. Server Initiated..........................................12
5.3. Security Negotiation between Proxies......................13
6. Security Considerations........................................13 6. Security Considerations........................................13
7. IANA Considerations............................................14 7. IANA Considerations............................................15
8. Modifications..................................................14 8. Acknowledgments................................................15
9. Acknowledgments................................................15 9. Normative References...........................................15
10. Normative References...........................................15 10. Non-Normative References.......................................16
11. Non-Normative References.......................................15 11. AuthorsÆs Addresses............................................16
12. Authors’s Addresses............................................16
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 experience has shown that algorithm The reason for this is that experience has shown that algorithm
development uncovers problems in old algorithms and produces new development uncovers problems in old algorithms and produces new
ones. Furthermore, different mechanisms and algorithms are suitable ones. Furthermore, different mechanisms and algorithms are suitable
for different situations. Typically, protocols also select other for different situations. Typically, protocols also select other
parameters beyond algorithms at the same time. parameters beyond algorithms at the same time.
skipping to change at page 3, line 15 skipping to change at page 3, line 14
attacks. More seriously, it is hard or sometimes even impossible to attacks. More seriously, it is hard or sometimes even impossible to
know whether a SIP peer entity is truly unable to perform (e.g., 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 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 networks consisting of workstations and servers these issues are not
very relevant, as the administrators can deploy appropriate software very relevant, as the administrators can deploy appropriate software
versions and set up policies for using exactly the right type of versions and set up policies for using exactly the right type of
security. However, SIP will be deployed to hundreds of millions of security. However, SIP will be deployed to hundreds of millions of
small devices with little or no possibilities for coordinated small devices with little or no possibilities for coordinated
security policies, let alone software upgrades, and this makes these security policies, let alone software upgrades, and this makes these
issues much worse. This conclusion is also supported by the issues much worse. This conclusion is also supported by the
requirements from 3GPP [6]. requirements from 3GPP [7].
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.
2. Problem Description 2. Problem Description
SIP has alternative security mechanisms such as HTTP authentication SIP has alternative security mechanisms such as HTTP authentication
with integrity protection, lower layer security protocols, and with integrity protection, lower layer security protocols, and
S/MIME. It is likely that their use will continue in the future. SIP S/MIME. It is likely that their use will continue in the future. SIP
security is developing, and is likely to see also new solutions in security is developing, and is likely to see also new solutions in
skipping to change at page 4, line 40 skipping to change at page 4, line 39
3.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 HTTP digest. It also allows the selection layer security protocols or HTTP digest. It also allows the selection
of individual algorithms and parameters when the security functions of individual algorithms and parameters when the security functions
are integrated in SIP (such as in the case of HTTP authentication). are integrated in SIP (such as in the case of HTTP authentication).
(b) It allows first-hop security negotiation. (b) It allows next-hop security negotiation.
(c) It is secure (i.e., 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 (e) It does not introduce any additional state to servers and
proxies. 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 Require, Supported headers are capable of informing peers about
various capabilities including security mechanisms. However, the various capabilities including security mechanisms. However, the
straight forward use of these features can not guarantee a secured straight forward use of these features can not guarantee a secured
agreement. HTTP Digest algorithm lists [4] are not secure for picking agreement. HTTP Digest algorithm lists [4] are not secure for picking
among the digest integrity algorithms, as is described in the RFC among the digest integrity algorithms, as is described in the HTTP
itself. More seriously, they have no provisions for allowing authentication RFC [4] itself. More seriously, they have no
encryption to be negotiated. Hence, it would be hard to turn on provisions for allowing encryption to be negotiated. Hence, it would
possible future encryption schemes in a secure manner. be hard to turn on possible future encryption schemes in a secure
manner.
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 A non-self-describing security mechanism is a security mechanism
that, when used, requires that the use of the method or some of its that, when used, requires that the use of the method or some of its
parameters 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
skipping to change at page 6, line 47 skipping to change at page 6, line 47
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-integrity" / "tls" / "ipsec-ike" /
"ipsec-man" / "smime" / token ) "ipsec-man" / "smime" / token )
mech-parameters = ( preference / algorithm / extension ) mech-parameters = ( preference / algorithm / 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 algorithm = "alg" EQUAL token
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: It identifies the security mechanism supported by
the client, when it appears in a security-client header fields, or the client, when it appears in a Security-Client header fields, or
by the server, when it appears in a security-server header field. by the server, when it appears in a Security-Server or in a
This specification defines six values: Security-Verify header field. This specification defines six
values:
- "tls" for TLS [3]. - "tls" for TLS [3].
- "digest-integrity" for HTTP Digest [4] using additional - "digest-integrity" for HTTP Digest [4] using additional
integrity protection (i.e., the qop parameter) for the Security- integrity protection for the Security-Verify header field. The
Verify header field. additional integrity protection consists of using the qop
parameter to protect a sipfrag body part [6] that contains the
Security-Verify header field.
- "ipsec-ike" for IPsec with IKE [2]. - "ipsec-ike" for IPsec with IKE [2].
- "ipsec-man" for manually keyed IPsec without IKE. - "ipsec-man" for manually keyed IPsec without IKE.
- "smime" for S/MIME [5]. - "smime" for S/MIME [5].
Preference: The "q" value indicates a relative preference for the Preference: The "q" value indicates a relative preference for the
particular mechanism. The higher the value the more preferred the particular mechanism. The higher the value the more preferred the
mechanism is. mechanism is.
Algorithm: An optional algorithm field for those security Algorithm: An optional algorithm field for those security
mechanisms which are not self-describing or which are vulnerable mechanisms which are not self-describing or which are vulnerable
for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP
Digest, the same rules apply as defined in [4] for the "algorithm" Digest, the same rules apply as defined in RFC 2617 [4] for the
field in HTTP Digest. "algorithm" field in HTTP Digest.
3.4. Protocol Operation 3.4. 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 user agent client and its next-hop SIP entity. negotiation between a SIP entity and its next-hop SIP entity.
Throughout the text the next-hop SIP entity is referred to as the Throughout the text the next-hop SIP entity is referred to as the
first-hop proxy or outbound proxy. However, the reader should bear in first-hop proxy or outbound proxy. However, the reader should bear in
mind that a user agent server can also be the next-hop for a user mind that a user agent server can also be the next-hop for a proxy
agent client in the absence of proxies. Note as well that a proxy can or, in absence of proxies, for a user agent client. Note as well that
also have an outbound proxy. a proxy can also have an outbound proxy.
3.4.1 Client Initiated 3.4.1 Client Initiated
A client wishing to establish some type of security with its first- A client wishing to establish some type of security with its first-
hop proxy SHOULD add a Security-Client header field to a request 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 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 first-hop proxy). This header field contains a list of all the
security mechanisms that the client supports. The client SHOULD NOT security mechanisms that the client supports. The client SHOULD NOT
add preference parameters to this list. The client MUST also add a add preference parameters to this list. The client MUST also add a
Require header field with the value "sec-agree" to its request. Require header field with the value "sec-agree" to its request.
skipping to change at page 8, line 7 skipping to change at page 8, line 11
supported by the client do not need any further information to be supported by the client do not need any further information to be
established (e.g., TLS) the client MAY choose not to include the established (e.g., TLS) the client MAY choose not to include the
Security-Client header field in its request. Security-Client header field in its request.
A server receiving a request that contains a Require header field A server receiving a request that contains a Require header field
with the value "sec-agree" MUST challenge the client with a 494 with the value "sec-agree" MUST challenge the client with a 494
(Security Agreement Required) response. The server MUST add a (Security Agreement Required) response. The server MUST add a
Security-Server header field to this response listing the security Security-Server header field to this response listing the security
mechanisms that the server supports. The server MUST add its list to mechanisms that the server supports. The server MUST add its list to
the response even if there are no common security mechanisms in the the response even if there are no common security mechanisms in the
client's and server's lists. The servers list MUST NOT depend on the client's and server's lists. The serverÆs list MUST NOT depend on the
contents of the client's list. 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 higher preference value. common security mechanism with the higher preference value.
Therefore, the server MUST add the necessary information so that the Therefore, the server MUST add the necessary information so that the
client can initiate that mechanism (e.g., a WWW-Authenticate header client can initiate that mechanism (e.g., a WWW-Authenticate header
field for digest-integrity). field for digest-integrity).
When the client receives a response with a Security-Server header When the client receives a response with a Security-Server header
field, it SHOULD choose the security mechanism in the servers list field, it SHOULD 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 mechanism
as described in Section 3.5. This initiation may be carried out as described in Section 3.5. This initiation may be carried out
without involving any SIP message exchange (e.g., establishing a TLS without involving any SIP message exchange (e.g., establishing a TLS
connection). connection).
If an attacker modified the Security-Client header field in the
request, the server may not include in its response the information
needed to establish the common security mechanism with the highest
preference value (e.g., the WWW-authenticate header field is
missing). A client detecting such a lack of information in the
response MUST consider the current security negotiation process
aborted, and MAY try to start it again by sending a new request with
a Security-Client header field as described above.
All the subsequent SIP requests sent by the client SHOULD make use of All the subsequent SIP requests sent by the client SHOULD make use of
the security mechanism initiated in the previous step. These requests the security mechanism initiated in the previous step. These requests
MUST contain a Security-Verify header field that mirrors the servers MUST contain a Security-Verify header field that mirrors the serverÆs
list received previously in the Security-Server header field. This list received previously in the Security-Server header field. This
request MAY use SIP loose routing mechanism (i.e., Route header request MAY use SIP loose routing mechanism (i.e., Route header
fields) to traverse the proxy, but its final destination may be fields) to traverse the proxy, but its final destination may be
different than the proxy. In this case, the request SHOULD NOT different than the proxy. In this case, the request SHOULD NOT
include a Require header field with the value "sec-agree". include a Require header field with the value "sec-agree".
For example, the first request was an OPTIONS request directly For example, the first request was an OPTIONS request directly
addressed to the proxy and the second request is an INVITE that addressed to the proxy and the second request is an INVITE that
will traverse the proxy but that is addressed to a real user (see will traverse the proxy but that is addressed to a real user (see
example in section 4.1). example in section 4.1).
skipping to change at page 9, line 20 skipping to change at page 9, line 32
absence of any Require or Supported header fields in incoming absence of any Require or Supported header fields in incoming
requests. 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 or Supported header field MUST return a 421 (Extension Require or Supported header field MUST return a 421 (Extension
Required) response. If the request had the sec-agree option tag in a Required) response. If the request had the sec-agree option tag in a
Supported header field, it MUST return a 494 (Security Agreement Supported header field, it MUST return a 494 (Security Agreement
Required) response. In both situation the server MUST also include in Required) response. In both situation the server MUST also include in
the response a Security-Server header field listing its capabilities the response a Security-Server header field listing its capabilities
and a Require header field with an option-tag 'sec-agree' in it. All 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 the Via header field entries in the response except the topmost value
MUST be removed. MUST be removed. This ensures that the previous hop is the one
processing the response (see example in Section 5.3).
Clients that support the extension defined in this document MAY add a 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". In addition to
this, clients SHOULD add a Security-Client header field so that they 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 can save a round trip in case the server decides to challenge the
request. request.
3.5. Security mechanism initiation 3.5. 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 MUST contact the server using the host If TLS is chosen, the client MUST contact the server using the host
part of the Request-URI in the first request to the server as the part of the topmost Route entry in the first request to the server as
destination of the connection (note that this may involve using the destination of the connection (note that this may involve using
standard SIP DNS procedures to locate a server). If this connection standard SIP DNS procedures to locate a server). In the absence of a
attempt fails, the security agreement procedure MUST be considered to Route header field, the host part of the Request-URI is used as the
have failed, and MUST be terminated. destination of the connection instead. If this connection attempt
fails, the security agreement procedure MUST be considered to have
failed, and MUST be terminated.
If digest-integrity is chosen, the 494 (Security Agreement Required) If digest-integrity is chosen, the 494 (Security Agreement Required)
response will contain an HTTP authentication challenge. The client response will contain an HTTP authentication challenge. The client
MUST use the qos parameter possibly together with some variant of MUST use the qop parameter to protect a sipfrag body part [6] that
MIME tunneling so that the Security-Verify header field in the contains the Security-Verify header field in the request. Note that
request is integrity protected in the MIME body. Note that digest digest alone would not fulfill the minimum security requirements of
alone would not fulfill the minimum security requirements of this this specification.
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.
skipping to change at page 10, line 17 skipping to change at page 10, line 32
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 could be typically 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. To use S/MIME, the client MUST construct its request using S/MIME.
The client may have received the servers certificate in an S/MIME The client may have received the serverÆs certificate in an S/MIME
body in the 494 (Security Agreement Required) response. body in the 494 (Security Agreement Required) response.
3.6. Duration of Security Associations 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 mechanisms
described in this document have a different way to signal the end of described in this document have a different way to signal the end of
a security association. When TLS is used, the termination of the a security association. When TLS is used, the termination of the
connection indicates that a new negotiation is needed. IKE negotiates connection indicates that a new negotiation is needed. IKE negotiates
the duration of a security association. If the credentials provided the duration of a security association. If the credentials provided
skipping to change at page 12, line 19 skipping to change at page 12, line 32
| | | | | |
| | | | | |
| | | | | |
| | | | | |
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
that it is able to negotiate security mechanisms and that it supports that it is able to negotiate security mechanisms and that it supports
TLS and digest-integrity (Step 1 of figure 1). The outbound proxy TLS and digest-integrity (Step 1 of figure 1). The outbound proxy
challenges the UAC with its own list of security mechanisms IPsec challenges the UAC with its own list of security mechanisms û IPsec
and TLS (Step 2 of figure 1). The only common security mechanism is 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 TLS, so they establish a TLS connection between them (Step 3 of
figure 1). When the connection is successfully established, the UAC figure 1). When the connection is successfully established, the UAC
sends an INVITE over the TLS connection just established (Step 4 of sends an INVITE over the TLS connection just established (Step 4 of
figure 1). This INVITE contains the servers security list. The figure 1). This INVITE contains the serverÆs security list. The
server verifies it, and since it matches its static list, it server verifies it, and since it matches its static list, it
processes the INVITE and forwards it to the next hop. 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 4, 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 proxy.example.com (1) OPTIONS sip:proxy.example.com SIP/2.0
Security-Client: tls;q=0.1 Security-Client: tls;q=0.1
Security-Client: digest-integrity;q=0.2 Security-Client: digest-integrity;q=0.2
Require: sec-agree Require: sec-agree
(2) 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 proxy.example.com
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: callee@domain.com Route: sip:callee@domain.com
The 200 OK response for the INVITE and the ACK are also sent over the The 200 OK response for the INVITE and the ACK are also sent over the
TLS connection. The ACK (7) will contain the same Security-Verify TLS connection. The ACK (7) will contain the same Security-Verify
header field as the INVITE (3). header field as the INVITE (3).
5.2. Server Initiated 5.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-------| |
skipping to change at page 13, line 22 skipping to change at page 13, line 33
| | | | | |
|<-----(2) 421-------| | |<-----(2) 421-------| |
| | | | | |
|------(3) ACK------>| | |------(3) ACK------>| |
| | | | | |
|<=======IKE========>| | |<=======IKE========>| |
| | | | | |
|-----(4) INVITE---->| | |-----(4) INVITE---->| |
| |----(5) INVITE--->| | |----(5) INVITE--->|
| | | | | |
| |<---(7) 200 OK----| | |<---(6) 200 OK----|
|<----(6) 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 The proxy, following its local policy, challenges the INVITE. It
returns a 421 (Extension Required) with a Security-Server header 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. The second INVITE (4) and the ACK (8) contain a
Security-Verify header field that mirrors the Security-Server header 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 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 (8) are sent using the security association that has been
established. established.
5.3 Security Negotiation between Proxies
The example in Figure 4 shows a security negotiation between two
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
| | | |
|-(1) INVITE->| | |
| |-(2) INVITE->| |
| | | |
| |<--(3) 421---| |
| | | |
| |---(4) ACK-->| |
| | | |
| |<====TLS====>| |
| | | |
| |-(5) INVITE->| |
| | |-(6) INVITE->|
| | | |
| | |<-(7) 200 OK-|
| |<-(8) 200 OK-| |
|<-(9) 200 OK-| | |
| | | |
|--(10) ACK-->| | |
| |--(11) ACK-->| |
| | |--(12) ACK-->|
| | | |
Figure 4: Negotiation between two proxies
6. Security Considerations 6. 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 here allow current networks using, for instance,
Digest, to be securely upgraded to, for instance, IPsec without Digest, to be securely upgraded to, for instance, IPsec without
requiring a simultaneous modification in all equipment. The method requiring a simultaneous modification in all equipment. The method
presented in this specification is secure only if the weakest presented in this specification is secure only if the weakest
proposed mechanism offers at least integrity protection. proposed mechanism offers at least integrity protection.
skipping to change at page 14, line 31 skipping to change at page 15, line 34
effect. effect.
All clients that implement this specification MUST select HTTP Digest All clients that implement this specification MUST select HTTP Digest
with integrity, TLS, IPsec, or any stronger method for the protection with integrity, TLS, IPsec, or any stronger method for the protection
of the second request. If HTTP Digest is used alone, the security of the second request. If HTTP Digest is used alone, the security
agreement headers MUST be protected. This can be done with HTTP agreement headers MUST be protected. This can be done with HTTP
Digest if combined with MIME/SIP tunneling, for example. Digest if combined with MIME/SIP tunneling, for example.
7. IANA Considerations 7. IANA Considerations
This specification defines three new header fields, namely Security-
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 the 'sec-agree' SIP option tag which
should be registered in IANA. should be registered in IANA.
This specification also defines a new SIP status code, 494 (Security This specification also defines a new SIP status code, 494 (Security
Agreement Failed), which should be registered in IANA. Agreement Failed), which should be registered in IANA.
8. Modifications 8. Acknowledgments
The draft-sip-sec-agree-01.txt version of this specification
introduced the following modifications:
- Scope narrowed down to first-hop negotiation.
- Fixed syntax of header fields.
The draft-sip-sec-agree-00.txt version of this specification
introduced the following modifications:
- Many editorial changes, restructuring and clarifications.
- Motivation section has been shortened since this is now a WG
item.
- Clarified that the solution requires always some base level of
security (i.e. integrity) in order to work. Even 'the weak
security' must not be broken.
- Text related to alternative solutions shortened and moved to a
new place.
- New rules for possible error and special cases has been added,
(e.g., for the case in which an non-adjacent SIP entities try to
negotiate hop-by-hop security mechanisms).
- Syntax of the header redesigned. Wanted to get rid of the
semantics related to the relative position of a header component in
the header e.g., first parameters defines the 'from-uri', second
the 'to-uri', and third the first supported security mechanism).
The option tags are now used to identify the Security Agreement
extension, not the individual security mechanisms.
- The semantics of the header slightly changed: the AND operator
between the indivicual mechanisms is removed because it is really
need with HTTP Digest only. And even in this case, the negotiation
is not needed beforehand if some underlying security is used.
- Options for HTTP Digest algorithms and manually keyed IPsec
added.
- Explicit rules were added to all mechanisms on how they should be
used, such as TLS to be run on port 5061 etc.
- References to Enhanced HTTP Digest removed.
- Example related to 3GPP generalized.
The draft-arkko-sip-sec-agree-01.txt version of this specification
introduced the following modifications:
- Reversed approach to make servers stateless
- Removed discussion of the use of this for Digest algorithm
selection, since Enhanced Digest already has bidding-down
protection
- Renamed org.iana.sip.digest to org.iana.sip.edigest and removed
the parameters, as we can rely on Enhanced Digest to perform the
algorithm selection.
- Removed agreements for full paths.
- Simplified syntax
9. Acknowledgments
The authors wish to thank Lee Valerius, Rolf Blom, James Undery, The authors wish to thank Lee Valerius, Rolf Blom, James Undery,
Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David
Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin
Euchner, Eric Rescorla and members of the 3GPP SA3 group for Euchner, Eric Rescorla and members of the 3GPP SA3 group for
interesting discussions in this problem space. interesting discussions in this problem space.
10. Normative References 9. Normative References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation
Protocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, 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 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", 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.
11. Non-Normative References [6] R. Sparks, "Internet Media Type message/sipfrag", Work in
Progress, draft-sparks-sip-mimetypes-03.txt, IETF, April 2002.
[6] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. 10. Non-Normative References
[7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A.
Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP",
draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF,
October 2001. October 2001.
12. Authors's Addresses 11. Authors's Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
02420 Jorvas 02420 Jorvas
Finland Finland
EMail: Jari.Arkko@ericsson.com EMail: Jari.Arkko@ericsson.com
Vesa Torvinen Vesa Torvinen
Ericsson Ericsson
02420 Jorvas 02420 Jorvas
 End of changes. 

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