Network Working Group M. Baugher
Internet-Draft Cisco Systems, Inc.
Expires: April 17, 2007 A. Rueegsegger
October 14, 2006
GDOI Key Establishment for the SRTP Data Security Protocol
draft-baugher-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 April 17, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Secure Real-time Transport Protocol (SRTP) secures unicast and
multicast media streams. Multicast receivers of an SRTP stream
therefore share an SRTP master key for multicast 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.
Baugher & Rueegsegger Expires April 17, 2007 [Page 1]
Internet-Draft GDOI-SRTP October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of This Document . . . . . . . . . . . . . . . . 3
1.2. Conformance Language . . . . . . . . . . . . . . . . . . . 3
2. SRTP Definitions for GDOI Signaling . . . . . . . . . . . . . 4
2.1. GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. SRTP SA-TEK Definitions . . . . . . . . . . . . . . . . . 6
2.3. SRTP Key Download . . . . . . . . . . . . . . . . . . . . 10
3. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4.1. No Sharing Counter-Mode Encryption Keys . . . . . . . . . 12
4.2. Enable Distributed Key Management . . . . . . . . . . . . 12
4.3. Support Strong Source Authentication . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Baugher & Rueegsegger Expires April 17, 2007 [Page 2]
Internet-Draft GDOI-SRTP October 2006
1. Introduction
The Group Domain of Interpretation (GDOI) is specified in 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. GDOI uses both unicast and multicast key
establishment, and can support messaging for member revocation
algorithms, such as the "key hierarchy" algorithm [RFC2627]. GDOI
preserves the ISAKMP design, which supports new data security
protocols through documented procedures. GDOI currently supports
only one data security protocol, IPsec.
This document presents GDOI payloads for another data security
protocol, the Secure Real-time Transport Protocol (SRTP). These
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]. GDOI carries keys, parameters, and
other values needed for an SRTP session's "cryptographic context",
which is described in Section 8 of the SRTP specification [RFC3711].
The GDOI-SRTP payloads MAY signal use of the EKT protocol as an
option for secure dissemination of internally-generated SRTP
parameters [I-D.mcgrew-srtp-ekt]. These options, parameters and keys
are contained in two GDOI payloads, the "Key Download" (KD) and the
"Security Association Traffic Encrypting Key" (SA-TEK) payloads.
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 has
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 & Rueegsegger Expires April 17, 2007 [Page 3]
Internet-Draft GDOI-SRTP October 2006
2. SRTP Definitions for GDOI Signaling
An application can use GDOI to establish security associations for a
data security protocol when GDOI is extended with one or more
payloads for that data security protocol. Payloads are carried in
GDOI message exchanges between a GDOI Group Controller/Key Server
(GCKS) and a GDOI member, as shown in Figure 2.0-1.
Figure 2.0-1: GDOI and SRTP Interfaces
+-------+
| GDOI |
| GCKS |
+-------+
^
|
V
+--------------------------+
| GDOI with SRTP payloads |
V V
+--------+ +--------+
| GDOI | | GDOI |
| Member | | Member |
+--------+ +--------+
^ ^
| |
API API
| |
V V
+--------+ SRTP/SRTCP +--------+
| SRTP |---------------->| SRTP |
| Source |<----------------|Receiver|
+--------+ SRTCP +--------+
This section specifies 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. Using the API, SRTP or another
application requests that GDOI establish an SRTP cryptographic
context (a "security association" in GDOI parlance), 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 with extending the GDOI protocol with a new payload.
Using this protocol extension, the GDOI Group Controller/Key Server
(GCKS) provides the cryptographic keys, policies and other attributes
to SRTP (via the API to a GDOI Member). The GCKS might obtain some
of this information through a user console or event database, and it
Baugher & Rueegsegger Expires April 17, 2007 [Page 4]
Internet-Draft GDOI-SRTP October 2006
generates some information automatically, such as keying materials.
How the GCKS obtains or generates information for the SRTP payload
fields is not considered further in this document.
Figure 2.0-2: GDOI GCKS Co-located with GDOI Member
+--------+
| GDOI | GDOI with +--------+
| GCKS & |<--------------->| GDOI |
| Member | SRTP payloads | Member |
+--------+ +--------+
^ ^
| |
API API
| |
V V
+--------+ SRTP/SRTCP +--------+
| SRTP |---------------->| SRTP |
| Source |<----------------|Receiver|
+--------+ SRTCP +--------+
Figure 2.0-1 is a logical diagram. In a physical realization of the
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 efficient for the GCKS to be
physically co-located in the same computer as the SRTP source of the
multicast stream.
2.1. GDOI and EKT
It is not always possible for GCKS to obtain all the needed SRTP
information. In order to establish an SRTP session, an SRTP system
requires some internally-generated SRTP information along with keys.
This information is the SSRC, the rollover counter (ROC), and the
sequence number (SEQ). The ROC and SEQ are used by the SRTP ciphers,
and they are used in SRTP replay protection; the SSRC is used in
combination with the destination transport address to identify an RTP
session [RFC3550] and thus an SRTP session's crypto context. The SEQ
and ROC values are generated internally by the SRTP source. When the
GCKS is co-located with the GDOI Member and the SRTP source, however,
this information can be obtained via the API shown in the above
figures. But when the GCKS is physically separate from the SRTP
source, GDOI has no over-the-wire protocol for collecting such SSRC,
ROC and SEQ information from a multicast source.
Baugher & Rueegsegger Expires April 17, 2007 [Page 5]
Internet-Draft GDOI-SRTP October 2006
The EKT protocol offers a solution to the problem of securely
providing 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 or following RTP SSRC collision repair
[I-D.mcgrew-srtp-ekt]. EKT is RECOMMENDED in this document for
transport of an SRTP sender's SSRC, ROC and SEQ to SRTP receivers.
When it is possible for the GCKS to correctly initialize the SSRC,
ROC and SEQ, however, it is RECOMMENDED that the Key Download also
carry the SRTP master key and salt as this will allow the SRTP
receiver to begin validating and decrypting packets without waiting
for an EKT message to arrive in the SRTCP. EKT is particularly
useful when the GCKS cannot reliably initialize the SA-TEK with SSRC,
ROC and SEQ fields. When EKT is used, the SA-TEK at minimum signals
EKT in the SA-TEK Options field and provides the EKT Key in a Key
Download payload.
2.2. SRTP SA-TEK Definitions
Figure 2.2-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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Options ! SSRC ! Crypto Suite !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Replay Window ! KD Rate ! SRTP Lifetime ! SRTCP Lifetime!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! ROC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SEQ ! MKI Length ! MKI (Optional)~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! EKT Cipher ! EKT SPI Length! EKT SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GDOI provides SA-TEK and Key-Download payload information to an SRTP
implementation, 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 SRTP
Baugher & Rueegsegger Expires April 17, 2007 [Page 6]
Internet-Draft GDOI-SRTP October 2006
rollover counter (ROC) and current sequence number (SEQ) MAY be
carried in the SA TEK payload that is shown in Figure 2.2-1. When
the ROC and the SEQ are not carried in the SRTP SA-TEK payload, the
EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt], in which case the
SA-TEK carries EKT information as shown in Figure 2.2-1. In either
case, GDOI-SRTP uses the same encryption and authentication
transforms for SRTP and SRTCP.
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
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 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.
o DST ID Data Len (1 octet) -- Value specifying the length of the
DST Identification Data field.
Baugher & Rueegsegger Expires April 17, 2007 [Page 7]
Internet-Draft GDOI-SRTP October 2006
o DST Identification Data (variable length) -- Value, as indicated
by the DST ID Type.
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 and signaled in 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.
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 Replay Window Size (1 octet) - The size of SRTP Replay Window as
specified in Section 3.3.2 of the 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
Baugher & Rueegsegger Expires April 17, 2007 [Page 8]
Internet-Draft GDOI-SRTP October 2006
Rate is an integer that is greater than or equal to zero. The
modulus of 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.
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.
o ROC (4 octets) - When bit 4 of Opions is cleared to '0', this
field contains the current value of the SRTP ROC.
o SEQ (2 octets) - When bit 4 of Options is cleared to '0', this
field contains the current SRTP SEQ.
o MKI Length (1 octet) - An SRTP Master Key Indicator (MKI) SHALL
appear in SRTP packets when this field is nonzero. The MKI field
is the length of the SRTP MKI 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.
o MKI (optional, variable length) - The SRTP MKI is present when the
SRTP MKI Length is nonzero. The value of the SRTP MKI Length
determines the number of bytes in the width of this field.
o EKT Cipher (1 octet) - When bit 3 of the SRTP Options field is
cleared to '0', EKT parameters appear in the SA TEK payload. "EKT
Cipher" is 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.
Baugher & Rueegsegger Expires April 17, 2007 [Page 9]
Internet-Draft GDOI-SRTP October 2006
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 Len (1 octet) - The length of the EKT SPI.
o EKT SPI (variable length) - The EKT SPI.
2.3. SRTP Key Download
The Crypto Suites of Table 2.1-2 define 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, EKT key is carried as a KEK_ALGORITHM_KEY
attribute.
Baugher & Rueegsegger Expires April 17, 2007 [Page 10]
Internet-Draft GDOI-SRTP October 2006
3. NAT Considerations
Transport addresses are carried in the SA-TEK payload and this
contradicts recommendations for application-layer signaling through
network address translators (NATs) [RFC2663][RFC3235]. The
destination IP address and port, however, are multicast addresses and
these 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.1-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.1-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 & Rueegsegger Expires April 17, 2007 [Page 11]
Internet-Draft GDOI-SRTP October 2006
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 to 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 and 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
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 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 & Rueegsegger Expires April 17, 2007 [Page 12]
Internet-Draft GDOI-SRTP October 2006
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 & Rueegsegger Expires April 17, 2007 [Page 13]
Internet-Draft GDOI-SRTP October 2006
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 & Rueegsegger Expires April 17, 2007 [Page 14]
Internet-Draft GDOI-SRTP October 2006
6. Acknowledgements
The authors thank David McGrew and Brian Weis for their helpful
comments.
Baugher & Rueegsegger Expires April 17, 2007 [Page 15]
Internet-Draft GDOI-SRTP October 2006
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.
[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 & Rueegsegger Expires April 17, 2007 [Page 16]
Internet-Draft GDOI-SRTP October 2006
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 & Rueegsegger Expires April 17, 2007 [Page 17]
Internet-Draft GDOI-SRTP October 2006
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
Bocksteinstrasse 2
4583 Muehledorf,
Switzerland
Phone: +41 32 661 10 88
Email: adrian.rueegsegger@students.fhnw.ch
Baugher & Rueegsegger Expires April 17, 2007 [Page 18]
Internet-Draft GDOI-SRTP October 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baugher & Rueegsegger Expires April 17, 2007 [Page 19]