Network Working Group M. Baugher
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Rueegsegger
Expires: August 24, 2007 secunet SwissIT AG
S. Rowles
Cisco Systems, Inc.
February 20, 2007
GDOI Key Establishment for the SRTP Data Security Protocol
draft-ietf-msec-gdoi-srtp-00.txt
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.
This Internet-Draft will expire on August 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Baugher, et al. Expires August 24, 2007 [Page 1]
Internet-Draft GDOI-SRTP February 2007
Abstract
The Secure Real-time Transport Protocol (SRTP) protects unicast and
multicast RTP packets. Multicast receivers of SRTP session data
therefore share an SRTP master key for message authentication and
decryption. This document describes how to establish a shared,
"group key" for an SRTP session using RFC 3547, the Group Domain of
Interpretation (GDOI) and RFC 2408, the Internet Security Association
and Key Management Protocol. This document extends GDOI for SRTP
group key establishment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of This Document . . . . . . . . . . . . . . . . 3
1.2. Conformance Language . . . . . . . . . . . . . . . . . . . 3
2. GDOI Signaling of an SRTP Crypto Context . . . . . . . . . . . 4
2.1. GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. GDOI Exchanges for SRTP . . . . . . . . . . . . . . . . . 7
2.3. SRTP SA-TEK Definitions . . . . . . . . . . . . . . . . . 9
2.4. EKT SA-TEK Definitions . . . . . . . . . . . . . . . . . . 14
2.5. SRTP Key Download . . . . . . . . . . . . . . . . . . . . 15
3. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.1. No Sharing Counter-Mode Encryption Keys . . . . . . . . . 17
4.2. Enable Distributed Key Management . . . . . . . . . . . . 17
4.3. Support Strong Source Authentication . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Baugher, et al. Expires August 24, 2007 [Page 2]
Internet-Draft GDOI-SRTP February 2007
1. Introduction
The Group Domain of Interpretation (GDOI) is an authenticated key
establishment protocol for groups, which is specified by RFC 3547
[RFC3547]. GDOI is based upon ISAKMP, the Internet Security
Association and Key Management Protocol [RFC2408]. GDOI extends
ISAKMP for group key management whereby a cryptographic key is shared
among multiple receivers and optionally multiple senders. GDOI uses
unicast (ISAKMP) as well as multicast key establishment method and
supports member revocation algorithms, such as the "key hierarchy"
algorithm of RFC 2627 [RFC2627]. GDOI preserves the ISAKMP design,
which supports new data security protocols through documented
procedures, but it currently supports only one data security
protocol, IPsec.
This document extends GDOI to a new data security protocol, the
Secure Real-time Transport Protocol (SRTP) as specified by RFC 3711
[RFC3711]. SRTP extensions to GDOI use two new GDOI payloads. The
GDOI-SRTP payload definitions apply GDOI key establishment procedures
to groups of SRTP receivers in accordance with Section 5.4.2 of the
GDOI protocol specification [RFC3547]. The SRTP payloads carry keys,
parameters, and other values needed for an SRTP session's
"cryptographic context", which is described in Section 8 of the SRTP
specification [RFC3711]. In addition to signaling SRTP, GDOI-SRTP
payloads MAY signal use of the Encrypted Key Transport (EKT) protocol
as an option [I-D.mcgrew-srtp-ekt]. These options, parameters and
keys are defined in two GDOI payloads, the "Security Association
Traffic Encrypting Key" (SA-TEK) payloads for SRTP (SRTP SA-TEK) and
EKT (EKT SA-TEK).
1.1. Overview of This Document
Section 2 of this document presents the GDOI-SRTP payloads. The SRTP
SA-TEK payload MAY carry IP address and port information, which have
implications for network address translation (NAT). Section 3 gives
NAT considerations, Section 4 discusses Security Considerations, and
Section 5 lists IANA requirements.
1.2. Conformance Language
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].
Baugher, et al. Expires August 24, 2007 [Page 3]
Internet-Draft GDOI-SRTP February 2007
2. GDOI Signaling of an SRTP Crypto Context
A service can use GDOI to establish keys (security associations) for
a data security protocol provided that GDOI is extended with one or
more payload definitions for that data security protocol. For GDOI,
a "data security protocol" is any protocol that uses the services of
GDOI. By contrast, TLS key establishment is packaged with the TLS
data-security protocol. GDOI follows the ISAKMP model in which key
management and data security MAY use separate transport addresses and
underlying transport protocols, typically UDP or TCP. By default,
GDOI uses UDP to negotiate an IKE phase 1 security association
between a GDOI Group Controller/Key Server (GCKS) and group member;
the IKE phase 1 protects an exchange to establish a security
association on behalf of an application security protocol. In SRTP,
a "security association" is called a "cryptographic context", and
this is the application-specific information carried in GDOI payloads
between the GCKS and a GDOI member. This section defines these SRTP
payloads for GDOI.
Baugher, et al. Expires August 24, 2007 [Page 4]
Internet-Draft GDOI-SRTP February 2007
Figure 2.0-1: Member and SRTP Interfaces in a Central GCKS
Configuration
+-------+
| GDOI |
| GCKS |
+-------+
^
|
V
+--------------------------+
| GDOI with SRTP payloads |
V V
+----------+ +----------+
|+--------+| |+--------+|
|| GDOI || || GDOI ||
|| Member || || Member ||
|+--------+| |+--------+|
| ^ | | ^ |
| | | | | |
| API | | API |
| | | | | |
| V | | V |
|+--------+| SRTP/SRTCP |+--------+|
|| SRTP |---------------->| SRTP ||
|| Source |<----------------|Receiver||
|+--------+| SRTCP |+--------+|
+----------+ +----------+
MEMBERi MEMBERj
This section gives the SRTP payloads for GDOI key management
exchanges. SRTP is an application-layer security protocol that
operates above the TCP/IP services (sockets) interface. GDOI also
operates above the transport service. SRTP communicates with GDOI
using the API shown in Figure 2.0-1. SRTP or another application
uses the API to request that GDOI establish an SRTP cryptographic
context (i.e. a GDOI "security association"), which is described in
Section 3.2 of the SRTP specification [RFC3711]. The API of Figure
2.0-1 is not considered further in this document, which is concerned
solely with extending the GDOI protocol with new payloads for SRTP.
Using this protocol extension, the GDOI Group Controller/Key Server
(GCKS) can provide the cryptographic keys, cryptographic parameters
and session parameters to SRTP (via the API to a GDOI Member) in
accordance with pre-configured group policy regarding which
parameters are acceptable and which are not. The GCKS might obtain
policy and some SRTP crypto-context information through a user
console or event database. The GCKS generates some information
Baugher, et al. Expires August 24, 2007 [Page 5]
Internet-Draft GDOI-SRTP February 2007
automatically, such as keying materials. How the GCKS obtains or
generates policy information for the SRTP payload fields is specific
to an implementation and not considered further in this document.
Figure 2.0-2: A Distributed GCKS Configuration
+----------+
+----------+ |+--------+|
+|+--------+| GDOI with || GDOI ||
||| GCKS & |<--------------->| GCKS & ||
||| Member || SRTP payloads|| Member ||
||+--------+| |+--------+|
|| ^ | | ^ |
|| | | | | |
|| API | | API |
|| | | | | |
|| V | | V |
||+--------+| SRTP/SRTCP |+--------+|
||| SRTP |---------------->| SRTP ||
||| Source |<----------------|Receiver||
||+--------+| SRTCP |+--------+|
|| MEMBERi | | MEMBERj |
|+----------+ +----------+
| MEMBERk |
+----------+
In a physical realization of GDOI system, the GDOI GKCS can either be
separate from or co-located with a GDOI Member. When physically co-
located with a member, the GCKS can be dedicated to maintaining the
group keys for that member's "SRTP Source", and the GCKS can more
easily obtain the SRTP-specific information for its payloads across
the API. This configuration is shown in Figure 2.0-2. It is often
more scalable for the GCKS to be physically co-located in the same
computer as the SRTP source of the multicast stream. When this
configuration is possible, there is no need for a centralized Group
Controller/Key Server.
2.1. GDOI and EKT
When the Group Controller/Key Server (GCKS) is centralized as a
third-party device, it is not co-located with the SRTP source, and it
is not always possible for the GCKS to get access to important SRTP
keystream parameters, which are the SSRC, the Rollover Counter (ROC)
and current SRTP sequence number (SEQ). This information is
generated internally by the SRTP source and used in the SRTP ciphers
and SRTP replay protection; the SSRC is used in combination with the
destination transport address to identify an RTP session [RFC3550]
and thus identify an SRTP session's crypto context. When the GCKS is
Baugher, et al. Expires August 24, 2007 [Page 6]
Internet-Draft GDOI-SRTP February 2007
co-located with the SRTP source, this information can be obtained via
the API shown in the above figures. Such an API can be defined in an
implementation. But when the GCKS is physically separate from the
SRTP source, GDOI has no over-the-wire protocol for collecting the
SSRC, ROC and SEQ information from the source. The Encrypted Key
Transport (EKT) protocol solves this problem.
EKT extends SRTCP to securely provide the SSRC, ROC and the SEQ from
the SRTP source to the SRTP receiver, and EKT correctly initializes
the SSRC, ROC and SEQ for late joiners to the multicast group or
following RTP SSRC collision repair [I-D.mcgrew-srtp-ekt]. In a
centralized GCKS configuration (Fig 2.0-1), EKT is RECOMMENDED in
this document for transporting an SRTP sender's SSRC, ROC and SEQ to
SRTP receivers. In a distributed GCKS configuration, it is possible
for the GCKS to correctly initialize the SSRC, ROC and SEQ by
obtaining these values through an API with the GDOI member; in this
case, it is RECOMMENDED that GDOI peform this function. When the
GCKS provides current SSRC, ROC and SEQ values, these are carried in
GDOI-SRTP SA-TEK payload and the GDOI Key Download payload carries
the SRTP master key and salt. When EKT is used instead, the GDOI Key
Download payload carries the EKT key.
Whether or not to use EKT or to provide SRTP SSRC, ROC and SEQ
parameters via GDOI SHALL be a configurable option in GDOI-SRTP.
When the EKT option is not used, the SRTP receiver can begin
validating and decrypting packets without waiting for an EKT message
to arrive in the SRTCP session. EKT is needed, however, when the
GCKS cannot reliably initialize the SA-TEK with SSRC, ROC and SEQ
fields.
When EKT is used, there are two SA-TEK payloads. First, there is an
SRTP SA-TEK payload that describes an SRTP master key and salt; the
SRTP SA-TEK is always present. Second, there is an EKT SA-TEK
payload that describes an EKT key. In either case, there is exactly
one Key Download payload sent in a GDOI-SRTP exchange. If EKT is
signaled by the presence of an EKT SA-TEK, then the Key Download
payload SHALL carry an EKT key. If EKT is not signaled, then the KEY
Download payload SHALL carry an SRTP master key and master salt. In
either case, there MUST be exactly one Key Download payload when
signaling SRTP in GDOI.
2.2. GDOI Exchanges for SRTP
As mentioned above, GDOI exchanges for SRTP are protected by a "phase
1 security association", which is an IKE phase 1 connection in which
the GCKS and the member identify and authenticate each other. For
the IKE phase 1, RFC 3547 allows any defined IKE identity such as IP
address, fully-qualified domain name or an opaque byte string that
Baugher, et al. Expires August 24, 2007 [Page 7]
Internet-Draft GDOI-SRTP February 2007
identifies a pre-shared key[ISAKMP-REG]. Also, any of the IKE
authentication methods MAY be used including pre-shared key, public-
key encryption, and digitial signatures. The IKE phase 1 connection
is established using a six-message "Main Mode" exchange if identity
protection is desired or a 3-message "Aggressive Mode" if identity
protection is not needed [RFC2409]. With identity protection, a
passive attack will not reveal the identities that the initiator or
responder use to authenticate themselves.
In GDOI, the initiator is usually the group member and the responder
is usually the Group Controller/Key Server. This is true in both the
phase 1 and phase 2 exchanges. The phase 2 exchange uses a 4-message
exchange as defined in RFC 3547, Section 3 [RFC3547] and is
reproduced below for the convenience of the reader.
Figure 2.2-1: GDOI Phase 2 Exchange, from Section 3.2 [RFC3547]
Initiator (Member) Responder (GCKS)
------------------ ----------------
HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I] -->
[,CERT] [,POP_I]
<-- HDR*, HASH(4),[KE_R,][SEQ,]
KD [,CERT] [,POP_R]
* Protected by the Phase 1 SA, encryption occurs after HDR
When sent to the GDOI port, the message header (HDR) of Fig. 2.2-1
identifies the phase 2 exchange, i.e. by the ISAKMP message id (M-ID)
field of HDR. Everything else is encrypted using the phase 1
encryption key and authenticated in the HASH payloads that appear in
each message. A nonce and an ID are sent in the first message from
the member to the GCKS, which responds by downloading the
cryptographic parameters, session parameters, authentication policy
and other information that the member needs to identify and
authenticate itself to the GCKS. The GCKS provides these parameters
and policy information in the Security-Association (SA) payload of
the second message along with its nonce, Nr. As described in the
previous section of this document, how these policies and parameters
are defined is out of scope for this document. The successful GDOI-
SRTP exchange establishes an SRTP cryptographic context (i.e. a
security association among SRTP endpoints).
The third message of Fig 2.2-1 is from the member to the GCKS. If
perfect forward secrecy is desired, Diffie-Hellman public value are
exchanged in the Key-Exchange (KE) payloads (KE_I and KE_R), which
Baugher, et al. Expires August 24, 2007 [Page 8]
Internet-Draft GDOI-SRTP February 2007
are optional. If additional authorization and authentication are
desired beyond the IKE Phase 1, then a digital certificate can be
passed in a Cerficate (CERT) payload with an optional proof-of-
possession exchange to prove possession of the corresponding private
key (POP_I and POP_R).
The fourth and final message concludes a successful GDOI phase 2
exchange by passing a Key-Download (KD) payload. Any KE, CERT or POP
exchanges are completed in the final message. Another optional field
is SEQ, which is the sequence number associated with messages that
are sent (pushed) from the GCKS to the member. For pushed messages,
the SA payload will include a GDOI key-encrypting key (KEK)
definition in an SA-KEK payload. A GDOI group will not use pushed
messages if it does not need to perform key update of the SRTP Master
Key (SA-TEK) or member revocation. Thus, an SA-KEK is OPTIONAL
whereas one or two SA-TEKs are REQUIRED by this document; these are
the SRTP SA-TEK and the optional EKT SA-TEK. The SA-KEK and SA-TEK
are part of the SA payload shown in Figure 2.2-1.
2.3. SRTP SA-TEK Definitions
The RFC 3547 SA TEK payload has a header and a protocol-specific
payload. The SRTP SA TEK is identified by the GDOI_PROTO_SRTP value
(assigned by IANA) in the Protocol-ID field of the SA TEK header,
which is defined in Section 5.4 of RFC 3547 [RFC3547]. The SA TEK
protocol-specific payload for SRTP is given in Figure 2.2-1. The SAT
Payload fields are shown in Figure 2.3-1.
Baugher, et al. Expires August 24, 2007 [Page 9]
Internet-Draft GDOI-SRTP February 2007
Figure 2.3-1: SRTP SA-TEK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SRC ID Type ! SRC ID Port !SRC ID Date Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Replay Window ! KD Rate ! SRTP Lifetime ! SRTCP Lifetime!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Options ! Crypto Suite ! SPI ! Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Attribute Class Value Type
--------------- ----- ----
RESERVED 0
SSRC 1 B
ROC 2 B
SEQ 3 B
MKI 4 V
The Group Controller/Key Server (GCKS) provides SA-TEK and Key-
Download payload information to an SRTP implementation through the
GDOI member to SRTP, which uses this information to initialize the
cryptographic context of an SRTP session. An SRTP crypto context is
identified by the SSRC and RTP destination transport address as
explained in Section 8 of the SRTP specification [RFC3711]. The RTP
destination address is identified in the SA-TEK, which is shown in
Figure 2.3-1. The "DST ID Type" defines the type of DST
Identification data, which is an IP address or a fully-qualified
domain name that resolves to one. The destination port is also
carried in the DST ID Port, also shown in Figure 2.3-1 following the
similar definitions for the source.
Replay window, key-derivation (KD) rate, SRTP and SRTCP lifetimes are
the crypto context parameters for the particular SRTP session. Also
shown in Figure 2.3-1 is the options field, that declares values for
boolean SRTP configuration parameters and also whether EKT is to be
used or not. Crypto Suite identifies the SRTP encryption and
authentication transforms. GDOI-SRTP uses the same encryption and
authentication transforms for SRTP and SRTCP. Finally, the SPI is
the "security parameter index", which identifies the particular
Baugher, et al. Expires August 24, 2007 [Page 10]
Internet-Draft GDOI-SRTP February 2007
security association (SRTP crypto context) by a 8-bit number, a
positive integer.
The Attributes payloads are optional. The attributes must follow the
format defined in ISAKMP [RFC3547] section 3.3. In the table,
attributes that are defined as TV are marked as Basic (B); attributes
that are defined as TLV are marked as Variable (V). The SSRC,
rollover counter (ROC) and current sequence number (SEQ) MAY be
carried in the SA TEK payload that is shown in Figure 2.3-1. When
the SSRC, ROC and the SEQ are not carried in the SRTP SA-TEK payload,
the EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt]. EKT is
signaled in the options field described above. If EKT is signaled in
Options, then the SSRC, ROC and SEQ Attributes MUST be ignored. If
EKT is not signaled in Options, the the SSRC, ROC and SEQ MUST be
present.
Each of the fields of Figure 2.3-1 is defined as follows.
o SRC ID Type (1 octet) -- Value describing the identity information
found in the SRC Identification Data field. Defined values are
specified by the IPSEC Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG].
o SRC ID Port (2 octets) -- Value specifying a port associated with
the SRC Identification data. A value of zero means that the SRC
ID Port field should be ignored.
o SRC ID Data Len (1 octet) -- Value specifying the length of the
SRC Identification Data field.
o SRC Identification Data (variable length) -- Value as indicated by
the SRC ID Type. According to RFC 3547, SRC Identification Data
consists of three bytes of zero for multiple-source multicast
groups that use a common TEK for all senders. The TEK in an SRTP
Key Download payload is an SRTP master key, however, and it is NOT
RECOMMENDED that this key be shared for the counter mode and f8
ciphers of SRTP. Thus, it is NOT RECOMMENDED that this field
consist of three bytes of zero. It SHOULD be ID_FQDN (see the
"NAT Considerations" section).
o DST ID Type (1 octet) -- Value describing the identity information
found in the DST Identification Data field. Defined values are
specified by the IPSEC Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG].
o DST ID Port (2 octets) -- Value specifying a port associated with
the source Id. A value of zero means that the DST ID Port field
should be ignored.
Baugher, et al. Expires August 24, 2007 [Page 11]
Internet-Draft GDOI-SRTP February 2007
o DST ID Data Len (1 octet) -- Value specifying the length of the
DST Identification Data field.
o DST Identification Data (variable length) -- Value, as indicated
by the DST ID Type.
o Replay Window Size (1 octet) - The size of the SRTP Replay Window
as specified in Section 3.3.2 of the SRTP standard [RFC3711].
o KD Rate (1 octet) - SRTP Key Derivation Rate as specified in
Section 4.3.1, second paragraph of the standard [RFC3711]. KD
Rate is an integer that is greater than or equal to zero. The
SRTP "packet index" of an outgoing or incoming SRTP packet is
computed modulo the KD Rate in cases where the KD Rate is greater
than zero. The reader is referred to Sections 3.3.1 and 4.3.1 of
the SRTP specification for the definitions of "packet index" and
"Key Derivation Rate".
o SRTP Lifetime (1 octet) - The SRTP key lifetime is encoded as an
integer N to represent a lifetime of 2^N packets, where N cannot
exceed the maximum lifetime as specified by the Crypto Suite. A
value of zero signals the SRTP default (N=48).
o SRTCP Lifetime (1 octet) - The SRTCP key lifetime is encoded as an
integer N to represent a lifetime of 2^N packets, where N cannot
exceed the maximum lifetime as specified by the Crypto Suite. A
value of zero signals the SRTP default (N=31).
o Options (1 octet) - Reading from left to right (big-endian), SRTP
is unencrypted when bit 0 is set to '1'. SRTP is unauthenticated
when bit 1 is set to '1'. SRTCP is unencrypted when bit 2 is set
to '1'. EKT is not used when bit 3 is set to '1'. The SSRC, ROC
and SEQ are not included and MUST be ignored when bit 4 is set to
'1'.
o SSRC (2 octets) - Value of the Sender's SSRC when there is a
single sender associated with the KEK and TEK signaled in the SA-
TEK and Key Download payload.
o Crypto Suite (1 octet) -- The set of parameters that defines the
SRTP and SRTCP encryption transform, authentication transform, key
length, and salt length. The values are defined in the Table
2.1-2. Each row in the table defines a suite of parameters. Any
parameter can be changed and new parameters added by creating a
new Crypto Suite, documenting it in an Internet RFC, and
requesting a Suite Value for it from IANA.
Baugher, et al. Expires August 24, 2007 [Page 12]
Internet-Draft GDOI-SRTP February 2007
Table 2.1-2: SRTP Crypto Suites
Suite Master Master Max SRTP Max SRTCP
Value Cipher Keylen Saltlen Lifetime Lifetime MAC/len
----- ------ ------ ------- -------- -------- -------
0 AES-CM 128 112 2^48 2^31 HMAC-SHA1/80
1 AES-CM 128 112 2^48 2^31 HMAC-SHA1/32
2 AES-F8 128 112 2^48 2^31 HMAC-SHA1/80
3 AES-CM 192 112 2^48 2^31 HMAC-SHA1/80
4 AES-CM 192 112 2^48 2^31 HMAC-SHA1/32
5 AES-CM 256 112 2^48 2^31 HMAC-SHA1/80
6 AES-CM 256 112 2^48 2^31 HMAC-SHA1/32
7-127 RESERVED
Note: All keylen values are in bits
The key values of 192 and 256 are specified in the "BIG AES"
Internet Draft document [I-D.mcgrew-srtp-big-aes]. In the vast
majority of SRTP applications, the BIG AES values SHOULD NOT be
used since they do not increase security as a practical matter but
could diminish interoperability, see Section 7 of the Big AES I-D.
o SPI (2 octets) - The value of the security parameter index that
identifies this security association between the GCKS and the
group member.
o SSRC (1 octet) - The value of the SRTP SSRC; this attribute MUST
be present when bit 4 of Options is set to '1' but MUST be ignored
otherwise.
o ROC (4 octets) - The current value of the SRTP rollover counter
(ROC); this attribute value MUST be present when bit 4 of Options
is set to '1' but MUST be ignored otherwise.
o SEQ (2 octets) - The current value of the SRTP sequence number;
this attribute MUST be present when bit 4 of Options is set to '0'
but MUST be ignored otherwise.
o MKI (variable) - An SRTP Master Key Indicator (MKI) SHALL appear
in SRTP packets when this attribute is present. As defined in
Section 3 of RFC 3711 [RFC3711], the maximum MKI length is 128
(bytes) though a smaller length of one or two bytes IS
RECOMMENDED. The MKI Length attribute MUST be present when an MKI
attribute is given.
Baugher, et al. Expires August 24, 2007 [Page 13]
Internet-Draft GDOI-SRTP February 2007
2.4. EKT SA-TEK Definitions
EKT is an abbreviation for "encrypted key transport", which carries
an SRTP master key, SEQ and ROC in an SRTCP packet. As described
above, these values are generated internally to SRTP, and a central
GCKS typically cannot obtain these values and the SSRC when it has no
interface to the SRTP sender. In this case, EKT is RECOMMENDED as a
means to correctly initialize an SRTP receiver with the SSRC, SEQ,
ROC and SRTP master key. In this case, GDOI-SRTP serves to
initialize the EKT system in a GDOI member by providing EKT
parameters and a key called the "EKT key", which is used to encrypt
the SRTP master key in the SRTCP packet. Thus, the security
association between the GCKS and GDOI member establishes and
maintains an EKT key.
The EKT identifying information and parameters are shown in Figure
2.4-1.
Figure 2.4-1: EKT-TEK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! EKT Cipher ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the fields of Figure 2.3-1 is defined as follows.
o DST ID Type (1 octet) -- Value describing the identity information
found in the DST Identification Data field. Defined values are
specified by the IPSEC Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG].
o DST ID Port (2 octets) -- Value specifying a port associated with
the source Id. A value of zero means that the DST ID Port field
should be ignored.
o DST ID Data Len (1 octet) -- Value specifying the length of the
DST Identification Data field.
o DST Identification Data (variable length) -- Value, as indicated
by the DST ID Type.
Baugher, et al. Expires August 24, 2007 [Page 14]
Internet-Draft GDOI-SRTP February 2007
o EKT Cipher (1 octet) - Value specifying the cipher and mode used
by EKT for the EKT key, which is carried in a GDOI Key Download
payload. The following table correlates each EKT Cipher Suite
[I-D.mcgrew-srtp-ekt] with a Suite Value. New EKT Cipher Suites
MAY be added when documented by an Internet RFC and once IANA
assigns a Suite Value to that Cipher Suite.
Table 2.1-3: EKT Cipher Suites
EKT Cipher Suite
Suite Value
------ -----
RESERVED 0
AES_128 1
AESKW_128 2
AESKW_196 3
AESKW_256 4
RESERVED 5-127
o EKT SPI (1 octet) - The EKT security parameter index, which
identifies the EKT security association between the GCKS and the
GDOI member.
2.5. SRTP Key Download
The SRTP SA-TEK Crypto Suite of Table 2.3-1 defines two keys, the
SRTP master key and master salt key. These two keys are concatenated
with the SRTP master key followed by the SRTP master salt in a Key
Download (KD) payload's TEK_ALGORITHM_KEY attribute.
When EKT is used, there is no KD payload corresponding to the SRTP
SA-TEK. Instead, the KD payload carries the EKT key as defined by
the EKT SA-TEK EKT Cipher.
Baugher, et al. Expires August 24, 2007 [Page 15]
Internet-Draft GDOI-SRTP February 2007
3. NAT Considerations
Transport addresses are carried in the SA-TEK payloads and this
contradicts recommendations for application-layer signaling through
network address translators (NATs) [RFC2663][RFC3235]. The SA-TEK
destination IP address and port, however, are multicast addresses
which are not re-written by a NAT. The source address, however,
might be re-written on outgoing multicast packets
[I-D.wing-behave-multicast].
If the SA TEK SRC ID type of Figure 2.3-1 is an IP address and if
there is an outgoing NAT that re-writes the source IP address field
of outgoing packets, then there will likely be a discrepancy between
the source address in the IP packet and the SRC Identification Data
field of Figure 2.3-1. It is therefore RECOMMENDED that SRC ID Type
be ID_FQDN [ISAKMP-REG] whenever there is network address translation
present on the network of the multicast source.
Baugher, et al. Expires August 24, 2007 [Page 16]
Internet-Draft GDOI-SRTP February 2007
4. Security Considerations
The security of GDOI and its payloads is discussed in Section 6 of
the GDOI specification [RFC3547]. The security of SRTP and its
parameter settings is discussed in Section 9 of the SRTP
specification[RFC3711]. There are some additional risks in GDOI and
SRTP that are considered here.
4.1. No Sharing Counter-Mode Encryption Keys
One risk is the proper establishment of the SRTP SSRC, which is
subject to SSRC collisions that might be exploited by an attacker.
SRTP specifies that the SSRC is used in the AES counter mode and f8
initialization vectors (IV) to prevent counter reuse. RFC 3711
states that key management "SHOULD" install a unique SSRC. GDOI
relaxes this requirement since SSRCs collide. It is also difficult
to support an unchanged RTP module in a "bump-in-the-stack" SRTP
configuration. Instead of depending on SSRC uniqueness, IT IS
RECOMMENDED that the GDOI SA-TEK SHOULD provide a unique SRTP master
key for each sender.
To ensure SRTP master key uniqueness among senders to an SRTP
session, SA-TEK SRC Identification Data (Figure 2.1.1) MUST NOT
signal a group of senders sharing a key. GDOI specifies a means for
sharing a traffic encrypting key (TEK) among senders, but a GDOI TEK
is an SRTP master key and this specification RECOMMENDS that a TEK
SHOULD NOT be shared among SRTP sources.
4.2. Enable Distributed Key Management
In many cases, SRTP sources are not co-located with a GCKS. This is
one possible configuration in a large scale "video pump", for
example, that is specialized to a purpose other than key management.
If there are geographically-dispersed video-pump sources, there is
the risk that the GCKS will be attacked and its ability to
disseminate source-unique values to such as the ROC to the multicast
group will be impaired. This is one possible attack out of many
where a central GCKS can disrupt the entire multicast group of SRTP
receivers. This document RECOMMENDS the use of EKT to securely
distribute the SSRC, ROC and SEQ. GDOI-SRTP payloads signal the EKT
Key.
Two protocols have more vulnerabilities than one, however, and there
are added risks that come from using both GDOI and EKT. A
programming bug in GDOI (e.g. signaling zeros in SA-TEK SRC
Identification Data), for example, might cause an attack on EKT (e.g.
a distributed denial of service attack on a group of EKT receivers).
In some cases, a feature that is useful for M:N groups might be risky
Baugher, et al. Expires August 24, 2007 [Page 17]
Internet-Draft GDOI-SRTP February 2007
when used in 1:N groups. For these reasons, the GDOI-SRTP SA-TEK
SHOULD explicitly signal each source and provides a source TEK (SRTP
Master Key) as well as a KEK (EKT Key). In extraordinary cases such
as SSRC collision, the SSRC and SRTP master key MAY come from EKT,
but in normal operation only the SEQ and ROC SHOULD be obtained from
EKT.
4.3. Support Strong Source Authentication
Despite the precautions described above, there is always the
possibility of "source spoofing" when any member of the group
authorized only to receive can impersonate an authorized sender.
This is a limitation in symmetric-key authentication in secure
groups. To address this problem, SRTP can use TESLA source
authentication messaging [RFC4383]. A future revision of this
document will consider TESLA signaling.
Baugher, et al. Expires August 24, 2007 [Page 18]
Internet-Draft GDOI-SRTP February 2007
5. IANA Considerations
IANA is requested to register "GDOI_PROTO_SRTP" with a new value and
that additional values be added to the Security Association Traffic
Encrypting Key payload definitions, "SA TEK Payload Values"
[GDOI-REG], as follows.
1. Table 2.1-2: SRTP Crypto Suites.
2. Table 2.1-3: EKT Cipher Suites
Baugher, et al. Expires August 24, 2007 [Page 19]
Internet-Draft GDOI-SRTP February 2007
6. Acknowledgements
The authors thank David McGrew, Brian Weis and Liu Ya for their
helpful comments.
Baugher, et al. Expires August 24, 2007 [Page 20]
Internet-Draft GDOI-SRTP February 2007
7. References
7.1. Normative References
[GDOI-REG]
"Group Domain of Interpretation (GDOI) Payloads - per
[RFC3547], http://www.iana.org/assignments/gdoi-payloads",
2003.
[I-D.mcgrew-srtp-big-aes]
McGrew, D., "The use of AES-192 and AES-256 in Secure
RTP", draft-mcgrew-srtp-big-aes-00 (work in progress),
April 2006.
[I-D.mcgrew-srtp-ekt]
McGrew, D., "Encrypted Key Transport for Secure RTP",
draft-mcgrew-srtp-ekt-01 (work in progress), June 2006.
[ISAKMP-REG]
"FROM RFC 2407 and RFC 2408 Magic Numbers for ISAKMP
Protocol,
http://www.iana.org/assignments/isakmp-registry",
September 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
February 2006.
Baugher, et al. Expires August 24, 2007 [Page 21]
Internet-Draft GDOI-SRTP February 2007
7.2. Informative References
[I-D.wing-behave-multicast]
Wing, D., "IGMP Proxy Behavior",
draft-wing-behave-multicast-00 (work in progress),
October 2004.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
Baugher, et al. Expires August 24, 2007 [Page 22]
Internet-Draft GDOI-SRTP February 2007
Authors' Addresses
Mark Baugher
Cisco Systems, Inc.
800 East Tasman Drive
San Jose, CA 95164
US
Phone: (503) 245-4543
Email: mbaugher@cisco.com
Adrian-Ken Rueegsegger
secunet SwissIT AG
Hauptbahnhofstrasse 12
4501 Solothurn,
Switzerland
Phone: +41 32 625 80 40
Email: rueegsegger@swiss-it.ch
Sheela Rowles
Cisco Systems, Inc.
1700 West Tasman Drive
San Jose, CA 95134-1706
US
Phone: (408) 527-7677
Email: srowles@cisco.com
Baugher, et al. Expires August 24, 2007 [Page 23]
Internet-Draft GDOI-SRTP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Baugher, et al. Expires August 24, 2007 [Page 24]