Internet DRAFT - draft-saito-mmusic-sdes-ipsec
draft-saito-mmusic-sdes-ipsec
MMUSIC Working Group
Internet Draft M. Saito
draft-saito-mmusic-sdes-ipsec-00 NTT Communications
Expires: December 2006 June 2006
Security Descriptions Extension for IPsec
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or 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.
Abstract
In this document, a method of exchanging IPsec key information based
on security descriptions [sdesc] framework is defined. By making use
of this method, it is possible to negotiate IPsec with the offer-
answer model with SDP [RFC3264] in order to protect a media session.
Necessary extensions to security descriptions are also defined.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction..................................................2
2. Applicability.................................................3
Saito Expires - December 2006 [Page 1]
Security Descriptions Extension for IPsec June 2006
3. Definition of Extension.......................................3
3.1. Extension to Media Type..................................3
3.2. Extension to Crypto-suite................................4
3.3. Definition of Key-method.................................4
3.4. Extension to Key-info....................................4
4. Negotiation of IPsec SA.......................................6
4.1. Basic Mechanism..........................................6
4.2. Key Generation...........................................7
4.3. Security Policy for IPsec................................8
4.4. Rekeying.................................................8
4.5. About NAT Environment....................................8
5. Examples......................................................9
6. Grammar......................................................11
6.1. Generic "Crypto" Attribute Grammar......................11
6.2. IPsec Crypto Attribute Grammar..........................11
7. Comparison with IKE..........................................13
7.1. Comparison in Negotiation Phase.........................13
7.2. Comparison with IKE Quick Mode..........................13
8. Security Considerations......................................16
9. IANA Considerations..........................................16
9.1. IPsec Media Stream Transport............................16
9.2. IPsec Crypto Suite......................................17
10. References.................................................17
10.1. Normative References..................................17
10.2. Informative References................................18
1. Introduction
When a SIP-based application uses general or dedicated media
protocols, it is effective to apply IPsec as a security protocol for
them. TLS [RFC2246] and DTLS [DTLS] are the other candidates for this
use, but IPsec has the advantages that it can easily protect the
several media transports in a lump and in addition the applications
can omit the implementation of security protocol stacks. However
described in the requirement document [ipsec-req], it is necessary to
set up a lot of option parameters properly in order to establish
IPsec Security Association (SA). And it requires technical knowledge
even if using IKE, which does it automatically.
On the other hand, there are several key exchange frameworks for SIP-
based applications to protect their media sessions by SRTP, such as
MIKEY/key-mgmt [RFC3830] [keymgt] and security descriptions. And then
applications will be able to use IPsec easily by extending these
frameworks so as to support the exchange of IPsec key information. As
one of approaches for that, this document describes the extension for
IPsec key exchange in the security descriptions framework.
Saito Expires - December 2006 [Page 2]
Security Descriptions Extension for IPsec June 2006
2. Applicability
Similar to security descriptions, this specification that defines the
extension to support IPsec, assumes cryptographic key distribution
within the SDP message through the signaling which is protected by
some methods. Key-mgmt provides similar cryptographic key
distribution capabilities, but is intended for use when the signaling
is to be confidential and/or integrity-protected separated from the
keying material.
3. Definition of Extension
It is necessary to extend the format and semantics of security
descriptions framework in order to exchange IPsec key. This section
defines the method to negotiate the parameters related to IPsec (i.e.
IPsec SA) using "crypto" attribute.
3.1. Extension to Media Type
In the spec of security descriptions, crypto-suite is defined
depending on media stream transport. For example,
AES_CM_128_HMAC_SHA1_80 is defined as a crypto-suite for SRTP. Media
stream transport depends on the value of transport sub-field in "m="
field (ex. RTP/SAVP) defined in SDP [RFC2327].
In addition, when the initial offer includes one or more crypto
attributes, the answer MUST accept one of them or reject the session.
This means UA cannot fall-back to the non-secure session as a result
of SRTP negotiation. Crypto attribute can be used only when the
secure transport is offered in the "m=" field of SDP.
As described above, crypto attribute and transport are closely
related with each other so that it is necessary to define the new
transports that indicate the binding with IPsec. As for the general
UDP session or TCP connection, "UDP" [RFC2327] and "TCP" [RFC4145]
are already defined as the values of media type field. Therefore in
this document, the following media types are provided.
ESP_TRANSPORT/UDP: UDP session encrypted by ESP transport mode
AH_TRANSPORT/UDP: UDP session encrypted by AH transport mode
ESP_TRANSPORT/TCP: TCP connection encrypted by ESP transport mode
AH_TRANSPORT/TCP: TCP connection encrypted by AH transport mode
ESP_TRANSPORT: Host-to-Host encryption by ESP transport mode
AH_TRANSPORT: Host-to-Host encryption by AH transport mode
When the above media type is specified in the offer/answer SDP, IPsec
SAs that protect the corresponding UDP or TCP or Host-to-Host
sessions MUST be also negotiated at the same time. If the negotiation
Saito Expires - December 2006 [Page 3]
Security Descriptions Extension for IPsec June 2006
of IPsec SAs is failed, also the negotiation of media sessions MUST
be failed.
When "ESP_TRANSPORT" or "AH_TRANSPORT" is specified as a media type,
the port field in "m=" cannot have the meaningful value because IPsec
does not protect only a specific port but all the traffic between
nodes. In such a case, both offer SDP and answer SDP specify the
value 9 (discard port) in the port field and each application MUST
ignore this value.
3.2. Extension to Crypto-suite
The above new media types substantially need the definition of two
media stream transports, that is, transport mode ESP and transport
mode AH. Therefore crypto-suite needs to be extended in order to
support these two media stream transports. In this document, the
following crypto-suites are defined.
Crypto-suite | Encryption | Authentication
for Transport Mode ESP | Algorithm | Algorithm
----------------------------------------------------------------
ESP_AES_CBC_128_HMAC_SHA1_96 | AES-CBC | HMAC-SHA-1-96
| (128 bits key) | [RFC2404]
ESP_AES_CBC_128_HMAC_MD5_96 | AES-CBC | HMAC-MD5-96
| (128 bits key) | [RFC2403]
ESP_3DES_CBC_HMAC_SHA1_96 | 3DES-CBC | HMAC-SHA-1-96
ESP_3DES_CBC_HMAC_MD5_96 | 3DES-CBC | HMAC-MD5-96
ESP_NULL_HMAC_SHA1_96 | NULL Encryption | HMAC-SHA1-96
ESP_NULL_HMAC_MD5_96 | NULL Encryption | HMAC-MD5-96
AH_HMAC_SHA1_96 | N/A | HMAC-SHA-1-96
AH_HMAC_MD5_96 | N/A | HMAC-MD5-96
3.3. Definition of Key-method
In this specification, pre-existing key-method "inline" is used. When
"inline" is used, actual keying material is included in the key-info
field.
3.4. Extension to Key-info
When the media types defined in 3.1 are used and key-method is
"inline", key-info includes the following parameters.
nonce: Parameter of keying material. The random
number whose length is 128bits is generated
and then base64 encoded.
Saito Expires - December 2006 [Page 4]
Security Descriptions Extension for IPsec June 2006
protocol: Protocol that will be protected by IPsec SA.
As the value, "udp", "tcp", "icmp" and "any"
are defined.
offerer-address: Offerer's IP address used in IPsec SA. But it
MUST be reachable from answerer.
answerer-address: Answerer's IP address used in IPsec SA. But
it MUST be reachable from offerer.
offerer-spi: SPI (Security Parameter Index) of offerer's
inbound IPsec SA. The value is in decimal.
Offerer-spi MUST be decided by the offerer.
answerer-spi: SPI of answerer's inbound IPsec SA. The value
is in decimal. Answerer-spi MUST be decided
by the answerer.
offerer-life-type: The unit of life duration for offerer's
inbound IPsec SA. The value is "sec" that
represents second, or "kb" that represents
kilobyte.
offerer-life: Life duration of offerer's inbound IPsec SA.
The value is in decimal.
answerer-life-type: The unit of life duration for answerer's
inbound IPsec SA. The value is "sec" that
represents second, or "kb" that represents
kilobyte.
answerer-life: Life duration of answerer's inbound IPsec SA.
The value is in decimal.
offerer-port: In the case that "protocol" is "tcp" or
"udp", offerer's local port number that
should be separately protected by IPsec SA
can be specified. The value is between 0 and
65535 in decimal, or "any". The value "0" and
"any" have the same meaning. By the way, the
media from the answerer MUST be able to reach
the pair of offerer-address and offerer-port.
answerer-port: In the case that "protocol" is "tcp" or
"udp", answerer's local port number that
should be separately protected by IPsec SA
can be specified. The value is between 0 and
65535 in decimal, or "any". The value "0" and
"any" have the same meaning. By the way, the
Saito Expires - December 2006 [Page 5]
Security Descriptions Extension for IPsec June 2006
media from the offerer MUST be able to reach
the pair of answerer-address and answerer-
port.
These parameters appear in key-info in the following format. The
details are defined in the chapter 5.
"inline:" <nonce> "|" <protocol> "|" [offerer-address] ":"
[answerer-address] "|" [offerer-spi] ":" <offerer-life-type> ":"
<offerer-life> [":" [offerer-port] ":" [answerer-port] ] ":"
[answerer-spi] ":" <answerer-life-type> ":" <answerer-life> [":"
[offerer-port] ":" [answerer-port] ]
The whole key-info includes all the parameters necessary for a pair
of IPsec SAs (inbound IPsec SA and outbound IPsec SA). The parameters
of the first, second and third fields separated by "|" are used in
common to both inbound IPsec SA and outbound IPsec SA. On the other
hand, the parameters of the fourth field are used for offerer's
inbound IPsec SA, and those of the fifth field are used for offerer's
outbound IPsec SA.
4. Negotiation of IPsec SA
4.1. Basic Mechanism
The offer/answer example of IPsec SA negotiation using security
descriptions is as follows.
v=0
o=sam 2890844526 2890842807 IN IP4 192.168.0.1
s=sample
c=IN IP4 192.168.0.1
t=2873397496 2873404696
m=application 49170 ESP_TRANSPORT/UDP sample-appl
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1:
|4321:sec:3600:49170:|:sec:3600:49170:
a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1:
|4321:sec:3600:49170:|:sec:3600:49170:
In reply to the above offer SDP, the following answer SDP can be
sent.
v=0
o=jill 25690844 8070842634 IN IP4 172.16.0.1
s=sample
c=IN IP4 172.16.0.1
t=2873397526 2873405696
Saito Expires - December 2006 [Page 6]
Security Descriptions Extension for IPsec June 2006
m=application 32640 ESP_TRANSPORT/UDP sample-appl
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:MTIzNDU2Nzg5MGFiY2RlZg==|udp|192.168.0.1:172.16.0.1
|4321:sec:3600:49170:32640|1234:sec:3600:49170:32640
In this example, the offerer sends two crypto attributes (two
candidates of SA proposal) and the answerer accepts the first one. SA
proposals of offer SDP are incomplete because the answerer's local IP
address and port number are not decided at the time of generating
offer SDP. Therefore the answerer MUST complete these SA proposals
when generating answer SDP.
When key-method is "inline", offer SDP MUST include the values of
nonce, protocol, offerer-address, offerer-spi, offerer-life and
answer-life fields. And if "udp" or "tcp" is specified in the
protocol field, offer SDP MAY specify the values of the first and
second offerer-port fields (If they are omitted, it means the same as
"any" is specified). If the offerer knows the IP address and service
port of the answerer by some means or other in advance, offer SDP MAY
include the values of answerer-address and the first and second
answerer-port fields. However, offer SDP MUST NOT include the value
of answerer-spi field.
In the answer SDP, all the values of all the fields except for the
nonce field MUST NOT be changed from those of the offer SDP. But the
field whose value is omitted in the offer SDP MUST be filled up in
the answer SDP. In nonce field, the answerer MUST specify the random
value the answerer newly generates. On the other hand, when the
offerer omits the offerer-port field itself, the answerer MUST NOT
add the offerer-port and answerer-port fields.
4.2. Key Generation
As a result of offer/answer SDP exchange, both offerer and answerer
can generate the shared secret for IPsec SA. The method to generate
the secret key is defined in this section, but the following notation
is used throughout this section.
| indicates concatenation of information. For example, X|Y means
the concatenation of X with Y. [x] indicates that x is optional.
prf(key,msg) indicates the keyed pseudo-random function.
When key-method is "inline", the keying material KMAT is generated
for each IPsec SA as follows.
KMAT = K1|K2|K3|...
K1 = prf(offer-nonce|answer-nonce,
crypto-suite|spi|offer-nonce|answer-nonce)
K2 = prf(offer-nonce|answer-nonce,
Saito Expires - December 2006 [Page 7]
Security Descriptions Extension for IPsec June 2006
K1|crypto-suite|spi|offer-nonce|answer-nonce)
K3 = prf(offer-nonce|answer-nonce,
K2|crypto-suite|spi|offer-nonce|answer-nonce)
...
If the authentication algorithm specified in the crypto-suite is
HMAC-SHA1-96, HMAC-SHA1 (output is 160 bits) is used for prf. If it
is HMAC-MD5-96, HMAC-MD5 (output is 128 bits) is used for prf. Offer-
nonce means the value of nonce field included in offer SDP. Answer-
nonce means the value of nonce field included in answer SDP. Spi
means the SPI value (32 bits binary data) of the IPsec SA. And
crypto-suite means the value (in ASCII code) of crypto-suite field
defined in crypto attribute.
The encryption key for IPsec SA is cut out from the head of KMAT for
the necessary length for its encryption algorithm. The authentication
key for IPsec SA is cut out from the next bit of that for the
necessary length for its authentication algorithm. For example, if
the crypto-suite is ESP_AES_CBC_128_HMAC_SHA1_96, the first 128 bits
of KMAT is used for the encryption key of ESP and the following 160
bits is used for the authentication key of HMAC-SHA1. In the case of
NULL encryption or AH, only the authentication key is cut out from
the head of KMAT.
4.3. Security Policy for IPsec
IPsec SAs can be generated by using offer/answer negotiation in this
document, but at the same time both the offerer and the answerer MUST
install the proper security policy for IPsec dynamically in
themselves. The method to install security policy is outside the
scope of this document.
4.4. Rekeying
Because IPsec SA has its life time, it MUST be refreshed sufficiently
before it expires. The simplest way is negotiating IPsec SA again by
generating re-INVITE. A user agent that supports session timers
[RFC4028] MAY set the life duration of IPsec SA equal to the session
timer, and refresh the IPsec SA synchronously with the session
refresh.
4.5. About NAT Environment
As defined in 3.4, IP address and port information exchanged in key-
info MUST be reachable from the other peer. Even in NAT environment,
such information can be acquired by making use of the framework such
as ICE [ICE]. Of course, it is also necessary to implement UDP
encapsulation [RFC3948] and so on, in order to traverse NAT. However
the solution for IPsec NAT traversal itself depends on the method of
Saito Expires - December 2006 [Page 8]
Security Descriptions Extension for IPsec June 2006
NAT traversal of media (for example, the method using L2TP [RFC3931]
can also be thought), therefore the solution in NAT environment is
outside the scope of this document.
5. Examples
In this chapter, several examples of offer/answer SDP based on this
specification are illustrated.
The simplest example is protecting all the IP packets between two
hosts, that is, Host-to-Host encryption. The example of negotiating
IPsec SAs that cover all the IP packets between the offerer and the
answerer is as follows.
offer SDP
v=0
o=sam 2890844526 2890842807 IN IP4 192.168.0.1
s=sample
c=IN IP4 192.168.0.1
t=2873397496 2873404696
m=application 9 ESP_TRANSPORT sample-appl
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|any|192.168.0.1:
|4321:sec:3600|:sec:3600
a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|any|192.168.0.1:
|4321:sec:3600|:sec:3600
answer SDP
v=0
o=jill 25690844 8070842634 IN IP4 172.16.0.1
s=sample
c=IN IP4 172.16.0.1
t=2873397526 2873405696
m=application 9 ESP_TRANSPORT sample-appl
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:MTIzNDU2Nzg5MGFiY2RlZg==|any|192.168.0.1:172.16.0.1
|4321:sec:3600|1234:sec:3600
In this case, both offer SDP and answer SDP specify the value 9
(discard port) in the port field in "m=", but it is ignored at the
application layer.
The following example shows the situation that the offerer accepts
UDP datagram from the answerer at the UDP port 7000, and the answerer
accepts UDP datagram from the offerer at the UDP port 8000. In order
to protect these media stream, two IPsec SAs are negotiated. The
former has the selector that the source port of the answerer is "any"
and the destination port of the offerer is 7000. The latter has the
Saito Expires - December 2006 [Page 9]
Security Descriptions Extension for IPsec June 2006
selector that the source port of the offerer is "any" and the
destination port of the answerer is 8000.
offer SDP
v=0
o=sam 2890844526 2890842807 IN IP4 192.168.0.1
s=sample
c=IN IP4 192.168.0.1
t=2873397496 2873404696
m=application 7000 ESP_TRANSPORT/UDP sample-appl
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1:
|4321:sec:3600:7000:|:sec:3600:any:
a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1:
|4321:sec:3600:7000:|:sec:3600:any:
answer SDP
v=0
o=jill 25690844 8070842634 IN IP4 172.16.0.1
s=sample
c=IN IP4 172.16.0.1
t=2873397526 2873405696
m=application 8000 ESP_TRANSPORT/UDP sample-appl
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:MTIzNDU2Nzg5MGFiY2RlZg==|udp|192.168.0.1:172.16.0.1
|4321:sec:3600:7000:any|1234:sec:3600:any:8000
And the following example shows the case that the offerer is a TCP
client and the answerer is a TCP server that accepts the TCP
connection at the port 8000. In order to protect this TCP connection,
two IPsec SAs are negotiated. The former has the selector that the
source port of the answerer is 8000 and the destination port of the
offerer is "any". The latter has the selector that the source port of
the offerer is "any" and the destination port of the answerer is
8000.
offer SDP
v=0
o=sam 2890844526 2890842807 IN IP4 192.168.0.1
s=sample
c=IN IP4 192.168.0.1
t=2873397496 2873404696
m=application 9 ESP_TRANSPORT/TCP sample-appl
a=setup:active
a=connection:new
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|tcp|192.168.0.1:
|4321:sec:3600:any:|:sec:3600:any:
Saito Expires - December 2006 [Page 10]
Security Descriptions Extension for IPsec June 2006
a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96
inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|tcp|192.168.0.1:
|4321:sec:3600:any:|:sec:3600:any:
answer SDP
v=0
o=jill 25690844 8070842634 IN IP4 172.16.0.1
s=sample
c=IN IP4 172.16.0.1
t=2873397526 2873405696
m=application 8000 ESP_TRANSPORT/TCP sample-appl
a=setup:passive
a=connection:new
a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96
inline:MTIzNDU2Nzg5MGFiY2RlZg==|tcp|192.168.0.1:172.16.0.1
|4321:sec:3600:any:8000|1234:sec:3600:any:8000
6. Grammar
In this chapter the ABNF grammar for this specification is defined.
6.1. Generic "Crypto" Attribute Grammar
In the section 9.1 of [sdes], the following definition is provided as
the generic "crypto" attribute grammar.
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param)
key-param = key-method ":" key-info
key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = %x21-3A / %x3C-7E ; visible (printing) characters
; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters
where WSP, ALPHA, DIGIT and VCHAR are defined in [RFC2234].
6.2. IPsec Crypto Attribute Grammar
The definition of ABNF grammar for the IPsec specific crypto
attribute is provided as follows.
crypto-suite = ipsec-crypto-suite
key-method = ipsec-key-method
Saito Expires - December 2006 [Page 11]
Security Descriptions Extension for IPsec June 2006
key-info = ipsec-key-info
session-param = ipsec-session-param
ipsec-crypto-suite = "ESP_AES_CBC_128_HMAC_SHA1_96" /
"ESP_AES_CBC_128_HMAC_MD5_96" /
"ESP_3DES_CBC_HMAC_SHA1_96" /
"ESP_3DES_CBC_HMAC_MD5_96" /
"ESP_NULL_HMAC_SHA1_96" /
"ESP_NULL_HMAC_MD5_96" /
"AH_HMAC_SHA1_96" /
"AH_HMAC_MD5_96"
ipsec-crypto-suite-ext
ipsec-key-method = "inline"
ipsec-key-info = nonce "|"
protocol "|"
[offerer-address] ":" [answerer-address] "|"
[offerer-spi] ":" offerer-life-type ":"
offerer-life [":" [offerer-port] ":"
[answerer-port] ] "|"
[answerer-spi] ":" answerer-life-type ":"
answerer-life [":" [offerer-port] ":"
[answerer-port] ]
nonce = 1*(base64) ; base64 encoded binary nonce
; value [RFC3548]
protocol = "tcp" /
"udp" /
"icmp" /
"any" /
protocol-ext
offerer-address = IP-address
answerer-address = IP-address
offerer-spi = spi-value
answerer-spi = spi-value
offerer-life-type = life-type-value
answerer-life-type = life-type-value
offerer-life = life-value
answerer-life = life-value
offerer-port = port-value
answerer-port = port-value
IP-address = IP4-address | IP6-address
IP4-address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT
IP6-address = hexpart [ ":" IP4-address]
Saito Expires - December 2006 [Page 12]
Security Descriptions Extension for IPsec June 2006
hexpart = hexseq / hexseq "::" [hexseq] / "::"
[hexseq]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
spi-value = 1*10DIGIT
life-type-value = "sec" /
"kb" /
life-type-value-ext
life-value = 1*DIGIT
port-value = 1*5DIGIT / "any"
ipsec-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
protocol-ext = 1*(ALPHA / DIGIT / "_")
life-type-value-ext
= 1*(ALPHA / DIGIT / "_")
base64 = ALPHA / DIGIT / "+" / "/" / "="
ipsec-session-param
= ipsec-session-ext
ipsec-session-ext = ["-"] 1*(VCHAR) ; visible chars[RFC2234]
; first character must
; not be dash ("-")
7. Comparison with IKE
For reference, this section describes the comparison with IKE
[RFC2409] which is widespread as the key-exchange protocol for IPsec.
7.1. Comparison in Negotiation Phase
In the specification of ISAKMP [RFC2408], two negotiation phases to
establish SA are defined. In the first phase, ISAKMP SA which
protects the following negotiation traffic is established, and in the
second phase, SA for the security protocol is established. However,
it is allowed to skip the initial ISAKMP exchange and establish an SA
directly if a basic set of security attributes is already in place
between the negotiating nodes. The specification in this document
assumes the SDP messages are protected (by S/MIME and so on),
therefore it can be compared to just the SA negotiation in IKE phase
2 skipping the first ISAKMP exchange.
7.2. Comparison with IKE Quick Mode
The message flow of IKE phase 2 quick mode is as follows.
Saito Expires - December 2006 [Page 13]
Security Descriptions Extension for IPsec June 2006
Initiator Responder
HDR, HASH(1), SA, Ni,
[, KE] [, IDci, IDcr] -->
HDR, HASH(2), SA, Nr,
<-- [, KE] [, IDci, IDcr]
HDR, HASH(3) -->
HDR: ISAKMP header. Only this header in the above
parameters is exchanged in plain text.
HASH: Hash payload.
SA: SA negotiation payload with one or more proposals.
Ni, Nr: Initiator nonce payload and responder nonce payload.
KE: Key exchange payload.
IDci, IDcr: Initiator identification payload and responder
identification payload.
In the case of IKE, a single ISAKMP SA can include several different
quick modes (they are distinguished by Message ID), but in the case
of security descriptions, a key exchange process cannot have multiple
sessions because that process is bound to an offer/answer model with
SDP [RFC3264], which prescribes a single SDP cannot have multiple
sessions.
Hash payload in the IKE quick mode is used for message integrity and
anti-replay attack based on the authentication key generated in the
phase 1. But in security descriptions, it is assumed that AKE is
provided at least to SDP, therefore a mechanism corresponding to hash
payload is not necessary.
SA proposal part in the IKE quick mode negotiates the following
parameters.
o DOI, Situation (SA payload)
o protocol ID of the security protocol, SPI (proposal payload)
o SA attributes (transform payload)
Parameters that can be negotiated in SA attributes are 9 classes
defined in 4.5 of [RFC2407], and all ISAKMP implementations MUST be
prepared to negotiate the following parameters among them to ensure
basic interoperability.
o SA Life Type (the unit of life duration for SA: seconds,
kilobytes)
o Auth Algorithm (the authentication algorithm attribute)
Saito Expires - December 2006 [Page 14]
Security Descriptions Extension for IPsec June 2006
DOI and Situation are not exchanged in the security descriptions. The
parameters corresponding to protocol ID of the security protocol are
provided in the media type field (3.1) and in the crypto-suite field
(3.2). In addition, the value of crypto-suite includes Auth Algorithm
because crypto-suite is defined as the set of encryption algorithm
and authentication algorithm. In the case of IKE, it is possible to
offer multiple SA attributes, which are listed in the priority order.
And it is also possible in the case of security descriptions by
listing "a=crypto" attributes in the priority order. By the way,
there is a default value of 28800 seconds for SA Duration in IKE, but
life-type and life must be negotiated in security descriptions.
A parameter in the security descriptions corresponding to nonce
payload in the IKE quick mode is "nonce" defined in 3.4.
KE payload in the IKE quick mode is optional and used to provide PFS
(Perfect Forward Secrecy). In order to provide PFS in security
descriptions, there is a framework of Diffie-Hellman exchange [sdp-
dh], therefore this document does not specify the parameter
corresponding to KE payload.
Identification payload in the IKE quick mode makes it possible to
exchange ID information of each node (if omitted, IP address of the
node is used). Security descriptions provide the similar function by
inserting the information about IP address, transport protocol and
port into the key-info field. However it does not support the
information such as hostname, username, subnet, address range, and
certificate supported by IKE.
By the way, a method to calculate the keying material in the IKE
quick mode that does not have KE payload is as follows.
KEYMAT = prf(SKEYID_d, protocol | protocol | SPI | Ni_b | Nr_b)
SKEYID_d: keying material generated in the IKE phase 1
protocol: protocol ID (1 byte) included in proposal payload
SPI: SPI (4 bytes) included in proposal payload
Ni_b: random value in initiator's nonce payload
Nr_b: random value in responder's nonce payload
And if the length of KEYMAT is not sufficiently long, it is extended
by the following caluculation.
KEYMAT = K1 | K2 | K3 | ...
K1 = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b)
K2 = prf(SKEYID_d, K1 | protocol | SPI | Ni_b | Nr_b)
K3 = prf(SKEYID_d, K2 | protocol | SPI | Ni_b | Nr_b)
Saito Expires - December 2006 [Page 15]
Security Descriptions Extension for IPsec June 2006
As a result, the components of KEYMAT in IKE are the keying material
generated in phase 1, protocol, SPI, initiator's nonce and
responder's nonce, which are negotiated in phase 2. KEYMAT in the
security descriptions is calculated as described in 4.2. Because
there is no process corresponding to the IKE phase 1 in the security
descriptions, the parameter corresponding to SKEYID_d does not exist,
therefore the concatenation of offer-nonce and answer-nonce is used
instead. In addition, crypto-suite is used instead of protocol ID
parameter in IKE. The other components are the same as IKE.
8. Security Considerations
When using security descriptions framework for IPsec keying, the
following properties must be considered.
o overlap of IPsec SAs belonging to multiple INVITE sessions
Although it depends on the implementations, if there are
multiple pairs of IPsec SA belonging to multiple INVITE
sessions and their selectors overlap to each other, all the
media sessions may be protected by only a pair of IPsec SA.
Therefore, implementations are required to verify that any
IPsec SAs that can be used do not use a vulnerable algorithm.
o Security of SDP message
Security descriptions framework itself does not provide a
specific mechanism to protect SDP messages. Therefore, the
security of SDP message relies on the security protocol that
applications use (e.g., S/MIME, or a lower-layer security
service such as TLS and IPsec). If using the keying mechanism
defined in this document, SDP messages must be protected with
regard to replay protection, message authentication, and
message confidentiality.
9. IANA Considerations
IANA is requested to register new parameters related to Security
Descriptions extension for IPsec. The following sub-sections define
all of them based on the SDP Security Descriptions registry.
9.1. IPsec Media Stream Transport
IANA is requested to register new SDP Security Descriptions Media
Stream Transports named "ESP_TRANSPORT/UDP", "AH_TRANSPORT/UDP",
"ESP_TRANSPORT/TCP", "AH_TRANSPORT/TCP", "ESP_TRANSPORT" and
"AH_TRANSPORT". All of them represent transport mode ESP/AH, and the
key method supported is "inline".
Saito Expires - December 2006 [Page 16]
Security Descriptions Extension for IPsec June 2006
9.2. IPsec Crypto Suite
IANA is requested to create a new sub-registry for IPsec crypto
suites under the IPsec transport of the SDP Security Descriptions.
IANA IPsec crypto suite registration MUST indicate the crypto suite
name in accordance with the grammar for ipsec-crypto-suite-ext
defined in 6.2.
The following IPsec crypto suites are hereby registered:
ESP_AES_CBC_128_HMAC_SHA1_96
ESP_AES_CBC_128_HMAC_MD5_96
ESP_3DES_CBC_HMAC_SHA1_96
ESP_3DES_CBC_HMAC_MD5_96
ESP_NULL_HMAC_SHA1_96
ESP_NULL_HMAC_MD5_96
AH_HMAC_SHA1_96
AH_HMAC_MD5_96
10. References
10.1. Normative References
[sdesc] Andreasen, F., Baugher, M., and D. Wing, "SDP Security
Descriptions for Media Streams", work in progress,
September 2005.
[RFC3264] Rosenberg, J., and Schulzrinne, H., "An Offer/Answer
Model with the Session Description Protocol (SDP)",
RFC 3264, June 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2327] M. H andley, and V. Jacobson, "SDP: Session
Description Protocol", RFC 2327, April 1998.
[RFC4145] D. Yon, and G. Camarillo, "TCP-Based Media Transport
in the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC2404] C. Madson, and R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", RFC 2404, November 1998.
[RFC2403] C. Madson, and R. Glenn, "The Use of HMAC-MD5-96
within ESP and AH", RFC 2403, November 1998.
Saito Expires - December 2006 [Page 17]
Security Descriptions Extension for IPsec June 2006
[RFC4028] S. Donovan, and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028, April
2005.
[RFC2234] D. Crocker, Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC3548] S. Josefsson, Ed., "The Base16, Base32, and Base64
Data Encodings", RFC 3548, July 2003.
10.2. Informative References
[RFC2246] Dierks, T., and Allen, C., "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[DTLS] E. Rescorla, and N. Modadugu, "Datagram Transport
Layer Security", work in progress, June 2004.
[ipsec-req] M. Saito, and S. Fujimoto, "Requirements for IPsec
Negotiation in the SIP Framework", work in progress,
March 2006.
[RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K.
Norrman, "MIKEY: Multimedia Internet KEYing",
RFC 3830, August 2004.
[keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K.
Norrman, "Key Management Extensions for SDP and RTSP",
work in progress, June 2005.
[ICE] J. Rosenberg, "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator
(NAT) Traversal for Offer/Answer Protocols", work in
progress, March 2006.
[RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC3931] J. Lau, Ed., M. Townsley, Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, March 2005.
[RFC2409] D. Harkins, and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2408] D. Maughan, M. Schertler, M. Schneider, and J. Turner,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, November 1998.
Saito Expires - December 2006 [Page 18]
Security Descriptions Extension for IPsec June 2006
[RFC2407] D. Piper, "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[sdp-dh] M. Baugher, and D. McGrew, "Diffie-Hellman Exchanges
for Multimedia Sessions", work in progress, February
2006.
Saito Expires - December 2006 [Page 19]
Security Descriptions Extension for IPsec June 2006
Acknowledgements
The concepts of this document were discussed in the UOPF: Ubiquitous
Open Platform Forum (http://www.uopf.org/en/), which is participated
by many ISPs and information appliances makers and so on. The author
would like to thank the UOPF members and those who contributed to
this document.
And the author would also like to thank Mark Baugher and Shingo
Fujimoto for their suggestions and review.
Author's Address
Makoto Saito
NTT Communications
3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421 Japan
Phone: +81-3-6800-3262
Email: ma.saito@nttv6.jp
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Saito Expires - December 2006 [Page 20]
Security Descriptions Extension for IPsec June 2006
Copyright Notice
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Saito Expires - December 2006 [Page 21]
