draft-ietf-avtcore-srtp-aes-gcm-00.txt   draft-ietf-avtcore-srtp-aes-gcm-01.txt 
Network Working Group D. McGrew Network Working Group D. McGrew
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Intended Status: Informational K.M. Igoe Intended Status: Informational K.M. Igoe
Expires: August 20, 2012 National Security Agency Expires: December 27, 2012 National Security Agency
February 17, 2012 June 25, 2012
AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)
draft-ietf-avtcore-srtp-aes-gcm-00 draft-ietf-avtcore-srtp-aes-gcm-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current. Drafts is at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 20, 2012. This Internet-Draft will expire on December 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
This document defines how AES-GCM, AES-CCM, and other Authenticated This document defines how AES-GCM, AES-CCM, and other Authenticated
Encryption with Associated Data (AEAD) algorithms, can be used to Encryption with Associated Data (AEAD) algorithms can be used to
provide confidentiality and data authentication mechanisms in the provide confidentiality and data authentication mechanisms in the
SRTP protocol. SRTP protocol.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................3
1.1. Conventions Used In This Document...........................3 2. Conventions Used In This Document................................3
1.2. AEAD processing for SRTP....................................4 3. Overview of the SRTP/SRTCP Security Architecture.................4
1.2.1. AEAD versus SRTP/SRTCP Authentication..................5 4. Terminology......................................................4
1.2.2. Values used to form the Initialization Vector (IV).....6 5. Generic AEAD Processing..........................................5
1.3. SRTP IV formation for AES-GCM and AES-CCM...................6 5.1. Types of Input Data.........................................5
1.4. SRTCP IV formation for AES-GCM and AES-CCM..................7 5.2. AEAD Invocation Inputs and Outputs..........................5
1.5. AEAD Processing of SRTP Packets.............................8 5.2.1. Encrypt Mode...........................................5
1.6. AEAD Processing of SRTCP Packets............................8 5.2.2. Decrypt Mode...........................................6
1.6.1. Encrypted SRTCP packets................................9 5.3. Handling of AEAD Authentication.............................6
1.6.2. Unencrypted SRTCP packets.............................10 6. Counter Mode Encryption..........................................6
1.7. Initialization of the Counters.............................10 7. Unneeded SRTP/SRTCP Fields.......................................7
1.8. Prevention of IV Reuse.....................................11 7.1. SRTP/SRTCP Authentication Field.............................7
2. AEAD parameters for SRTP and SRTCP..............................11 7.2. RTP Padding.................................................7
2.1. Generic AEAD Parameter Constraints.........................11 8. AES-GCM/CCM processing for SRTP..................................7
2.2. AES-GCM for SRTP/SRTCP.....................................12 8.1. SRTP IV formation for AES-GCM and AES-CCM...................7
2.3. AES-CCM for SRTP/SRTCP.....................................13 8.2. Data Types in SRTP Packets..................................8
2.4. Key Derivation Functions...................................13 8.3. Prevention of SRTP IV Reuse.................................9
3. Security Considerations.........................................14 9. AES-GCM/CCM Processing of SRTCP Compound Packets................10
3.1. Handling of Security Critical Parameters...................14 9.1. SRTCP IV formation for AES-GCM and AES-CCM.................10
3.2. Size of the Authentication Tag.............................14 9.2. Data Types in Encrypted SRTCP Compound Packets.............10
4. IANA Considerations.............................................15 9.3. Data Types in Unencrypted SRTCP Compound Packets...........12
5. Acknowledgements................................................16 9.4. Prevention of SRTCP IV Reuse...............................13
6. References......................................................17 10. Constraints on AEAD for SRTP and SRTCP.........................13
6.1. Normative References.......................................17 10.1. Generic AEAD Parameter Constraints........................13
6.2. Informative References.....................................18 10.2. AES-GCM for SRTP/SRTCP....................................14
10.3. AES-CCM for SRTP/SRTCP....................................14
11. Key Derivation Functions.......................................15
12. Security Considerations........................................15
12.1. Handling of Security Critical Parameters..................15
12.2. Size of the Authentication Tag............................15
13. IANA Considerations............................................16
13.1. SDES......................................................16
13.2. DTLS......................................................17
13.3. MIKEY.....................................................19
14. Parameters for use with MIKEY..................................19
15. Acknowledgements...............................................20
16. References.....................................................21
16.1. Normative References......................................21
16.2. Informative References....................................22
1. Introduction 1. Introduction
The Secure Real-time Transport Protocol (SRTP) is a profile of the The Secure Real-time Transport Protocol (SRTP) is a profile of the
Real-time Transport Protocol (RTP), which can provide Real-time Transport Protocol (RTP), which can provide
confidentiality, message authentication, and replay protection to the confidentiality, message authentication, and replay protection to the
RTP traffic and to the control traffic for RTP, the Real-time RTP traffic and to the control traffic for RTP, the Real-time
Transport Control Protocol (RTCP). Transport Control Protocol (RTCP). It is important to note that the
outgoing SRTP packets from a single endpoint may be originating from
SRTP/SRTCP assumes that both the sender and recipient have a shared several independent data sources.
secret master key and a shared master salt. As described in sections
4.3.1 and 4.3.3 of [RFC3711], a Key Derivation Function is applied to
these values to obtain separate encryption keys, authentication keys
and salting keys for SRTP and for SRTCP. (Note: As will be explained
below, AEAD SRTP/SRTCP does not make use of these authentication
keys.)
Authenticated encryption [BN00] is a form of encryption that, in Authenticated encryption [BN00] is a form of encryption that, in
addition to providing confidentiality for the plaintext that is addition to providing confidentiality for the plaintext that is
encrypted, provides a way to check its integrity and authenticity. encrypted, provides a way to check its integrity and authenticity.
Authenticated Encryption with Associated Data, or AEAD [R02], adds Authenticated Encryption with Associated Data, or AEAD [R02], adds
the ability to check the integrity and authenticity of some the ability to check the integrity and authenticity of some
Associated Data (AD), also called "additional authenticated data", Associated Data (AD), also called "additional authenticated data",
that is not encrypted. This specification makes use of the interface that is not encrypted. This specification makes use of the interface
to a generic AEAD algorithm as defined in [RFC5116]. to a generic AEAD algorithm as defined in [RFC5116].
skipping to change at page 3, line 39 skipping to change at page 3, line 48
hardware, making it especially appealing for high-speed hardware, making it especially appealing for high-speed
implementations, or for implementations in an efficient and compact implementations, or for implementations in an efficient and compact
circuit. CCM is well suited for use in compact software circuit. CCM is well suited for use in compact software
implementations. This specification uses GCM and CCM with both implementations. This specification uses GCM and CCM with both
AES-128 and AES-256. AES-128 and AES-256.
In summary, this document defines how to use AEAD algorithms, In summary, this document defines how to use AEAD algorithms,
particularly AES-GCM and AES-CCM, to provide confidentiality and particularly AES-GCM and AES-CCM, to provide confidentiality and
message authentication within SRTP and SRTCP packets. message authentication within SRTP and SRTCP packets.
1.1. Conventions Used In This Document 2. 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 [RFC2119].
3. Overview of the SRTP/SRTCP Security Architecture
SRTP/SRTCP security is based upon the following principles:
a) Both privacy and authentication are based upon the use of
symmetric algorithms. An AEAD algorithm such as AES-CCM and
AES-GCM combines privacy and authentication into a single
process.
b) A secret master key is shared by all participating endpoints,
both those originating SRTP/SRTCP packets and those receiving
these packets. Any given master key MAY be used
simultaneously by several endpoints to originate SRTP/SRTCP
packets (as well one or more endpoints using this master key
to process inbound data).
c) A Key Derivation Function is applied to the shared master key
value to form separate encryption keys, authentication keys
and salting keys for SRTP and for SRTCP (a total of six
keys). This process is described in sections 4.3.1 and 4.3.3
of [RFC3711]. Since AEAD algorithms such as AES-CCM and
AES-GCM combine encryption and authentication into a single
process, AEAD algorithms do not make use of the
authentication keys. The master key MUST be at least as
large as the encryption key derived from it.
4. Terminology
The following terms have very specific meanings in the context of The following terms have very specific meanings in the context of
this RFC: this RFC:
Crypto Context For the purposes of this document a crypto context Crypto Context For the purposes of this document, a crypto
is the outcome of any process which results in context is the outcome of any process which
authentication of each participant in the SRTP results in authentication of each endpoint in the
session and possession by each partcipant of a SRTP session and possession by each endpoint of a
shared secret master key and a shared master shared secret master key. Various encryption
salt. Details of how the maser key and master keys, authentication keys and salts are derived
salt are established are outside the scope of this from the master key. Aside from making
document. Similarly any mechanism for rekeying an modifications to IANA registries to allow AES-GCM
existing Ciper Contest is outside the scope of the and AES-CCM to work with SDES, DTLS and MIKEY, the
document. The master key MUST be at least as details of how the master key is established are
large as the encryption key. The SRTP/SRTCP Key outside the scope of this document. Similarly any
Derivation Function (KDF) defined in [RFC3711] is mechanism for rekeying an existing Cipher Context
applied to the master key and master SALT to is outside the scope of the document.
derive the SRTP_encr_key, SRTCP_encr_key,
SRTP_SALT, and SRTCP_SALT. Authentication keys
are not used in AEAD.
Instantiation Once keys have been established, an instance of Instantiation In AEAD, an instantiation is an (Encryption_key,
the AEAD algorithm is created using the salt) pair together with all of the data
appropriate key and salt. In a point-to-point structures (for example, counters) needed for it
scenario, each participant in the SRTP/SRTCP to function properly. In SRTP/SRTCP, each
session will need four instantiations of the AEAD endpoint will need two instantiations of the AEAD
algorithm; one for inbound SRTP traffic, one for algorithm for each master key in its possession,
outbound SRTP traffic source, one for inbound one for SRTP and one for SRTCP.
SRTCP traffic, and one for outbound SRTCP traffic
source. See section 1.2 for details on what is
required of each instantiation.
Invocation SRTP/SRTCP data streams are broken into packets. Invocation SRTP/SRTCP data streams are broken into packets.
Each packet is processed by a single invocation of Each packet is processed by a single invocation of
the appropriate instantiation of the AEAD the appropriate instantiation of the AEAD
algorithm. algorithm.
Each AEAD instantiation has its own key, a 48-bit zero-based packet In many applications, each endpoint will have one master key for
counter that is incremented after that particular instantiation has processing outbound data but may have one or more separate master
been invoked to process an SRTP packet, and a 31-bit zero-based SRTCP keys for processing inbound data.
index that is incremented each time an SRTCP packet is processed. A
32-bit Block Counter is incremented each time a block of key is
produced and is reset (to zero for CCM and to one for GCM) at the
start of each packet. As we shall see in sections 1.3 and 1.4, the
packet counter and SRTCP counter play a crucial role in the formation
of each packet's IV.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 5. Generic AEAD Processing
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. AEAD processing for SRTP 5.1. Types of Input Data
We first define how to use a generic AEAD algorithm in SRTP, then we Associated Data This is data that is to be authenticated but
describe the specific use of the AES-128-GCM and AES-256-GCM not encrypted.
algorithms.
The use of an AEAD algorithm is defined by expressing the AEAD Plaintext Data that is to be both encrypted and
encryption algorithm inputs in terms of SRTP fields and data authenticated.
structures. The AEAD encryption inputs are as follows:
Key This input is the SRTP encryption key Raw Data Data that is to be neither encrypted nor
(SRTP_encr_key) produced from the shared authenticated.
secret master key using the key derivation
process. (Note that the SRTP_auth_key is
not used).
Associated Data This is data that is to be authenticated Which portions of SRTP/SRTCP packets that are to be treated as
but not encrypted. In SRTP, the associated associated data, which are to be treated as plaintext, and which are
data consists of the entire RTP header, to be treated as raw data are covered in sections 8.2, 9.2 and 9.3.
including the list of CSRC identifiers (if
present) and the RTP header extension (if
present), as shown in Figure 3.
Plaintext Data that is to be both encrypted and 5.2. AEAD Invocation Inputs and Outputs
authenticated. In SRTP this consists of
the RTP payload, the RTP padding and the
RTP pad count fields (if the latter two
fields are present) as shown in Figure 3.
The padding service provided by RTP is not
needed by the AEAD encryption algorithm, so
the RTP padding and RTP pad count fields
SHOULD be omitted.
Initialization Vector Each SRTP/SRTCP packet has its own 12-octet 5.2.1. Encrypt Mode
initialization vector (IV). Construction
of this IV is covered in more detail
below.
The AEAD encryption algorithm accepts these four inputs and returns a Inputs:
Ciphertext field. Encryption_key Octet string, either 16 or 32
octets long
Initialization_Vector Octet string, 12 octets long
Associated_Data Bit string of variable length
Plaintext Bit string of variable length
Tag_Size_Flag (CCM only*) One Octet
1.2.1. AEAD versus SRTP/SRTCP Authentication Outputs
Ciphertext Bit string, length =
length(ciphertext)-tag_length
The reader is reminded that in addition to providing confidentiality (*) For GCM, the algorithm choice determines the tag size.
for the plaintext that is encrypted, an AEAD algorithm also provides
a mechanism that allows the intended recipient to check the data AES-CCM uses a Tag_Size_Flag that has the hex value 5A if an 8-octet
integrity and authenticity of the plaintext and associated data. The authentication tag is used, 6A if a 12-octet authentication tag is
AEAD authentication tag is incorporated into the Ciphertext field by used, and 7A if a 16-octet authentication tag is used.
RFC 5116, thus AEAD does not make use of the SRTP/SRTCP
Authentication Tag fields defined in RFC 3711. (Note that this means 5.2.2. Decrypt Mode
that the cipher text will be longer than the plain text by precisely
the length of the AEAD authentication tag.) Inputs:
Encryption_key Octet string, either 16 or 32
octets long
Initialization_Vector octet string, 12 octets long
Associated_Data Bit string of variable length
Ciphertext Bit string of variable length
Tag_Size_Flag (CCM only*) One Octet
Outputs
Plaintext Bit string, length =
length(ciphertext)-tag_length
Validity_Flag Boolean, TRUE if valid,
FALSE otherwise
(*) For GCM, the algorithm choice determines the tag size.
AES-CCM uses a Tag_Size_Flag that has the hex value 5A if an 8-octet
authentication tag is used, 6A if a 12-octet authentication tag is
used, and 7A if a 16-octet authentication tag is used.
5.3. Handling of AEAD Authentication
AEAD requires that all incoming packets MUST pass AEAD authentication
before any other action takes place. The ciphertext MUST NOT be
decrypted until the AEAD tag has been validated. The associated data
MUST NOT be released until the AEAD tag has been validated.
Should the AEAD tag prove to be invalid, the incoming data is to be
discarded and appropriate error flags raised. Local policy
determines how these flags are to be handled and are outside the
scope of this document.
6. Counter Mode Encryption
Each outbound packet uses a 12 octet IV and encryption key to form a
keystream of bits which is XORed to the plaintext to form cipher.
Using the 12-octet IV and a 4-octet block counter, the keystream is
formed in 16-octet blocks until it is at least as long as the
plaintext, and any excess keystream bits are discarded. At the start
of each packet, the block counter is initialized to 0x0000 for
AES-CCM and to 0x0001 for AES-GCM. A key block is formed by
key_block = AES_ENC( IV || block_counter; key=Encryption_key )
and the block counter is incremented. This allows for a per packet
keystream of length of up to 2^36 octets for AES-CCM and up to
2^36-16 octets for AES-GCM.
With any counter mode, if the same (IV, Encryption_key) pair is used
twice, precisely the same keystream is formed. As explained in
section 9.1 of RFC 3711, this is a cryptographic disaster. For
AES-GCM, the consequences of such a reuse are even worse than
explained in RFC 3711 because it would completely compromise the
AES-GCM authentication mechanism.
7. Unneeded SRTP/SRTCP Fields
AEAD counter mode encryption removes the need for certain existing
SRTP/SRTCP mechanisms.
7.1. SRTP/SRTCP Authentication Field
The AEAD message authentication mechanism MUST be the primary message The AEAD message authentication mechanism MUST be the primary message
authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP
authentication mechanisms SHOULD NOT be used with any AEAD algorithm authentication mechanisms SHOULD NOT be used with any AEAD algorithm
and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED
and SHOULD NOT be present. Note that this contradicts section 3.4 of and SHOULD NOT be present. Note that this contradicts section 3.4 of
[RFC3711] which makes the use of the SRTCP Authentication field [RFC3711] which makes the use of the SRTCP Authentication field
mandatory, but the presence of the AEAD authentication renders the mandatory, but the presence of the AEAD authentication renders the
older authentication methods redundant. older authentication methods redundant.
Rationale. Some applications use the SRTP/SRTCP Authentication Rationale. Some applications use the SRTP/SRTCP Authentication
Tag as a means of conveying additional information, notably Tag as a means of conveying additional information, notably
[RFC4771]. This document retains the Authentication Tag field [RFC4771]. This document retains the Authentication Tag field
primarily to preserve compatibility with these applications. primarily to preserve compatibility with these applications.
1.2.2. Values used to form the Initialization Vector (IV) 7.2. RTP Padding
The initialization vector for an SRTP packet is formed from the:
SSRC The 4-octet Synchronization Source identifier
(SSRC), found in the RTP header.
Packet Counter Each AEAD instantiation MUST maintain a 6 octet
zero-based packet counter which is incremented
each time an SRTP packet is sent. As we shall
see below, the packet counter is used to insure
each SRTP packet gets a unique initialization
vector.
Sequence Number The 2-octet RTP Sequence Number (SEQ), found in
the RTP header. The SEQ is just the 16 least
significant bits of the packet counter.
Rollover Counter A 4-octet Rollover Counter (ROC), maintained
independently by both sides of the link,
incremented each time the Sequence Number cycles
back to 0. The ROC is just the 32 most
significant bits of the Packet Counter.
SRTCP index The SRTCP index is a 31-bit counter that plays
the same role for SRTCP packets that the Packet
Counter does for SRTP packets. Unlike the
Packet Counter, the SRTCP index is explicitly
included in each STRCP packet. The sender MUST
increment the SRTCP index by one after each SRTP
packet is sent.
SALT A 12-octet SRTP session encryption salt produced Neither AES-GCM not AES-CCM requires that the data be padded out to a
by the SRTP Key Derivation Function (KDF) (see specific block size, reducing the need to ude the padding mechanism
section 2.4). provided by RTP. It is RECOMENDED that the RTP padding mechanism not
be used unless it is necessary to disguise the length of the
underlying plaintext.
The reader is reminded that both SRTP and SRTCP allow packets to 8. AES-GCM/CCM processing for SRTP
arrive out of order, presenting the receiver with a synchronization
problem. The 31-bit SRTCP index is contained in the unencrypted (but
authenticated) portion of the SRTCP header, allowing the recipient to
read the SRTCP index directly from the header. But only the low 16
bits of the SRTP Packet counter are contained in the SRTP header (in
the sequence number field). Section 3.3.1 of [RFC3711] explains in
great detail how the 16-bit sequence number and 32-bit Rollover
Counter are to be used to recover the 48-bit Packet Counter.
1.3. SRTP IV formation for AES-GCM and AES-CCM 8.1. SRTP IV formation for AES-GCM and AES-CCM
AES-GCM and AES-CCM SRTP use a 12 byte initialization vector which is The 12 byte initialization vector used by both AES-GCM and AES-CCM
formed as follows. A 12-octet string is formed by concatenating SRTP is formed by first concatenating 2-octets of zeroes, the 4-octet
2-octets of zeroes, the 4-octet SSRC, and the 6-octet Packet SSRC, the 4-octer Rollover Counter (ROS) and the two octet sequence
Counter. The resulting string is bitwise exclusive-ored with the number SEQ. The resulting 12-octet value is then XORed to the
12-octet salt to form the 12-octet IV. 12-octet salt to form the 12-octet IV.
0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1
+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+
|00|00| SSRC | Packet_Counter |---+ |00|00| SSRC | ROC | SEQ |---+
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| Encryption Salt |->(+) | Encryption Salt |->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| Initialization Vector |<--+ | Initialization Vector |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1: AES-GCM and AES-CCM SRTP Figure 1: AES-GCM and AES-CCM SRTP
Initialization Vector formation. Initialization Vector formation.
Using the terminology of section 8.2.1. of [GCM], the first six Using the terminology of section 8.2.1. of [GCM], the first six
octets of the IV are the fixed field and the last six bytes are the octets of the IV are the fixed field and the last six bytes are the
invocation field. invocation field.
1.4. SRTCP IV formation for AES-GCM and AES-CCM 8.2. Data Types in SRTP Packets
The initialization vector for an SRTCP packet is formed from the
4-octet Synchronization Source identifier (SSRC), 31-bit SRTCP Index
(packed zero-filled, right justified into a 4-octet field), and a
12-octet SRTCP session encryption salt produced by the SRTP Key
Derivation Function (KDF).
0 1 2 3 4 5 6 7 8 9 10 11
+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00| SSRC |00|00|SRTCP Index|---+
+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+ |
| Encryption Salt |->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+ |
| Initialization Vector |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: SRTCP Initialization Vector formation. All SRTP packets MUST be both authenticated and encrypted. The data
fields within the SRTP packets are broken into Associated Data,
Plaintext and Raw Data as follows (see figure 2):
As shown if figure 2, a 12-octet string is formed by concatenating in Associated Data The version (2 bits), padding flag (1 bit),
order 2-octets of zeroes, the 4-octet SSRC, 2 more zero octets, and extension flag (1 bit), CSRC count (4 bits),
the 4-octet SRTCP index. The resulting 12-octet string is bitwise sequence number (16 bits), timestamp (32 bits),
exclusive-ored into salt; the output of that process is the IV. The SSRC (32 bits), optional contributing source
IV is always exactly 12 octets in length. Using the terminology of identifiers (CSRCs, 32 bits each), and optional
section 8.2.1. of [GCM], the first eight octets of the IV are the RTP extension (32 bits).
fixed field and the last four bytes are the invocation field.
1.5. AEAD Processing of SRTP Packets Plaintext The RTP payload (variable length), RTP padding (if
used, variable length), and RTP pad count ( if
used, 8 bits).
All SRTP packets MUST be authenticated and encrypted. Figure 3 below Raw Data The optional 32-bit SRTP MKI and the 32-bit SRTP
shows which fields of AEAD SRTP packet are to be treated as plaintext authentication tag (whose use is NOT
and which are to be treated as additional authenticated data. RECOMMENDED).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A |V=2|P|X| CC |M| Packet Type | sequence number | A |V=2|P|X| CC |M| Packet Type | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | timestamp | A | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | synchronization source (SSRC) identifier | A | synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
A | contributing source (CSRC) identifiers (optional) | A | contributing source (CSRC) identifiers (optional) |
A | .... | A | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | RTP extension (OPTIONAL) | A | RTP extension (OPTIONAL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | payload ... | P | payload ... |
P | +-------------------------------+ P | +-------------------------------+
P | | RTP padding | RTP pad count | P | | RTP padding | RTP pad count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X : authentication tag (NOT RECOMMENDED) : R : SRTP MKI (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R : authentication tag (NOT RECOMMENDED) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P = Plaintext (to be encrypted and authenticated) P = Plaintext (to be encrypted and authenticated)
A = Associated Data (to be authenticated only) A = Associated Data (to be authenticated only)
X = neither encrypted nor authenticated R = neither encrypted nor authenticated
Note: The RTP padding and RP padding count fields are optional Note: The RTP padding and RTP padding count fields are optional
and are not recommended and are not recommended
Figure 3: AEAD inputs from an SRTP packet. Figure 2: AEAD inputs from an SRTP packet.
1.6. AEAD Processing of SRTCP Packets 8.3. Prevention of SRTP IV Reuse
All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC)
packet encryption is optional. A sender can select which packets to triple is never used twice with the same master key. There are two
encrypt, and indicates this choice with a 1-bit encryption flag phases to this issue.
(located in the leftmost bit of the 32-bit word that contains the
SRTCP index)
1.6.1. Encrypted SRTCP packets Counter Management A rekey MUST be performed to establish a new
master key before the (ROC,SEQ) pair cycles back
to its original value.
When the encryption flag is set to 1, the first 8-octets, the SSRC Management The set of all SSRC values must be partitioned
encryption flag and 31-bit SRTCP index MUST be treated as AAD. The into disjoint pools, one pool for each endpoint
remaining data MUST be treated as plaintext, and hence is to be both using the master key to originate outbound
encrypted and AEAD authenticated, save for the optional SRTCP MKI data. Each such endpoint MUST only issue SSRC
index and optional SRTCP authentication tag, which MUST be neither values from the pool it has been assigned.
encrypted nor AEAD authenticated. Figure 4 below shows how fields of Further, each endpoint MUST maintain a history
an RTCP packet are to be treated when the encryption flag is set to of outbound SSRC identifiers that it has issued
1. within the lifetime of the current master key,
and when a new synchronization source requests
an SSRC identifier it MUST NOT be given an
identifier that has been previously issued. A
rekey MUST be performed before its pool of SSRC
values is exhausted.
9. AES-GCM/CCM Processing of SRTCP Compound Packets
All SRTCP compound packets MUST be authenticated, but unlike SRTP,
SRTCP packet encryption is optional. A sender can select which
packets to encrypt, and indicates this choice with a 1-bit encryption
flag (located just before the 31-bit SRTCP index)
9.1. SRTCP IV formation for AES-GCM and AES-CCM
The 12 byte initialization vector used by both AES-GCM and AES-CCM
SRTCP is formed by first concatenating 2-octets of zeroes, the
4-octet Synchronization Source identifier (SSRC), 2-octets of zeroes,
a single zero bit, and the 31-bit SRTCP Index. The resulting
12-octet value is then XORed to the 12-octet salt to form the
12-octet IV.
0 1 2 3 4 5 6 7 8 9 10 11
+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00| SSRC |00|00|0+SRTCP Idx|---+
+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+ |
| Encryption Salt |->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+ |
| Initialization Vector |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: SRTCP Initialization Vector formation.
Using the terminology of section 8.2.1. of [GCM], the first eight
octets of the IV are the fixed field and the last four bytes are the
invocation field.
9.2. Data Types in Encrypted SRTCP Compound Packets
When the encryption flag is set to 1, the SRTCP packet is broken into
plaintext, associated data, and raw (untouched) data as listed below
(see figure 4):
Associated Data The packet version (2 bits), padding flag (1 bit),
reception report count (5 bits), packet type (8
bits), length (2 octets), SSRC (4 octets),
encryption flag (1 bit) and SRTCP index (31
bits).
Raw Data The 32-bit optional SRTCP MKI index and 32-bit
SRTCP authentication tag (whose use is NOT
RECOMMENDED).
Plaintext All other data.
Note that the plaintext comes in one contiguous field. Since the
AEAD cipher is larger than the plaintext by exactly the length of the
AEAD authentication tag, the corresponding STRCP encrypted packet
replaces the plaintext field with a slightly larger field containing
the cipher.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A |V=2|P| RC | Packet Type | length | A |V=2|P| RC | Packet Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | synchronization source (SSRC) of Sender | A | synchronization source (SSRC) of Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | sender info | P | sender info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 42 skipping to change at page 11, line 45
P |V=2|P| SC | Packet Type | length | P |V=2|P| SC | Packet Type | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
P | SSRC/CSRC_1 | P | SSRC/CSRC_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | SDES items | P | SDES items |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
P | ... | P | ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
A |1| SRTCP index | A |1| SRTCP index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X | SRTCP MKI (optional)index | R | SRTCP MKI (optional) index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X : authentication tag (NOT RECOMMENDED) : R : authentication tag (NOT RECOMMENDED) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P = Plaintext (to be encrypted and authenticated) P = Plaintext (to be encrypted and authenticated)
A = Associated Data (to be authenticated only) A = Associated Data (to be authenticated only)
X = neither encrypted nor authenticated R = neither encrypted nor authenticated
Figure 4: AEAD SRTCP inputs when encryption flag = 1. Figure 4: AEAD SRTCP inputs when encryption flag = 1.
1.6.2. Unencrypted SRTCP packets 9.3. Data Types in Unencrypted SRTCP Compound Packets
When the encryption flag is set to 0, all of the data up to and When the encryption flag is set to 0, the SRTCP compound packet is
including the SRTCP index is treated as AAD. Figure 5 shows how the broken into plaintext, associated data, and raw (untouched) data as
fields of an RTCP packet are to be treated when the encryption flag follows (see figure 5):
is set to 0.
Plaintext None.
Raw Data The 32-bit optional SRTCP MKI index and 32-bit
SRTCP authentication tag (whose use is NOT
RECOMMENDED).
Associated Data All other data.
Even though there is no plaintext in this RTCP packet, AEAD
encryption returns a cipher field which is precisely the length of
the AEAD authentication tag. This cipher is to be placed before the
Encryption flag and the SRTCP index in the authenticated SRTCP
packet.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A |V=2|P| RC | Packet Type | length | A |V=2|P| RC | Packet Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | synchronization source (SSRC) of Sender | A | synchronization source (SSRC) of Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | sender info | A | sender info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 37 skipping to change at page 12, line 50
A |V=2|P| SC | Packet Type | length | A |V=2|P| SC | Packet Type | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
A | SSRC/CSRC_1 | A | SSRC/CSRC_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | SDES items | A | SDES items |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
A | ... | A | ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
A |0| SRTCP index | A |0| SRTCP index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X | SRTCP MKI (optional)index | R | SRTCP MKI (optional)index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X : authentication tag (NOT RECOMMENDED) : R : authentication tag (NOT RECOMMENDED) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A = Associated Data (to be authenticated only) A = Associated Data (to be authenticated only)
X = neither encrypted nor authenticated R = neither encrypted nor authenticated
Figure 5: AEAD SRTCP inputs when encryption flag = 0. Figure 5: AEAD SRTCP inputs when encryption flag = 0.
1.7. Initialization of the Counters 9.4. Prevention of SRTCP IV Reuse
When an AEAD Crypto Context is first established, both the SRTCP
index and the rollover counter are set to zero. The Sequence Number
is set to a value passed to it by RTP. When the context is rekeyed
these counters keep their current values and are not reset to zero.
These conventions assist in making a seamless transition from the old
key (if any) to the new key despite of the fact that packets are
allowed to arrive out of order.
As mentioned in section 1.1, AES-GCM and AES-CCM both use a Block
Counter which is reset at the start of each packet. For AES-CCM it
is reset to 0 and for AES-GCM it is reset to 1.
1.8. Prevention of IV Reuse
For a given key it is critical that the IV not repeat. This reduces A new master key MUST be established before the 31-bit SRTCP index
to the problem of insuring neither the Packet Counter nor the SRTCP cycles back to its original value. Ideally a rekey performed should
index do not repeat before the AEAD instantiation is rekeyed. be performed and a new master key in place and well before the SRTCP
index overflows.
Processing MUST cease if either the 48-bit Packet Counter or the The comments on SSRC management in section 8.3 also apply.
31-bit SRTCP index cycles back to their initial value. Processing
MUST NOT resume until a new SRTP/SRTCP session has been established
using a new shared secret master key and shares master salt.
Ideally, a rekey should be done well before either of these counters
cycle.
2. AEAD parameters for SRTP and SRTCP 10. Constraints on AEAD for SRTP and SRTCP
In general, any AEAD algorithm can accept inputs with varying In general, any AEAD algorithm can accept inputs with varying
lengths, but each algorithm can accept only a limited range of lengths, but each algorithm can accept only a limited range of
lengths for a specific parameter. In this section, we describe the lengths for a specific parameter. In this section, we describe the
constraints on the parameter lengths that any AEAD algorithm must constraints on the parameter lengths that any AEAD algorithm must
support to be used in AEAD-SRTP. Additionally we specify a complete support to be used in AEAD-SRTP. Additionally we specify a complete
parameter set for two specific AEAD algorithms, namely AES-GCM and parameter set for two specific AEAD algorithms, namely AES-GCM and
AES-CCM. AES-CCM.
2.1. Generic AEAD Parameter Constraints 10.1. Generic AEAD Parameter Constraints
All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three
constraints listed below: constraints listed below:
PARAMETER Meaning Value PARAMETER Meaning Value
A_MAX maximum additional MUST be at least 12 octets A_MAX maximum additional MUST be at least 12 octets
authenticated data authenticated data
length length
N_MIN minimum nonce (IV) MUST be no more than 12 octets N_MIN minimum nonce (IV) MUST be no more than 12 octets
length length
N_MAX maximum nonce (IV) MUST be at least 12 octets N_MAX maximum nonce (IV) MUST be at least 12 octets
length length
C_MAX maximum ciphertext MUST be at most 2^16-40 octets C_MAX maximum ciphertext MUST be at most 2^36-16 octets
length per invocation SHOULD be at least 2232 length per invocation C_max values less than 2232
are discouraged
The upper bound on C_MAX is obtained by subtracting away a 20-octet
IP header, an 8-octet UDP header, and a 12-octet RTP header out of
the largest possible IP packet, the total length of which is 2^16
octets.
Similarly the lower bound on C_MAX is based on the maximum The upper bound on C_MAX are based on purely cryptographic
transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many considerations. The lower bound on C_MAX is obtained by subtracting
RTP applications use very short payloads (for example, the G.729 away a 20-octet IP header, 8-octet UDP header, and 12-octet RTP
codec used in VoIP can be as short as 20 octets), implementations header from the maximum transmission unit (MTU) of 2272.
that only support a maximum ciphertext length smaller than 2232
octets are permitted under this RFC. However, in the interest of
maximizing interoperability between various AEAD implementations, the
use of C_MAX values less than 2232 is discouraged.
For sake of clarity we specify two additional parameters: For sake of clarity we specify two additional parameters:
Authentication Tag Length MUST be either 8, 12, or 16 Authentication Tag Length MUST be either 8, 12, or 16
octets octets
Maximum number of invocations MUST be at most 2^48 for SRTP Maximum number of invocations MUST be at most 2^48 for SRTP
for a given instantiation MUST be at most 2^31 for SRTCP for a given instantiation MUST be at most 2^31 for SRTCP
Block Counter size MUST be 32 bits
The reader is reminded that the plaintext is shorter than the The reader is reminded that the plaintext is shorter than the
ciphertext by exactly the length of the AEAD authentication tag. ciphertext by exactly the length of the AEAD authentication tag.
2.2. AES-GCM for SRTP/SRTCP 10.2. AES-GCM for SRTP/SRTCP
AES-GCM is a family of AEAD algorithms built around the AES block AES-GCM is a family of AEAD algorithms built around the AES block
cipher algorithm. AES-GCM uses AES counter mode for encryption and cipher algorithm. AES-GCM uses AES counter mode for encryption and
Galois Message Authentication Code (GMAC) for authentication. A Galois Message Authentication Code (GMAC) for authentication. A
detailed description of the AES-GCM family can be found in detailed description of the AES-GCM family can be found in
[RFC5116]. The following members of the AES-GCM family may be used [RFC5116]. The following members of the AES-GCM family may be used
with SRTP/SRTCP: with SRTP/SRTCP:
Table 1: AES-GCM algorithms for SRTP/SRTCP Table 1: AES-GCM algorithms for SRTP/SRTCP
Name Key Size Auth. Tag Size Reference Name Key Size Auth. Tag Size Reference
================================================================ ================================================================
AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] AEAD_AES_128_GCM 16 octets 16 octets [RFC5116]
AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] AEAD_AES_256_GCM 32 octets 16 octets [RFC5116]
AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282]
AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282]
AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282]
AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282]
Any implementation of AES-GCM SRTP SHOULD support both Any implementation of AES-GCM SRTP SHOULD support both
AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8, and it MAY support the AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8, and it MAY support the
four other variants shown in the table. four other variants shown table 1.
In addition to the Packet Counter used in the formation of IVs, each
instantiation of AES-GCM has a block counter which is incremented
each time AES is called to produce a 16-octet output block. The
block counter is reset to "1" each time AES-GCM is invoked to process
a new packet. The 128-bit concatentation of the IV and the block
counter is input to AES and the output is used as a block of key that
is XORed to the next block of data to be encrypted/decypted.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| initialization | block |
| vector | counter |
----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 6: AES Inputs for Counter Mode Encryption
2.3. AES-CCM for SRTP/SRTCP 10.3. AES-CCM for SRTP/SRTCP
AES-CCM is another family of AEAD algorithms built around the AES AES-CCM is another family of AEAD algorithms built around the AES
block cipher algorithm. AES-GCM uses AES counter mode for encryption block cipher algorithm. AES-CCM uses AES counter mode for encryption
and AES Cipher Block Chaining Message Authentication Code (CBC MAC) and AES Cipher Block Chaining Message Authentication Code (CBC MAC)
for authentication. A detailed description of the AES-CCM family can for authentication. A detailed description of the AES-CCM family can
be found in [RFC5116]. The following members of the AES-CCM family be found in [RFC5116]. The following members of the AES-CCM family
may be used with SRTP/SRTCP: may be used with SRTP/SRTCP:
Table 2: AES-CCM algorithms for SRTP/SRTCP Table 2: AES-CCM algorithms for SRTP/SRTCP
Name Key Size Auth. Tag Size Reference Name Key Size Auth. Tag Size Reference
================================================================ ================================================================
AEAD_AES_128_CCM 16 octets 16 octets [RFC5116] AEAD_AES_128_CCM 16 octets 8, 12 or 16 octets [RFC5116]
AEAD_AES_256_CCM 32 octets 16 octets [RFC5116] AEAD_AES_256_CCM 32 octets 8, 12 or 16 octets [RFC5116]
Any implementation of AES-CCM SRTP/SRTCP SHOULD support both Any implementation of AES-CCM SRTP/SRTCP SHOULD support both
AEAD_AES_128_CCM and AEAD_AES_256_CCM. AEAD_AES_128_CCM and AEAD_AES_256_CCM.
In addition to the Packet Counter used in the formation of IVs,
each instantiation of AES-CCM has a block counter which is
incremented each time AES is called to produce a 16-octet output
block. The block counter is reset to "0" each time AES-CCM is
invoked to process a new packet. As with AES-GCM, the 128-bit
concatentation of the IV abd the block counter is input to AES to
produce a block of key that is XORed to the next block of data to
be encrypted/decypted.
AES-CCM uses a flag octet that conveys information about the length AES-CCM uses a flag octet that conveys information about the length
of the authentication tag, length of the block counter, and presence of the authentication tag, length of the block counter, and presence
of additional authenticated data. For AES-CCM in SRTP/SRTCP, the of additional authenticated data. For AES-CCM in SRTP/SRTCP, the
flag octet has the hex value 5A if an 8-octet authentication tag is flag octet has the hex value 5A if an 8-octet authentication tag is
used, 6A if a 12-octet authentication tag is used, and 7A if a used, 6A if a 12-octet authentication tag is used, and 7A if a
16-octet authentication tag is used. The flag octet is one of the 16-octet authentication tag is used. The flag octet is one of the
inputs to AES during the counter mode encryption of the plaintext. inputs to AES during the counter mode encryption of the plaintext.
2.4. Key Derivation Functions 11. Key Derivation Functions
A Key Derivation Function (KDF) is used to derive all of the required A Key Derivation Function (KDF) is used to derive all of the required
encryption and authentication keys from a secret value shared by the encryption and authentication keys from a secret value shared by the
two endpoints. Both the AEAD_AES_128_GCM algorithms and the endpoints. Both the AEAD_AES_128_GCM algorithms and the
AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key
Derivation Function described in [RFC3711]. Both the Derivation Function described in [RFC3711]. Both the
AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST
use the AES_256_CM_PRF Key Derivation Function described in [RFC use the AES_256_CM_PRF Key Derivation Function described in [RFC
6188]. 6188].
3. Security Considerations 12. Security Considerations
3.1. Handling of Security Critical Parameters 12.1. Handling of Security Critical Parameters
As with any security process, the implementer must take care to As with any security process, the implementer must take care to
ensure cryptographically sensitive parameters are properly handled. ensure cryptographically sensitive parameters are properly handled.
Many of these recommendations hold for all SRTP cryptographic Many of these recommendations hold for all SRTP cryptographic
algorithms, but we include them here to emphasize their importance. algorithms, but we include them here to emphasize their importance.
- If the master salt is to be kept secret it MUST be properly - If the master salt is to be kept secret, it MUST be properly
erased when no longer needed. erased when no longer needed.
- The secret master key and all keys derived from it MUST be kept - The secret master key and all keys derived from it MUST be kept
secret. All keys MUST be properly erased when no longer secret. All keys MUST be properly erased when no longer
needed. needed.
- Packets that fail the authentication check SHOULD be silently - At the start of each packet, the block counter MUST be reset (to
discarded.
- The sender MUST increment the Packet Counter after each SRTP
packet is processed.
- The sender MUST increment the SRTCP index after each SRTCP
packet is processed.
- At the start of each packet the block counter MUST be reset (to
0 for CCM, to 1 for GCM). The block counter is incremented 0 for CCM, to 1 for GCM). The block counter is incremented
after each block key has been produced, but it MUST NOT be after each block key has been produced, but it MUST NOT be
allowed to exceed 2^32-1. allowed to exceed 2^32-1.
- Each time a rekey occurs the initial values of the invocation - Each time a rekey occurs, the initial values of the SRTCP index
counter and SRTCP index MUST be saved. and the values of all the SEQ counters MUST be saved.
- Processing MUST cease if the 48-bit Packet Counter or the 31-bit - Processing MUST cease if the 48-bit Packet Counter or the 31-bit
SRTCP index cycles back to its initial value. Processing MUST SRTCP index cycles back to its initial value. Processing MUST
NOT resume until a new SRTP/SRTCP session has been established NOT resume until a new SRTP/SRTCP session has been established
using a new SRTP master key. Ideally, a rekey should be done using a new SRTP master key. Ideally, a rekey should be done
well before either of these counters cycle. well before either of these counters cycle.
3.2. Size of the Authentication Tag 12.2. Size of the Authentication Tag
We require that the AEAD authentication tag must be at least 8 We require that the AEAD authentication tag must be at least 8
octets, significantly reducing the probability of an adversary octets, significantly reducing the probability of an adversary
successfully introducing fraudulent data. The goal of an successfully introducing fraudulent data. The goal of an
authentication tag is to minimize the probability of a successful authentication tag is to minimize the probability of a successful
forgery occurring anywhere in the network we are attempting to forgery occurring anywhere in the network we are attempting to
defend. There are three relevant factors: how low we wish the defend. There are three relevant factors: how low we wish the
probability of successful forgery to be (prob_success), how many probability of successful forgery to be (prob_success), how many
attempts the adversary can make (N_tries) and the size of the attempts the adversary can make (N_tries) and the size of the
authentication tag in bits (N_tag_bits). Then authentication tag in bits (N_tag_bits). Then
skipping to change at page 15, line 20 skipping to change at page 16, line 23
into a target network by randomly selecting an authentication value into a target network by randomly selecting an authentication value
until by chance they hit a valid authentication tag. The table below until by chance they hit a valid authentication tag. The table below
summarizes the relationship between the number of forged packets the summarizes the relationship between the number of forged packets the
adversary has tried, the size of the authentication tag, and the adversary has tried, the size of the authentication tag, and the
probability of a compromise occurring (i.e. at least one of the probability of a compromise occurring (i.e. at least one of the
attempted forgeries having a valid authentication tag). The reader attempted forgeries having a valid authentication tag). The reader
is reminded that the forgery attempts can be made over the entire is reminded that the forgery attempts can be made over the entire
network, not just a single link, and that frequently changing the key network, not just a single link, and that frequently changing the key
does not decrease the probability of a compromise occurring. does not decrease the probability of a compromise occurring.
|==================+========================================| +==================+========================================+
| Authentication | Probability of a Compromise Occurring | | Authentication | Probability of a Compromise Occurring |
| Tag Size |------------+-------------+-------------| | Tag | for a given number of forgery attempts |
| (octets) | 2^-30 | 2^-20 | 2^-10 | | Size |------------+-------------+-------------|
| (octets) | prob=2^-30 | prob=2^-20 | prob=2^-10 |
|==================+=============+=============+============| |==================+=============+=============+============|
| 4 | 2^2 tries | 2^12 tries | 2^22 tries | | 4 | 2^2 tries | 2^12 tries | 2^22 tries |
|==================+============+=============+=============| |==================+============+=============+=============|
| 8 | 2^34 tries | 2^44 tries | 2^54 tries | | 8 | 2^34 tries | 2^44 tries | 2^54 tries |
|==================+============+=============+=============| |==================+============+=============+=============|
| 12 | 2^66 tries | 2^76 tries | 2^86 tries | | 12 | 2^66 tries | 2^76 tries | 2^86 tries |
|==================+============+=============+=============| |==================+============+=============+=============|
| 16 | 2^98 tries | 2^108 tries | 2^118 tries | | 16 | 2^98 tries | 2^108 tries | 2^118 tries |
|==================+============+=============+=============| +=================+============+=============+==============+
Table 1: Probability of a compromise occurring for a given Table 3: Probability of a compromise occurring for a given
number of forgery attempts and tag size. number of forgery attempts and tag size.
4. IANA Considerations 13. IANA Considerations
RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to 13.1. SDES
a particular AEAD algorithm in SRTP. In order to allow SDP to signal
the use of the algorithms defined in this document, IANA will Security description [RFC 4568] defines SRTP "crypto suites"; a
register the following crypto suites into the subregistry for SRTP crypto suite corresponds to a particular AEAD algorithm in SRTP. In
crypto suites under the SRTP transport of the SDP Security order to allow SDP to signal the use of the algorithms defined in
Descriptions: this document, IANA will register the following crypto suites into
the subregistry for SRTP crypto suites under the SRTP transport of
the SDP Security Descriptions:
srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / srtp-crypto-suite-ext = "AEAD_AES_128_GCM" /
"AEAD_AES_256_GCM" / "AEAD_AES_256_GCM" /
"AEAD_AES_128_GCM_8" / "AEAD_AES_128_GCM_8" /
"AEAD_AES_256_GCM_8" / "AEAD_AES_256_GCM_8" /
"AEAD_AES_128_GCM_12" / "AEAD_AES_128_GCM_12" /
"AEAD_AES_256_GCM_12" / "AEAD_AES_256_GCM_12" /
"AEAD_AES_128_CCM" / "AEAD_AES_128_CCM" /
"AEAD_AES_256_CCM" / "AEAD_AES_256_CCM" /
srtp-crypto-suite-ext srtp-crypto-suite-ext
13.2. DTLS
DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; it DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; it
also corresponds to the use of an AEAD algorithm in SRTP. In order also corresponds to the use of an AEAD algorithm in SRTP. In order
to allow the use of the algorithms defined in this document in to allow the use of the algorithms defined in this document in
DTLS-SRTP, IANA will also register the following SRTP Protection DTLS-SRTP, we request IANA register the following SRTP Protection
Profiles: Profiles:
SRTP_AEAD_AES_128_GCM AEAD_AES_128_CCM
SRTP_AEAD_AES_256_GCM cipher: AES_128_CCM
SRTP_AEAD_AES_128_GCM_8 cipher_key_length: 128 bits
SRTP_AEAD_AES_256_GCM_8 cipher_salt_length: 96 bits
SRTP_AEAD_AES_128_GCM_12 maximum lifetime: at most 2^31 SRTCP packets and
SRTP_AEAD_AES_256_GCM_12 at most 2^48 SRTP packets
SRTP_AEAD_AES_128_CCM
SRTP_AEAD_AES_256_CCM
5. Acknowledgements AEAD_AES_256_CCM
cipher: AES_256_CCM
cipher_key_length: 256 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_CCM_8
cipher: AES_128_CCM
cipher_key_length: 128 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_CCM_8
cipher: AES_256_CCM
cipher_key_length: 256 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_CCM_12
cipher: AES_128_CCM
cipher_key_length: 128 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_CCM_12
cipher: AES_256_CCM
cipher_key_length: 256 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_CCM
cipher: AES_128_CCM
cipher_key_length: 128 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_CCM
cipher: AES_256_CCM
cipher_key_length: 256 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_GCM_8
cipher: AES_128_GCM
cipher_key_length: 128 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_GCM_8
cipher: AES_256_GCM
cipher_key_length: 256 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_GCM_12
cipher: AES_128_GCM
cipher_key_length: 128 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_GCM_12
cipher: AES_256_GCM
cipher_key_length: 256 bits
cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
Note that these SRTP Protection Profiles do not specify an
auth_function, auth_key_length, or auth_tag_length because all of
these profiles use AEAD algorithms, and thus do not use a separate
auth_function, auth_key, or auth_tag.
13.3. MIKEY
In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830],
IANA maintains several Payload Name Spaces under Multimedia Internet
KEYing (MIKEY). This document requires dditions to two of the lists
maintained under MIKEY Security Protocol Parameters.
On the SRTP policy Type/Value list (derived from Table 6.10.1.a of
[RFC3830]) we request the following addition:
Type | Meaning | Possible values
----------------------------------------------------------------
TBD | AEAD authentication tag length | 8, 12, or 16 (in octets)
On the Encryption Algorithm List (derived from Table 6.10.1.b of
[RFC3830]) we request the following additions:
SRTP encr alg. | Value | Default Session Encr. Key Length
-----------------------------------------------------------
AES-CCM | TBD | 16 octets
AES-GCM | TBD | 16 octets
The SRTP encryption algorithm, session encryption key length, and
AEAD authentication tag values received from MIKEY fully determine
the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is
described in section 14.
14. Parameters for use with MIKEY
MIKEY specifies the algorithm family separately from the key length
(which is specified by the Session Encryption key length ) and the
authentication tag length (specified by AEAD Auth. tag length).
+------------+-------------+---------------+
| Encryption | Encryption | AEAD Auth. |
| Algorithm | Key Length | Tag Length |
+============+=============+===============+
AEAD_AES_128_GCM | AES-GCM | 16 | 16 |
+------------+-------------+---------------+
AEAD_AES_128_CCM | AES-CCM | 16 | 16 |
+------------+-------------+---------------+
AEAD_AES_128_GCM_12 | AES-GCM | 16 | 12 |
+------------+-------------+---------------+
AEAD_AES_128_CCM_12 | AES-CCM | 16 | 12 |
+------------+-------------+---------------+
AEAD_AES_128_GCM_8 | AES-GCM | 16 | 8 |
+------------+-------------+---------------+
AEAD_AES_128_CCM_8 | AES-CCM | 16 | 8 |
+------------+-------------+---------------+
AEAD_AES_256_GCM | AES-GCM | 32 | 16 |
+------------+-------------+---------------+
AEAD_AES_256_CCM | AES-CCM | 16 | 16 |
+------------+-------------+---------------+
AEAD_AES_256_GCM_12 | AES-GCM | 32 | 12 |
+------------+-------------+---------------+
AEAD_AES_256_CCM_12 | AES-CCM | 16 | 12 |
+------------+-------------+---------------+
AEAD_AES_256_GCM_8 | AES-GCM | 32 | 8 |
+------------+-------------+---------------+
AEAD_AES_256_CCM_8 | AES-CCM | 16 | 8 |
+============+=============+===============+
Table 4: Mapping MIKEY parameters to AEAD algorithm
Section 11 in this document restricts the choice of Key Derivation
Function for AEAD algorithms. To enforce this restriction in MIKEY,
we require that the SRTP PRF has value AES-CM whenever an AEAD
algorithm is used. Note that, according to Section 6.10.1 in
[RFC3830], the key length of the Key Derivation Function (i.e. the
SRTP master key length) is always equal to the session encryption key
length. This means, for example, that AEAD_AES_256_GCM will use
AES_256_CM_PRF as the Key Derivation Function.
15. Acknowledgements
The authors would like to thank Michael Peck, Michael Torla, Qin Wu, The authors would like to thank Michael Peck, Michael Torla, Qin Wu,
and many other reviewers who provided valuable comments on earlier Magnus Westerland, Oscar Ohllson and many other reviewers who
drafts of this document. provided valuable comments on earlier drafts of this document.
6. References 16. References
6.1. Normative References 16.1. Normative References
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM
Mode for Authentication and Confidentiality", U.S. Mode for Authentication and Confidentiality", U.S.
National Institute of Standards and Technology http:// National Institute of Standards and Technology http://
csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf.
[GCM] Dworkin, M., "NIST Special Publication 800-38D: [GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation: Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.", U.S. National Galois/Counter Mode (GCM) and GMAC.", U.S. National
Institute of Standards and Technology http:// Institute of Standards and Technology http://
csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004. (SRTP)", RFC 3711, March 2004.
[RFC4658] Andreasen, F., Baugher, M., and D.Wing, "Session [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and
Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session
Description Protocol (SDP): Security Descriptions for Description Protocol (SDP): Security Descriptions for
Media Streams", RFC 4568, July 2006. Media Streams", RFC 4568, July 2006.
[RFC5116] McGrew, D., "An Interface and Algorithms for [RFC5116] McGrew, D., "An Interface and Algorithms for
Authenticated Encryption with Associated Data", RFC 5116, Authenticated Encryption with Associated Data", RFC 5116,
January 2008. January 2008.
[RFC5116] McGrew, D., "An Interface and Algorithms for
Authenticated Encryption with Associated Data", RFC 5116,
January 2008.
[RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP" [RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP"
RFC 6811, March 2011 RFC 6811, March 2011
6.2. Informative References 16.2. Informative References
[BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption:
Relations among notions and analysis of the generic Relations among notions and analysis of the generic
composition paradigm", Proceedings of ASIACRYPT 2000, composition paradigm", Proceedings of ASIACRYPT 2000,
Springer-Verlag, LNCS 1976, pp. 531-545 http:// Springer-Verlag, LNCS 1976, pp. 531-545 http://
www-cse.ucsd.edu/users/mihir/papers/oem.html. www-cse.ucsd.edu/users/mihir/papers/oem.html.
[BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication
and Key Establishment", Springer, 2003 . and Key Establishment", Springer, 2003 .
 End of changes. 88 change blocks. 
355 lines changed or deleted 557 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/