draft-ietf-sip-sec-agree-05.txt   rfc3329.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft V. Torvinen Request for Comments: 3329 V. Torvinen
Expires: April 28, 2003 G. Camarillo Category: Standards Track G. Camarillo
Ericsson Ericsson
A. Niemi A. Niemi
T. Haukka T. Haukka
Nokia Nokia
October 28, 2002 January 2003
Security Mechanism Agreement for the Session Initiation Protocol Security Mechanism Agreement for the
(SIP) Session Initiation Protocol (SIP)
draft-ietf-sip-sec-agree-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines new functionality for negotiating the security This document defines new functionality for negotiating the security
mechanisms used between a Session Initiation Protocol (SIP) user mechanisms used between a Session Initiation Protocol (SIP) user
agent and its next-hop SIP entity. This new functionality agent and its next-hop SIP entity. This new functionality
supplements the existing methods of choosing security mechanisms supplements the existing methods of choosing security mechanisms
between SIP entities. between SIP entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Overview of Operation . . . . . . . . . . . . . . . . . . . 4 2.1 Overview of Operation . . . . . . . . . . . . . . . . . 3
2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 2.3 Protocol Operation . . . . . . . . . . . . . . . . . . . 6
2.3.1 Client Initiated . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Client Initiated . . . . . . . . . . . . . . . . . . 6
2.3.2 Server Initiated . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 Server Initiated . . . . . . . . . . . . . . . . . . 8
2.4 Security Mechanism Initiation . . . . . . . . . . . . . . . 10 2.4 Security Mechanism Initiation. . . . . . . . . . . . . . 9
2.5 Duration of Security Associations . . . . . . . . . . . . . 10 2.5 Duration of Security Associations. . . . . . . . . . . .10
2.6 Summary of Header Field Use . . . . . . . . . . . . . . . . 11 2.6 Summary of Header Field Use. . . . . . . . . . . . . . .10
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 12 3. Backwards Compatibility . . . . . . . . . . . . . . . . . .11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Client Initiated . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Client Initiated . . . . . . . . . . . . . . . . . . . .12
4.2 Server Initiated . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Server Initiated . . . . . . . . . . . . . . . . . . . .14
5. Security Considerations . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . .15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .17
6.1 Registration Information . . . . . . . . . . . . . . . . . . 18 6.1 Registration Information . . . . . . . . . . . . . . . .17
6.2 Registration Template . . . . . . . . . . . . . . . . . . . 19 6.2 Registration Template. . . . . . . . . . . . . . . . . .18
6.3 Header Field Names . . . . . . . . . . . . . . . . . . . . . 19 6.3 Header Field Names . . . . . . . . . . . . . . . . . . .18
6.4 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 19 6.4 Response Codes . . . . . . . . . . . . . . . . . . . . .18
6.5 Option Tags . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5 Option Tags. . . . . . . . . . . . . . . . . . . . . . .19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . .19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .19
Normative References . . . . . . . . . . . . . . . . . . . . 20 9. Normative References . . . . . . . . . . . . . . . . . . . .19
Informative References . . . . . . . . . . . . . . . . . . . 21 10. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . .21
A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .23
Full Copyright Statement . . . . . . . . . . . . . . . . . . 25 Full Copyright Statement . . . . . . . . . . . . . . . . . . . .24
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.
This is to add flexibility, since different mechanisms are usually This is to add flexibility, since different mechanisms are usually
suitable to different scenarios. Also, the evolution of security suitable to different scenarios. Also, the evolution of security
mechanisms often introduces new algorithms, or uncovers problems in mechanisms often introduces new algorithms, or uncovers problems in
existing ones, making negotiation of mechanisms a necessity. existing ones, making negotiation of mechanisms a necessity.
skipping to change at page 3, line 48 skipping to change at page 3, line 18
available from the very beginning of deployment (e.g., see [11]). available from the very beginning of deployment (e.g., see [11]).
1.2 Design Goals 1.2 Design Goals
1. The entities involved in the security agreement process need to 1. The entities involved in the security agreement process need to
find out exactly which security mechanisms to apply, preferably find out exactly which security mechanisms to apply, preferably
without excessive additional roundtrips. without excessive additional roundtrips.
2. The selection of security mechanisms itself needs to be secure. 2. The selection of security mechanisms itself needs to be secure.
Traditionally, all security protocols use a secure form of Traditionally, all security protocols use a secure form of
negotiation. For instance, after establishing mutual keys negotiation. For instance, after establishing mutual keys through
through Diffie-Hellman, IKE sends hashes of the previously sent Diffie-Hellman, IKE sends hashes of the previously sent data
data including the offered crypto mechanisms [8]. This allows including the offered crypto mechanisms [8]. This allows the
the peers to detect if the initial, unprotected offers were peers to detect if the initial, unprotected offers were tampered
tampered with. with.
3. The entities involved in the security agreement process need to 3. The entities involved in the security agreement process need to be
be able to indicate success or failure of the security agreement able to indicate success or failure of the security agreement
process. process.
4. The security agreement process should not introduce any 4. The security agreement process should not introduce any additional
additional state to be maintained by the involved entities. state to be maintained by the involved entities.
1.3 Conventions 1.3 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [9]. document are to be interpreted as described in BCP 14, RFC 2119 [9].
2. Solution 2. Solution
2.1 Overview of Operation 2.1 Overview of Operation
skipping to change at page 5, line 46 skipping to change at page 5, line 14
sec-mechanism = mechanism-name *(SEMI mech-parameters) sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest" / "tls" / "ipsec-ike" / mechanism-name = ( "digest" / "tls" / "ipsec-ike" /
"ipsec-man" / token ) "ipsec-man" / token )
mech-parameters = ( preference / digest-algorithm / mech-parameters = ( preference / digest-algorithm /
digest-qop / digest-verify / extension ) digest-qop / digest-verify / extension )
preference = "q" EQUAL qvalue preference = "q" EQUAL qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
digest-algorithm = "d-alg" EQUAL token digest-algorithm = "d-alg" EQUAL token
digest-qop = "d-qop" EQUAL token digest-qop = "d-qop" EQUAL token
digest-verify = LDQUOT 32LHEX RDQUOT digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT
extension = generic-param extension = generic-param
Note that qvalue is already defined in the SIP BNF [1]. We have Note that qvalue is already defined in the SIP BNF [1]. We have
copied its definitions here for completeness. copied its definitions here for completeness.
The parameters described by the BNF above have the following The parameters described by the BNF above have the following
semantics: semantics:
Mechanism-name Mechanism-name
This token identifies the security mechanism supported by the This token identifies the security mechanism supported by the
client, when it appears in a Security-Client header field; or by client, when it appears in a Security-Client header field; or
the server, when it appears in a Security-Server or in a Security- by the server, when it appears in a Security-Server or in a
Verify header field. The mechanism-name tokens are registered Security-Verify header field. The mechanism-name tokens are
with the IANA. This specification defines four values: registered with the IANA. This specification defines four
values:
* "tls" for TLS [3]. * "tls" for TLS [3].
* "digest" for HTTP Digest [4]. * "digest" for HTTP Digest [4].
* "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.
Preference Preference
The "q" value indicates a relative preference for the particular The "q" value indicates a relative preference for the
mechanism. The higher the value the more preferred the mechanism particular mechanism. The higher the value the more preferred
is. All the security mechanisms MUST have different "q" values. the mechanism is. All the security mechanisms MUST have
It is an error to provide two mechanisms with the same "q" value. different "q" values. It is an error to provide two mechanisms
with the same "q" value.
Digest-algorithm Digest-algorithm
This optional parameter is defined here only for HTTP Digest [4] This optional parameter is defined here only for HTTP Digest
in order to prevent the bidding-down attack for the HTTP Digest [4] in order to prevent the bidding-down attack for the HTTP
algorithm parameter. The content of the field may have same Digest algorithm parameter. The content of the field may have
values as defined in [4] for the "algorithm" field. same values as defined in [4] for the "algorithm" field.
Digest-qop Digest-qop
This optional parameter is defined here only for HTTP Digest [4] This optional parameter is defined here only for HTTP Digest
in order to prevent the bidding-down attack for the HTTP Digest [4] in order to prevent the bidding-down attack for the HTTP
qop parameter. The content of the field may have same values as Digest qop parameter. The content of the field may have same
defined in [4] for the "qop" field. values as defined in [4] for the "qop" field.
Digest-verify Digest-verify
This optional parameter is defined here only for HTTP Digest [4] This optional parameter is defined here only for HTTP Digest
in order to prevent the bidding-down attack for the SIP security [4] in order to prevent the bidding-down attack for the SIP
mechanism agreement (this document). The content of the field is security mechanism agreement (this document). The content of
counted exactly the same way as "request-digest" in [4] except the field is counted exactly the same way as "request-digest"
that the Security-Server header field is included in the A2 in [4] except that the Security-Server header field is included
parameter. If the "qop" directive's value is "auth" or is in the A2 parameter. If the "qop" directive's value is "auth"
unspecified, then A2 is: or is unspecified, then A2 is:
A2 = Method ":" digest-uri-value ":" security-server A2 = Method ":" digest-uri-value ":" security-server
If the "qop" value is "auth-int", then A2 is: If the "qop" value is "auth-int", then A2 is:
A2 = Method ":" digest-uri-value ":" H(entity-body) ":" A2 = Method ":" digest-uri-value ":" H(entity-body) ":"
security-server security-server
All linear white spaces in the Security-Server header field MUST All linear white spaces in the Security-Server header field
be replaced by a single SP before calculating or interpreting the MUST be replaced by a single SP before calculating or
digest-verify parameter. Method, digest-uri-value, entity-body, interpreting the digest-verify parameter. Method, digest-uri-
and any other HTTP Digest parameter are as specified in [4]. value, entity-body, and any other HTTP Digest parameter are as
specified in [4].
Note that this specification does not introduce any extension or Note that this specification does not introduce any extension or
change to HTTP Digest [4]. This specification only re-uses the change to HTTP Digest [4]. This specification only re-uses the
existing HTTP Digest mechanisms to protect the negotiation of existing HTTP Digest mechanisms to protect the negotiation of
security mechanisms between SIP entities. security mechanisms between SIP entities.
2.3 Protocol Operation 2.3 Protocol Operation
This section deals with the protocol details involved in the This section deals with the protocol details involved in the
negotiation between a SIP UA and its next-hop SIP entity. Throughout negotiation between a SIP UA and its next-hop SIP entity. Throughout
skipping to change at page 9, line 28 skipping to change at page 8, line 51
The user of a UA SHOULD be informed about the results of the security The user of a UA SHOULD be informed about the results of the security
mechanism agreement. The user MAY decline to accept a particular mechanism agreement. The user MAY decline to accept a particular
security mechanism, and abort further SIP communications with the security mechanism, and abort further SIP communications with the
peer. peer.
2.3.2 Server Initiated 2.3.2 Server Initiated
A server decides to use the security agreement described in this A server decides to use the security agreement described in this
document based on local policy. If a server receives a request from document based on local policy. If a server receives a request from
the network interface that is configured to use this mechanism, it the network interface that is configured to use this mechanism, it
must check that the request has only one Via header field. If there must check that the request has only one Via entry. If there are
are several Via header fields, the server is not the first-hop SIP several Via entries, the server is not the first-hop SIP entity, and
entity, and it MUST NOT use this mechanism. For such a request, the it MUST NOT use this mechanism. For such a request, the server must
server must return a 502 (Bad Gateway) response. return a 502 (Bad Gateway) response.
A server that decides to use this agreement mechanism MUST challenge A server that decides to use this agreement mechanism MUST challenge
unprotected requests with one Via header field regardless of the unprotected requests with one Via entry regardless of the presence or
presence or the absence of any Require, Proxy-Require or Supported the absence of any Require, Proxy-Require or Supported header fields
header fields in incoming requests. in incoming requests.
A server that by policy requires the use of this specification and A server that by policy requires the use of this specification and
receives a request that does not have the sec-agree option tag in a receives a request that does not have the sec-agree option tag in a
Require, Proxy-Require or Supported header field MUST return a 421 Require, Proxy-Require or Supported header field MUST return a 421
(Extension Required) response. If the request had the sec-agree (Extension Required) response. If the request had the sec-agree
option tag in a Supported header field, it MUST return a 494 option tag in a Supported header field, it MUST return a 494
(Security Agreement Required) response. In both situation the server (Security Agreement Required) response. In both situation the server
MUST also include in the response a Security-Server header field MUST also include in the response a Security-Server header field
listing its capabilities and a Require header field with an option- listing its capabilities and a Require header field with an option-
tag "sec-agree" in it. The server MUST also add necessary tag "sec-agree" in it. The server MUST also add necessary
information so that the client can initiate the preferred security information so that the client can initiate the preferred security
mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest). mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest).
Clients that support the extension defined in this document MAY add a Clients that support the extension defined in this document SHOULD
Supported header field with a value of "sec-agree". add a Supported header field with a value of "sec-agree".
2.4 Security Mechanism Initiation 2.4 Security Mechanism Initiation
Once the client chooses a security mechanism from the list received Once the client chooses a security mechanism from the list received
in the Security-Server header field from the server, it initiates in the Security-Server header field from the server, it initiates
that mechanism. Different mechanisms require different initiation that mechanism. Different mechanisms require different initiation
procedures. procedures.
If "tls" is chosen, the client uses the procedures of Section 8.1.2 If "tls" is chosen, the client uses the procedures of Section 8.1.2
of [1]to determine the URI to be used as an input to the DNS of [1]to determine the URI to be used as an input to the DNS
procedures of [5]. However, if the URI is a SIP URI, it MUST treat procedures of [5]. However, if the URI is a SIP URI, it MUST treat
the scheme as if it were sips, not sip. If the URI scheme is not the scheme as if it were sips, not sip. If the URI scheme is not
sip, the request MUST be sent using TLS. sip, the request MUST be sent using TLS.
If "digest" is chosen, the 494 (Security Agreement Required) response If "digest" is chosen, the 494 (Security Agreement Required) response
will contain an HTTP Digest authentication challenge. The client will contain an HTTP Digest authentication challenge. The client
MUST use the algorithm and qop parameters in the Security-Server MUST use the algorithm and qop parameters in the Security-Server
header field to replace the same parameters in the HTTP Digest header field to replace the same parameters in the HTTP Digest
challenge. The client MUST also use the digest-verify parameter to challenge. The client MUST also use the digest-verify parameter in
protect the Security-Server header field as specified in 2.2. the Security-Verify header field to protect the Security-Server
header field as specified in 2.2.
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. All rules for minimum implementations, be made known to the peers. All rules for minimum implementations,
skipping to change at page 11, line 37 skipping to change at page 11, line 23
Security-Client R ard o o - o o o Security-Client R ard o o - o o o
Security-Server 421,494 o o - o o o Security-Server 421,494 o o - o o o
Security-Verify R ard o o - o o o Security-Verify R ard o o - o o o
Table 1: Summary of Header Usage. Table 1: Summary of Header Usage.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field may be used. The header may not appear in other the header field may be used. The header may not appear in other
types of SIP messages. Values in the where column are: types of SIP messages. Values in the where column are:
o R: Header field may appear in requests. * R: Header field may appear in requests.
o 421, 494: A numerical value indicates response codes with which * 421, 494: A numerical value indicates response codes with which
the header field can be used. the header field can be used.
The "proxy" column describes the operations a proxy may perform on a The "proxy" column describes the operations a proxy may perform on a
header field: header field:
o a: A proxy can add or concatenate the header field if not present. * a: A proxy can add or concatenate the header field if not present.
o r: A proxy must be able to read the header field, and thus this * r: A proxy must be able to read the header field, and thus this
header field cannot be encrypted. header field cannot be encrypted.
o d: A proxy can delete a header field value. * d: A proxy can delete a header field value.
The next six columns relate to the presence of a header field in a The next six columns relate to the presence of a header field in a
method: method:
o o: The header field is optional. * o: The header field is optional.
3. Backwards Compatibility 3. Backwards Compatibility
The use of this extension in a network interface is a matter of local The use of this extension in a network interface is a matter of local
policy. Different network interfaces may follow different policies, policy. Different network interfaces may follow different policies,
and consequently the use of this extension may be situational by and consequently the use of this extension may be situational by
nature. UA and server implementations MUST be configurable to nature. UA and server implementations MUST be configurable to
operate with or without this extension. operate with or without this extension.
A server that is configured to use this mechanism, may also accept A server that is configured to use this mechanism, may also accept
skipping to change at page 14, line 28 skipping to change at page 14, line 7
Route: sip:callee@domain.com Route: sip:callee@domain.com
Require: sec-agree Require: sec-agree
Proxy-Require: sec-agree Proxy-Require: sec-agree
The 200 OK response (6) for the INVITE and the ACK (7) are also sent The 200 OK response (6) for the INVITE and the ACK (7) are also sent
over the TLS connection. The ACK will contain the same Security- over the TLS connection. The ACK will contain the same Security-
Verify header field as the INVITE (3). Verify header field as the INVITE (3).
4.2 Server Initiated 4.2 Server Initiated
In this example of figure 3 the client sends an INVITE towards the In this example of Figure 3 the client sends an INVITE towards the
callee using an outbound proxy. This INVITE does not contain any callee using an outbound proxy. This INVITE does not contain any
Require header field. Require header field.
UAC Proxy UAS UAC Proxy UAS
| | | | | |
|-----(1) INVITE---->| | |-----(1) INVITE---->| |
| | | | | |
|<-----(2) 421-------| | |<-----(2) 421-------| |
| | | | | |
|------(3) ACK------>| | |------(3) ACK------>| |
skipping to change at page 16, line 37 skipping to change at page 15, line 40
force the two peers to use weak security between them. But if the force the two peers to use weak security between them. But if the
offers are protected in some way -- such as by hashing, or repeating offers are protected in some way -- such as by hashing, or repeating
them later when the selected security is really on -- the situation them later when the selected security is really on -- the situation
is different. It would not be sufficient for the attacker to modify is different. It would not be sufficient for the attacker to modify
a single message. Instead, the attacker would have to modify both a single message. Instead, the attacker would have to modify both
the offer message, as well as the message that contains the hash/ the offer message, as well as the message that contains the hash/
repetition. More importantly, the attacker would have to forge the repetition. More importantly, the attacker would have to forge the
weak security that is present in the second message, and would have weak security that is present in the second message, and would have
to do so in real time between the sent offers and the later messages. to do so in real time between the sent offers and the later messages.
Otherwise, the peers would notice that the hash is incorrect. If the Otherwise, the peers would notice that the hash is incorrect. If the
attacker is able to break the weak security, the security method and/ attacker is able to break the weak security, the security method
or the algorithm should not be used. and/or the algorithm should not be used.
In conclusion, the security difference is making a trivial attack In conclusion, the security difference is making a trivial attack
possible versus demanding the attacker to break algorithms. An possible versus demanding the attacker to break algorithms. An
example of where this has a serious consequence is when a network is example of where this has a serious consequence is when a network is
first deployed with integrity protection (such as HTTP Digest [4]), first deployed with integrity protection (such as HTTP Digest [4]),
and then later new devices are added that support also encryption and then later new devices are added that support also encryption
(such as TLS [3]). In this situation, an insecure negotiation (such as TLS [3]). In this situation, an insecure negotiation
procedure allows attackers to trivially force even new devices to use procedure allows attackers to trivially force even new devices to use
only integrity protection. only integrity protection.
Possible attacks against the security agreement include: Possible attacks against the security agreement include:
1. Attackers could try to modify the server's list of security 1. Attackers could try to modify the server's list of security
mechanisms in the first response. This would be revealed to the mechanisms in the first response. This would be revealed to the
server when the client returns the received list using the server when the client returns the received list using the
security. security.
2. Attackers could also try to modify the repeated list in the 2. Attackers could also try to modify the repeated list in the second
second request from the client. However, if the selected request from the client. However, if the selected security
security mechanism uses encryption this may not be possible, and mechanism uses encryption this may not be possible, and if it uses
if it uses integrity protection any modifications will be integrity protection any modifications will be detected by the
detected by the server. server.
3. Attackers could try to modify the client's list of security 3. Attackers could try to modify the client's list of security
mechanisms in the first message. The client selects the security mechanisms in the first message. The client selects the security
mechanism based on its own knowledge of its own capabilities and mechanism based on its own knowledge of its own capabilities and
the server's list, hence the client's choice would be unaffected the server's list, hence the client's choice would be unaffected
by any such modification. However, the server's choice could by any such modification. However, the server's choice could
still be affected as described below: still be affected as described below:
* If the modification affected the server's choice, the server * If the modification affected the server's choice, the server
and client would end up choosing different security mechanisms and client would end up choosing different security mechanisms
in Step 3 or 4 of figure 1. Since they would be unable to in Step 3 or 4 of Figure 1. Since they would be unable to
communicate to each other, this would be detected as a communicate to each other, this would be detected as a
potential attack. The client would either retry or give up in potential attack. The client would either retry or give up in
this situation. this situation.
* If the modification did not affect the server's choice, * If the modification did not affect the server's choice, there's
there's no effect. no effect.
4. Finally, attackers may also try to reply old security agreement 4. Finally, attackers may also try to reply old security agreement
messages. Each security mechanism must provide replay messages. Each security mechanism must provide replay protection.
protection. In particular, HTTP Digest implementations should In particular, HTTP Digest implementations should carefully
carefully utilize existing reply protection options such as utilize existing reply protection options such as including a
including a time-stamp to the nonce parameter, and using nonce time-stamp to the nonce parameter, and using nonce counters [4].
counters [4].
All clients that implement this specification MUST select HTTP All clients that implement this specification MUST select HTTP
Digest, TLS, IPsec, or any stronger method for the protection of the Digest, TLS, IPsec, or any stronger method for the protection of the
second request. second request.
6. IANA Considerations 6. IANA Considerations
This specification defines a new mechanism-name namespace in Section This specification defines a new mechanism-name namespace in Section
2.2 which requires a central coordinating body. The body responsible 2.2 which requires a central coordinating body. The body responsible
for this coordination is the Internet Assigned Numbers Authority for this coordination is the Internet Assigned Numbers Authority
(IANA). (IANA).
This document defines four mechanism-names to be initially This document defines four mechanism-names to be initially
registered, namely "digest", "tls", "ipsec-ike", and "ipsec-man". In registered, namely "digest", "tls", "ipsec-ike", and "ipsec-man". In
addition to these mechanism-names, "ipsec-3gpp" mechanism-name is addition to these mechanism-names, "ipsec-3gpp" mechanism-name is
also registered (see Appendix A). Following the policies outlined in also registered (see Appendix A). Following the policies outlined in
[10], further mechanism-names are allocated based on IETF Consensus. [10], further mechanism-names are allocated based on IETF Consensus.
Registrations with the IANA MUST include the mechanism-name token Registrations with the IANA MUST include the mechanism-name token
being registered, and a pointer to a published RFC describing the being registered, and a pointer to a published RFC describing the
details of the corresponding security mechanism. Further, the details of the corresponding security mechanism.
registration MUST include contact information for the party
responsible for the registration.
6.1 Registration Information 6.1 Registration Information
As this document specifies five mechanism-names, the initial IANA IANA registers new mechanism-names at
registration for mechanism-names will contain the information shown http://www.iana.org/assignments/sip-parameters under "Security
in Table 2. It also demonstrates the type of information maintained Mechanism Names". As this document specifies five mechanism-names,
by the IANA. the initial IANA registration for mechanism-names will contain the
information shown in Table 2. It also demonstrates the type of
Mechanism Name Contact Reference information maintained by the IANA.
-------------- ------- ---------
digest [1] [RFCNNNN]
tls [1] [RFCNNNN]
ipsec-ike [1] [RFCNNNN]
ipsec-man [1] [RFCNNNN]
ipsec-3gpp [1] [RFCNNNN]
People
------
[1] Jari Arkko <Jari.Arkko@ericsson.com>
Vesa Torvinen <Vesa.Torvinen@ericsson.fi>
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Aki Niemi <Aki.Niemi@nokia.com>
Tao Haukka <Tao.Haukka@nokia.com>
References Mechanism Name Reference
---------- -------------- ---------
[RFCNNNN] Arkko, et. al., "Security Mechanism Agreement for the digest [RFC3329]
Session Initiation Protocol", RFC NNNN, October 2002. tls [RFC3329]
ipsec-ike [RFC3329]
ipsec-man [RFC3329]
ipsec-3gpp [RFC3329]
Table2: Initial IANA registration. Table2: Initial IANA registration.
(Note to RFC Editor: Replace NNNN with the RFC number of this
document when published.)
6.2 Registration Template 6.2 Registration Template
To: ietf-sip-sec-agree-mechanism-name@iana.org To: ietf-sip-sec-agree-mechanism-name@iana.org
Subject: Registration of a new SIP Security Agreement mechanism Subject: Registration of a new SIP Security Agreement mechanism
Mechanism Name: Mechanism Name:
(Token value conforming to the syntax described in (Token value conforming to the syntax described in
Section 2.2.) Section 2.2.)
Published Specification(s): Published Specification(s):
(Descriptions of new SIP Security Agreement mechanisms (Descriptions of new SIP Security Agreement mechanisms
require a published RFC.) require a published RFC.)
Person & email address to contact for further information:
(Must contain contact information for the person(s)
responsible for the registration.)
6.3 Header Field Names 6.3 Header Field Names
This specification registers three new header fields, namely This specification registers three new header fields, namely
Security-Client, Security-Server and Security-Verify. These headers Security-Client, Security-Server and Security-Verify. These headers
are defined by the following information, which is to be included are defined by the following information, which has been included in
inthe sub-registry for SIP headers under http://www.iana.org/ the sub-registry for SIP headers under
assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Header Name: Security-Client Header Name: Security-Client
Compact Form: (none) Compact Form: (none)
Header Name: Security-Server Header Name: Security-Server
Compact Form: (none) Compact Form: (none)
Header Name: Security-Verify Header Name: Security-Verify
Compact Form: (none) Compact Form: (none)
6.4 Response Codes 6.4 Response Codes
This specification registers a new response code, namely 494 This specification registers a new response code, namely 494
(Security Agreement Required). The response code is defined by the (Security Agreement Required). The response code is defined by the
following information, which is to be included to the sub-registry following information, which has been included to the sub-registry
for SIP methods and response-codes under http://www.iana.org/ for SIP methods and response-codes under
assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Response Code Number: 494 Response Code Number: 494
Default Reason Phrase: Security Agreement Required Default Reason Phrase: Security Agreement Required
6.5 Option Tags 6.5 Option Tags
This specification defines a new option tag, namely sec-agree. The This specification defines a new option tag, namely sec-agree. The
option tag is defined by the following information, which is to be option tag is defined by the following information, which has been
included in the sub-registry for option tags under http:// included in the sub-registry for option tags under
www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sec-agree Name: sec-agree
Description: This option tag indicates support for the Security Description: This option tag indicates support for the Security
Agreement mechanism. When used in the Require, or Agreement mechanism. When used in the Require, or
Proxy-Require headers, it indicates that proxy servers Proxy-Require headers, it indicates that proxy servers
are required to use the Security Agreement mechanism. are required to use the Security Agreement mechanism.
When used in the Supported header, it indicates that When used in the Supported header, it indicates that
the User Agent Client supports the Security Agreement the User Agent Client supports the Security Agreement
mechanism. When used in the Require header in the 494 mechanism. When used in the Require header in the 494
(Security Agreement Required) or 421 (Extension Required) (Security Agreement Required) or 421 (Extension
responses, it indicates that the User Agent Client must Required) responses, it indicates that the User Agent
use the Security Agreement Mechanism. Client must use the Security Agreement Mechanism.
7. Contributors 7. Contributors
Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to
the document. the document.
8. Acknowledgements 8. Acknowledgements
In addition to the contributors, the authors wish to thank Allison In addition to the contributors, the authors wish to thank Allison
Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh, Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh,
Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia, Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia,
Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP
SA3 group for interesting discussions in this problem space. SA3 group for interesting discussions in this problem space.
Normative References 9. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Kent, S. and R. Atkinson, "Security Architecture for the [2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [3] Dierks, T. and C. Allen, P. Kocher, "The TLS Protocol Version
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1.0", RFC 2246, January 1999.
1999.
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
skipping to change at page 21, line 29 skipping to change at page 20, line 18
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
Informative References 10. Informative References
[11] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) [11] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol Release 5 requirements on the Session Initiation Protocol
(SIP)", draft-ietf-sipping-3gpp-r5-requirements-00 (work in (SIP)", Work in Progress.
progress), October 2002.
[12] 3rd Generation Partnership Project, "Access security for IP- [12] 3rd Generation Partnership Project, "Access security for IP-
based services, Release 5", TS 33.203 v5.3.0, September 2002. based services, Release 5", TS 33.203 v5.3.0, September 2002.
[13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and [13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
AH", RFC 2403, November 1998. AH", RFC 2403, November 1998.
[14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP [14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998. and AH", RFC 2404, November 1998.
[15] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", [15] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms",
RFC 2451, November 1998. RFC 2451, November 1998.
Authors' Addresses
Jari Arkko
Ericsson
Hirsalantie 1
Jorvas, FIN 02420
Finland
Phone: +358 40 507 9256
EMail: jari.arkko@ericsson.com
Vesa Torvinen
Ericsson
Joukahaisenkatu 1
Turku, FIN 20520
Finland
Phone: +358 40 723 0822
EMail: vesa.torvinen@ericsson.fi
Gonzalo Camarillo
Ericsson
Hirsalantie 1
Jorvas, FIN 02420
Finland
Phone: +358 40 702 3535
EMail: gonzalo.camarillo@ericsson.com
Aki Niemi
Nokia
P.O. Box 301
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Tao Haukka
Nokia
P.O. Box abc
NOKIA GROUP, FIN 00045
Finland
Phone: +358 40 517 0079
EMail: tao.haukka@nokia.com
Appendix A. Syntax of ipsec-3gpp Appendix A. Syntax of ipsec-3gpp
This appendix specifies the syntax of non-normative parameters to be This appendix extends the security agreement framework described in
used in 3GPP IP Multimedia Subsystem [12] with security mechanism this document with a new security mechanism: "ipsec-3gpp". This
"ipsec-3gpp". The notation used in the Augmented BNF definitions is security mechanism and its associated parameters are used in the 3GPP
as used in SIP [1]. IP Multimedia Subsystem [12]. The Augmented BNF definitions below
follow the syntax of SIP [1].
mechanism-name = ( "ipsec-3gpp" ) mechanism-name = ( "ipsec-3gpp" )
mech-parameters = ( algorithm / protocol /mode / mech-parameters = ( algorithm / protocol /mode /
encrypt-algorithm / spi / encrypt-algorithm / spi /
port1 / port2 ) port1 / port2 )
algorithm = "alg" EQUAL ( "hmac-md5-96" / algorithm = "alg" EQUAL ( "hmac-md5-96" /
"hmac-sha-1-96" ) "hmac-sha-1-96" )
protocol = "prot" EQUAL ( "ah" / "esp" ) protocol = "prot" EQUAL ( "ah" / "esp" )
mode = "mod" EQUAL ( "trans" / "tun" ) mode = "mod" EQUAL ( "trans" / "tun" )
encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" ) encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
spi = "spi" EQUAL spivalue spi = "spi" EQUAL spivalue
spivalue = 10DIGIT; 0 to 4294967295 spivalue = 10DIGIT; 0 to 4294967295
port1 = "port1" EQUAL port port1 = "port1" EQUAL port
port2 = "port2" EQUAL port port2 = "port2" EQUAL port
port = 1*DIGIT port = 1*DIGIT
The parameters described by the BNF above have the following The parameters described by the BNF above have the following
semantics: semantics:
Algorithm Algorithm
This parameter defines the used authentication algorithm. It may This parameter defines the used authentication algorithm. It
have a value of "hmac-md5-96" for HMAC-MD5-96 [13], or "hmac-sha- may have a value of "hmac-md5-96" for HMAC-MD5-96 [13], or
1-96" for HMAC-SHA-1-96 [14]. The algorithm parameter is "hmac-sha-1-96" for HMAC-SHA-1-96 [14]. The algorithm
mandatory. parameter is mandatory.
Protocol Protocol
This parameter defines the IPsec protocol. It may have a value of This parameter defines the IPsec protocol. It may have a value
"ah" for AH [6], or "esp" for ESP [7]. If no Protocol parameter of "ah" for AH [6], or "esp" for ESP [7]. If no Protocol
is present, the protocol will be ESP by default. parameter is present, the protocol will be ESP by default.
Mode Mode
This parameter defines the mode in which the IPsec protocol is This parameter defines the mode in which the IPsec protocol is
used. It may have a value of "trans" for transport mode, or a used. It may have a value of "trans" for transport mode, or a
value of "tun" for tunneling mode. If no Mode parameter is value of "tun" for tunneling mode. If no Mode parameter is
present the the IPsec protocol is used in transport mode. present the IPsec protocol is used in transport mode.
Encrypt-algorithm Encrypt-algorithm
This parameter defines the used encryption algorithm. It may have This parameter defines the used encryption algorithm. It may
a value of "des-ede3-cbc" for 3DES [15], or "null" for no have a value of "des-ede3-cbc" for 3DES [15], or "null" for no
encryption. If no Encrypt-algorithm parameter is present, encryption. If no Encrypt-algorithm parameter is present,
encryption is not used. encryption is not used.
Spi Spi
Defines the SPI number used for inbound messages. Defines the SPI number used for inbound messages.
Port1 Port1
Defines the port number for inbound messages. Defines the destination port number for inbound messages that
are protected.
Port2 Port2
Defines the port number for outbound messages. If no Port2 Defines the source port number for outbound messages that are
parameter is present port1 is also used for outbound messages. protected. Port 2 is optional.
The communicating SIP entities need to know beforehand which keys to The communicating SIP entities need to know beforehand which keys to
use. It is also assumed that the underlying IPsec implementation use. It is also assumed that the underlying IPsec implementation
supports selectors that allow all transport protocols supported by supports selectors that allow all transport protocols supported by
SIP to be protected with a single SA. The duration of security SIP to be protected with a single SA. The duration of security
association is the same as in the expiration interval of the association is the same as in the expiration interval of the
corresponding registration binding. corresponding registration binding.
Authors' Addresses
Jari Arkko
Ericsson
Jorvas, FIN 02420
Finland
Phone: +358 40 507 9256
EMail: jari.arkko@ericsson.com
Vesa Torvinen
Ericsson
Joukahaisenkatu 1
Turku, FIN 20520
Finland
Phone: +358 40 723 0822
EMail: vesa.torvinen@ericsson.fi
Gonzalo Camarillo
Advanced Signalling Research Lab.
Ericsson
FIN-02420 Jorvas
Finland
Phone: +358 40 702 3535
EMail: Gonzalo.Camarillo@ericsson.com
Aki Niemi
NOKIA Corporation
P.O.Box 321, FIN 00380
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Tao Haukka
Nokia Corporation
P.O. Box 50
FIN - 90570 Oulu
Finland
Phone: +358 40 517 0079
EMail: tao.haukka@nokia.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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