draft-ietf-avtcore-srtp-aes-gcm-03.txt   draft-ietf-avtcore-srtp-aes-gcm-04.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. Igoe Intended Status: Standards Track K. Igoe
Expires: March 22, 2013 National Security Agency Expires: August 08, 2013 National Security Agency
September 18, 2012 February 04, 2013
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-03 draft-ietf-avtcore-srtp-aes-gcm-04
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 March 22, 2013. This Internet-Draft will expire on August 08, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction.....................................................3 1. Introduction.....................................................3
2. Conventions Used In This Document................................3 2. Conventions Used In This Document................................3
3. Overview of the SRTP/SRTCP Security Architecture.................4 3. Overview of the SRTP/SRTCP Security Architecture.................4
4. Terminology......................................................4 4. Terminology......................................................4
5. Generic AEAD Processing..........................................5 5. Generic AEAD Processing..........................................5
5.1. Types of Input Data.........................................5 5.1. Types of Input Data.........................................5
5.2. AEAD Invocation Inputs and Outputs..........................5 5.2. AEAD Invocation Inputs and Outputs..........................5
5.2.1. Encrypt Mode...........................................5 5.2.1. Encrypt Mode...........................................5
5.2.2. Decrypt Mode...........................................6 5.2.2. Decrypt Mode...........................................6
5.3. Handling of AEAD Authentication.............................6 5.3. Handling of AEAD Authentication.............................6
6. Counter Mode Encryption..........................................6 6. Counter Mode Encryption..........................................7
7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................8 7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................8
8. Unneeded SRTP/SRTCP Fields.......................................8 8. Unneeded SRTP/SRTCP Fields.......................................8
8.1. SRTP/SRTCP Authentication Field.............................8 8.1. SRTP/SRTCP Authentication Field.............................8
8.2. RTP Padding.................................................8 8.2. RTP Padding.................................................9
9. AES-GCM/CCM processing for SRTP..................................9 9. AES-GCM/CCM processing for SRTP..................................9
9.1. SRTP IV formation for AES-GCM and AES-CCM...................9 9.1. SRTP IV formation for AES-GCM and AES-CCM...................9
9.2. Data Types in SRTP Packets..................................9 9.2. Data Types in SRTP Packets..................................9
9.3. Prevention of SRTP IV Reuse................................10 9.3. Prevention of SRTP IV Reuse................................11
10. AES-GCM/CCM Processing of SRTCP Compound Packets...............11 10. AES-GCM/CCM Processing of SRTCP Compound Packets...............11
10.1. SRTCP IV formation for AES-GCM and AES-CCM................11 10.1. SRTCP IV formation for AES-GCM and AES-CCM................11
10.2. Data Types in Encrypted SRTCP Compound Packets............12 10.2. Data Types in Encrypted SRTCP Compound Packets............12
10.3. Data Types in Unencrypted SRTCP Compound Packets..........13 10.3. Data Types in Unencrypted SRTCP Compound Packets..........13
10.4. Prevention of SRTCP IV Reuse..............................14 10.4. Prevention of SRTCP IV Reuse..............................14
11. Constraints on AEAD for SRTP and SRTCP.........................14 11. Constraints on AEAD for SRTP and SRTCP.........................14
11.1. Generic AEAD Parameter Constraints........................15 11.1. Generic AEAD Parameter Constraints........................15
11.2. AES-GCM for SRTP/SRTCP....................................15 11.2. AES-GCM for SRTP/SRTCP....................................15
11.3. AES-CCM for SRTP/SRTCP....................................16 11.3. AES-CCM for SRTP/SRTCP....................................16
12. Key Derivation Functions.......................................16 12. Key Derivation Functions.......................................16
13. Security Considerations........................................17 13. Security Considerations........................................17
13.1. Handling of Security Critical Parameters..................17 13.1. Handling of Security Critical Parameters..................17
13.2. Size of the Authentication Tag............................17 13.2. Size of the Authentication Tag............................17
14. IANA Considerations............................................18 14. IANA Considerations............................................18
14.1. SDES......................................................18 14.1. SDES......................................................18
14.2. DTLS......................................................19 14.2. DTLS......................................................19
14.3. MIKEY.....................................................20 14.3. MIKEY.....................................................21
14.4. AEAD registry.............................................21 14.4. AEAD registry.............................................22
15. Parameters for use with MIKEY..................................21 15. Parameters for use with MIKEY..................................22
16. Acknowledgements...............................................22 16. Acknowledgements...............................................23
17. References.....................................................23 17. References.....................................................24
17.1. Normative References......................................23 17.1. Normative References......................................24
17.2. Informative References....................................25 17.2. Informative References....................................26
1. Introduction 1. Introduction
The Secure Real-time Transport Protocol (SRTP) is a profile of the The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
Real-time Transport Protocol (RTP), which can provide of the Real-time Transport Protocol (RTP) [RFC3550], which can
confidentiality, message authentication, and replay protection to the provide confidentiality, message authentication, and replay
RTP traffic and to the control traffic for RTP, the Real-time protection to the RTP traffic and to the control traffic for RTP, the
Transport Control Protocol (RTCP). It is important to note that the Real-time Transport Control Protocol (RTCP). It is important to note
outgoing SRTP packets from a single endpoint may be originating from that the outgoing SRTP packets from a single endpoint may be
several independent data sources. originating from several independent data sources.
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].
The Advanced Encryption Standard (AES) is a block cipher that The Advanced Encryption Standard (AES) is a block cipher that
provides a high level of security, and can accept different key provides a high level of security, and can accept different key
sizes. Two families of AEAD algorithm families, AES Galois/Counter sizes. Two families of AEAD algorithm families, AES Galois/Counter
Mode (AES-GCM) and AES Counter with Cipher Block Chaining-Message Mode (AES-GCM) [GCM] and AES Counter with Cipher Block
Authentication Code (AES-CCM), are based upon AES. This Chaining-Message Authentication Code (AES-CCM) [RFC3610], are based
specification makes use of the AES versions that use 128-bit and upon AES. This specification makes use of the AES versions that use
256-bit keys, which we call AES-128 and AES-256, respectively. 128-bit and 256-bit keys, which we call AES-128 and AES-256,
respectively.
The Galois/Counter Mode of operation (GCM) and the Counter with The Galois/Counter Mode of operation (GCM) and the Counter with
Cipher Block Chaining-Message Authentication Code mode of operation Cipher Block Chaining-Message Authentication Code mode of operation
(CCM) are both AEAD modes of operation for block ciphers. Both use (CCM) are both AEAD modes of operation for block ciphers. Both use
counter mode to encrypt the data, an operation that can be counter mode to encrypt the data, an operation that can be
efficiently pipelined. Further, GCM authentication uses operations efficiently pipelined. Further, GCM authentication uses operations
that are particularly well suited to efficient implementation in that are particularly well suited to efficient implementation in
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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
c) A Key Derivation Function is applied to the shared master key c) A Key Derivation Function is applied to the shared master key
value to form separate encryption keys, authentication keys value to form separate encryption keys, authentication keys
and salting keys for SRTP and for SRTCP (a total of six 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 keys). This process is described in sections 4.3.1 and 4.3.3
of [RFC3711]. Since AEAD algorithms such as AES-CCM and of [RFC3711]. Since AEAD algorithms such as AES-CCM and
AES-GCM combine encryption and authentication into a single AES-GCM combine encryption and authentication into a single
process, AEAD algorithms do not make use of the process, AEAD algorithms do not make use of the
authentication keys. The master key MUST be at least as authentication keys. The master key MUST be at least as
large as the encryption key derived from it. large as the encryption key derived from it.
d) Each time an instantiation of AES-GCM or AES-CCM is invoked
to encrypt and authenticate an SRTP or SRTCP data packet a
new IV is used. SRTP combines the 4-octet synchronization
source (SSRC) identifier, the 4-octet rollover counter (ROC),
and the 2-octet sequence number(SEQ) with the 12-octet
encryption salt to form a 12-octet IV (see section 9.1).
SRTCP combines the SSRC and 31-bit SRTCP index with the
encryption salt to form a 12-octet IV (see section 10.1).
4. Terminology 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 Crypto Context: For the purposes of this document, a crypto
context is the outcome of any process which context is the outcome of any process which
results in authentication of each endpoint in the results in authentication of each endpoint in the
SRTP session and possession by each endpoint of a SRTP session and possession by each endpoint of a
shared secret master key. Various encryption shared secret master key. Various encryption
keys, authentication keys and salts are derived keys, authentication keys and salts are derived
from the master key. Aside from making from the master key. Aside from making
modifications to IANA registries to allow AES-GCM modifications to IANA registries to allow AES-GCM
and AES-CCM to work with SDES, DTLS and MIKEY, the and AES-CCM to work with SDES, DTLS and MIKEY,
details of how the master key is established are the details of how the master key is established
outside the scope of this document. Similarly any are outside the scope of this document.
mechanism for rekeying an existing Cipher Context Similarly any mechanism for rekeying an existing
is outside the scope of the document. Cipher Context is outside the scope of the
document.
Instantiation In AEAD, an instantiation is an (Encryption_key, Instantiation: In AEAD, an instantiation is an (Encryption_key,
salt) pair together with all of the data salt) pair together with all of the data
structures (for example, counters) needed for it structures (for example, counters) needed for it
to function properly. In SRTP/SRTCP, each to function properly. In SRTP/SRTCP, each
endpoint will need two instantiations of the AEAD endpoint will need two instantiations of the AEAD
algorithm for each master key in its possession, algorithm for each master key in its possession,
one for SRTP and one for SRTCP. one instantiation for SRTP traffic and one
instantiation for SRTCP traffic.
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
the appropriate instantiation of the AEAD of the appropriate instantiation of the AEAD
algorithm. algorithm.
In many applications, each endpoint will have one master key for In many applications, each endpoint will have one master key for
processing outbound data but may have one or more separate master processing outbound data but may have one or more separate master
keys for processing inbound data. keys for processing inbound data.
5. Generic AEAD Processing 5. Generic AEAD Processing
5.1. Types of Input Data 5.1. Types of Input Data
Associated Data This is data that is to be authenticated but Associated Data: This is data that is to be authenticated
not encrypted. but not encrypted.
Plaintext Data that is to be both encrypted and Plaintext: Data that is to be both encrypted and
authenticated. authenticated.
Raw Data Data that is to be neither encrypted nor Raw Data: Data that is to be neither encrypted nor
authenticated. authenticated.
Which portions of SRTP/SRTCP packets that are to be treated as Which portions of SRTP/SRTCP packets that are to be treated as
associated data, which are to be treated as plaintext, and which are associated data, which are to be treated as plaintext, and which are
to be treated as raw data are covered in sections 9.2, 10.2 and to be treated as raw data are covered in sections 9.2, 10.2 and
10.3. 10.3.
5.2. AEAD Invocation Inputs and Outputs 5.2. AEAD Invocation Inputs and Outputs
5.2.1. Encrypt Mode 5.2.1. Encrypt Mode
skipping to change at page 6, line 7 skipping to change at page 6, line 18
Tag_Size_Flag (CCM only*) One Octet Tag_Size_Flag (CCM only*) One Octet
Outputs Outputs
Ciphertext Bit string, length = Ciphertext Bit string, length =
length(Plaintext)+tag_length length(Plaintext)+tag_length
(*) For GCM, the algorithm choice determines the tag size. (*) 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 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 authentication tag is used, 6A if a 12-octet authentication tag is
used, and 7A if a 16-octet authentication tag is used. used, and 7A if a 16-octet authentication tag is used. This flag
refers to the size of the intrinsic authentication tag provided by
the AEAD algorithm.
5.2.2. Decrypt Mode 5.2.2. Decrypt Mode
Inputs: Inputs:
Encryption_key Octet string, either 16 or 32 Encryption_key Octet string, either 16 or 32
Octets long Octets long
Initialization_Vector Octet string, 12 octets long Initialization_Vector Octet string, 12 octets long
Associated_Data Octet string of variable length Associated_Data Octet string of variable length
Ciphertext Octet string of variable length Ciphertext Octet string of variable length
Tag_Size_Flag (CCM only*) One octet Tag_Size_Flag (CCM only*) One octet
skipping to change at page 6, line 30 skipping to change at page 6, line 43
Plaintext Bit string, length = Plaintext Bit string, length =
length(Ciphertext)-tag_length length(Ciphertext)-tag_length
Validity_Flag Boolean, TRUE if valid, Validity_Flag Boolean, TRUE if valid,
FALSE otherwise FALSE otherwise
(*) For GCM, the algorithm choice determines the tag size. (*) For GCM, the algorithm choice determines the tag size.
The Tag_Size_Flag, used in AES-CCM authentication, has the hex value The Tag_Size_Flag, used in AES-CCM authentication, has the hex value
5A if an 8-octet authentication tag is used, 6A if a 12-octet 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 authentication tag is used, and 7A if a 16-octet authentication tag
is used. is used. This flag refers to the size of the intrinsic
authentication tag provided by the AEAD algorithm.
5.3. Handling of AEAD Authentication 5.3. Handling of AEAD Authentication
AEAD requires that all incoming packets MUST pass AEAD authentication AEAD requires that all incoming packets MUST pass AEAD authentication
before any other action takes place. Plaintext and associated data before any other action takes place. Plaintext and associated data
MUST NOT be released until the AEAD authentication tag has been MUST NOT be released until the AEAD authentication tag has been
validated. Further, when GCM is being used, the ciphertext MUST NOT validated. Further, when GCM is being used, the ciphertext MUST NOT
be decrypted until the AEAD tag has been validated. be decrypted until the AEAD tag has been validated.
Should the AEAD tag prove to be invalid, the packet in question is to Should the AEAD tag prove to be invalid, the packet in question is to
be discarded and a Validation Error flag raised. Local policy be discarded and a Validation Error flag raised. Local policy
determines how this flag is to be handled and is outside the scope of determines how this flag is to be handled and is outside the scope of
this document. this document.
6. Counter Mode Encryption 6. Counter Mode Encryption
In both GCM and CCM, each outbound packet uses a 12-octet IV and an In both GCM and CCM, each outbound packet uses a 12-octet IV and an
encryption key to form two outputs, a 16-octet first_key_block which encryption key to form two outputs, a 16-octet first_key_block which
is used informing the authentication tag and keystream of octets is used in forming the authentication tag and a keystream of octets
which is XORed to the plaintext to form cipher. which is XORed to the plaintext to form cipher.
When GCM is used, the concatenation of a 12-octet IV, with a 4-octet When GCM is used, the concatenation of a 12-octet IV (see sections
block counter forms the input to AES. This is used to build a 9.1 and 10.1)with a 4-octet block counter forms the input to AES.
key_stream as follows: This is used to build a key_stream as follows:
def GCM_keystream( Plaintext, IV, Encryption_key ): def GCM_keystream( Plaintext, IV, Encryption_key ):
assert len(plaintext) <= (2**36) - 32 assert len(plaintext) <= (2**36) - 32
key_stream = "" key_stream = ""
block_counter = 1 block_counter = 1
first_key_block = AES_ENC( data=IV||block_counter, first_key_block = AES_ENC( data=IV||block_counter,
key=Encryption_key ) key=Encryption_key )
while len(key_stream) < len(Plaintext): while len(key_stream) < len(Plaintext):
block_counter = block_counter + 1 block_counter = block_counter + 1
key_block = AES_ENC( data=IV||block_counter, key_block = AES_ENC( data=IV||block_counter,
key=Encryption_key ) key=Encryption_key )
key_stream = key_stream || key_block key_stream = key_stream || key_block
key_stream = truncate( key_stream, len(Plaintext) ) key_stream = truncate( key_stream, len(Plaintext) )
return (first_key_block, key_stream ) return (first_key_block, key_stream )
In AES-CCM counter mode encryption, the AES data input consists of In AES-CCM counter mode encryption, the AES data input consists of
the concatenaton of a 1-octet flag,, a 12-octet IV, and a 3-octet the concatenation of a 1-octet flag,, a 12-octet IV, and a 3-octet
block counter. Note that in this apllication the flag octet will block counter. Note that in this application the flag octet will
always have the value 0x02 (see section 2.3 of [RFC3610]). A always have the value 0x02 (see section 2.3 of [RFC3610]). A
(first_key_block, keystream) pair is formed as follows: (first_key_block, keystream) pair is formed as follows:
def CCM_keystream( Plaintext, IV, Encryption_key ): def CCM_keystream( Plaintext, IV, Encryption_key ):
assert len(Plaintext) <= (2**28)-16 assert len(Plaintext) <= (2**28)-16
key_stream = "" key_stream = ""
block_counter = 0 block_counter = 0
first_key_block = AES_ENC( data=0x02||IV||block_counter, first_key_block = AES_ENC( data=0x02||IV||block_counter,
key=Encryption_key ) key=Encryption_key )
while len(key_stream)<len(Plaintext): while len(key_stream)<len(Plaintext):
skipping to change at page 8, line 7 skipping to change at page 8, line 22
With any counter mode, if the same (IV, Encryption_key) pair is used With any counter mode, if the same (IV, Encryption_key) pair is used
twice, precisely the same keystream is formed. As explained in twice, precisely the same keystream is formed. As explained in
section 9.1 of RFC 3711, this is a cryptographic disaster. For section 9.1 of RFC 3711, this is a cryptographic disaster. For
AES-GCM, the consequences of such a reuse are even worse than AES-GCM, the consequences of such a reuse are even worse than
explained in RFC 3711 because it would completely compromise the explained in RFC 3711 because it would completely compromise the
AES-GCM authentication mechanism. AES-GCM authentication mechanism.
7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12 7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12
AEAD_AEC_128_CCM and AEAD_AEC_256_CCM are defined in [RFC5116] with AEAD_AES_128_CCM and AEAD_AES_256_CCM are defined in [RFC5116] with
an authentication tag length of 16-octets. AEAD_AEC_128_CCM_8 and an authentication tag length of 16-octets. AEAD_AES_128_CCM_8 and
AEAD_AEC_256_CCM_8 are defined in [RFC6655] with an authentication AEAD_AES_256_CCM_8 are defined in [RFC6655] with an authentication
tag length of 8-octets. We require two new variants, tag length of 8-octets. We require two new variants,
AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12, with 12-octet AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12, with 12-octet
authentication tags. In each case the authentication tag is formed authentication tags. In each case the authentication tag is formed
by taking the 12 most significant octets (in network order) of the by taking the 12 most significant octets (in network order) of the
AEAD_AES_128/256_CCM authentication tag: AEAD_AES_128/256_CCM authentication tag:
+=====================+===========+==============+ +=====================+===========+==============+
| Name | Key Size | tag size (t) | | Name | Key Size | tag size (t) |
+=====================+===========+==============+ +=====================+===========+==============+
| AEAD_AEC_256_CCM_12 | 256 bits | 12 octets | | AEAD_AES_256_CCM_12 | 256 bits | 12 octets |
| AEAD_AEC_128_CCM_12 | 128 bits | 12 octets | | AEAD_AES_128_CCM_12 | 128 bits | 12 octets |
+=====================+===========+==============+ +=====================+===========+==============+
8. Unneeded SRTP/SRTCP Fields 8. Unneeded SRTP/SRTCP Fields
AEAD counter mode encryption removes the need for certain existing AEAD counter mode encryption removes the need for certain existing
SRTP/SRTCP mechanisms. SRTP/SRTCP mechanisms.
8.1. SRTP/SRTCP Authentication Field 8.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
skipping to change at page 8, line 48 skipping to change at page 9, line 14
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.
8.2. RTP Padding 8.2. RTP Padding
Neither AES-GCM not AES-CCM requires that the data be padded out to a Neither AES-GCM not AES-CCM requires that the data be padded out to a
specific block size, reducing the need to use the padding mechanism specific block size, reducing the need to use the padding mechanism
provided by RTP. It is RECOMENDED that the RTP padding mechanism not provided by RTP. It is RECOMMENDED that the RTP padding mechanism
be used unless it is necessary to disguise the length of the not be used unless it is necessary to disguise the length of the
underlying plaintext. underlying plaintext.
9. AES-GCM/CCM processing for SRTP 9. AES-GCM/CCM processing for SRTP
9.1. SRTP IV formation for AES-GCM and AES-CCM 9.1. SRTP IV formation for AES-GCM and AES-CCM
The 12 octet initialization vector used by both AES-GCM and AES-CCM The 12 octet initialization vector used by both AES-GCM and AES-CCM
SRTP is formed by first concatenating 2-octets of zeroes, the 4-octet SRTP is formed by first concatenating 2-octets of zeroes, the 4-octet
SSRC, the 4-octer Rollover Counter (ROC) and the two octet sequence SSRC, the 4-octer Rollover Counter (ROC) and the two octet sequence
number SEQ. The resulting 12-octet value is then XORed to the number SEQ. The resulting 12-octet value is then XORed to the
skipping to change at page 9, line 32 skipping to change at page 9, line 45
| 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
octets of the IV are the fixed field and the last six octets are the
invocation field.
9.2. Data Types in SRTP Packets 9.2. Data Types in SRTP Packets
All SRTP packets MUST be both authenticated and encrypted. The data All SRTP packets MUST be both authenticated and encrypted. The data
fields within the SRTP packets are broken into Associated Data, fields within the SRTP packets are broken into Associated Data,
Plaintext and Raw Data as follows (see figure 2): Plaintext and Raw Data as follows (see figure 2):
Associated Data The version (2 bits), padding flag (1 bit), Associated Data: The version (2 bits), padding flag (1 bit),
extension flag (1 bit), CSRC count (4 bits), extension flag (1 bit), CSRC count (4 bits),
sequence number (16 bits), timestamp (32 bits), sequence number (16 bits), timestamp (32 bits),
SSRC (32 bits), optional contributing source SSRC (32 bits), optional contributing source
identifiers (CSRCs, 32 bits each), and optional identifiers (CSRCs, 32 bits each), and optional
RTP extension (variable length). RTP extension (variable length).
Plaintext The RTP payload (variable length), RTP padding (if Plaintext: The RTP payload (variable length), RTP padding
used, variable length), and RTP pad count ( if (if used, variable length), and RTP pad count (
used, 1 octet). if used, 1 octet).
Raw Data The optional 32-bit SRTP MKI and the 32-bit SRTP Raw Data: The optional 32-bit SRTP MKI and the 32-bit SRTP
authentication tag (whose use is NOT authentication tag (whose use is NOT
RECOMMENDED). 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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
skipping to change at page 10, line 53 skipping to change at page 11, line 13
consisting solely of the authentication tag. This tag is to be consisting solely of the authentication tag. This tag is to be
placed immediately before the optional SRTP MKI and SRTP placed immediately before the optional SRTP MKI and SRTP
authentication tag fields. authentication tag fields.
9.3. Prevention of SRTP IV Reuse 9.3. Prevention of SRTP IV Reuse
In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC) In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC)
triple is never used twice with the same master key. There are two triple is never used twice with the same master key. There are two
phases to this issue. phases to this issue.
Counter Management A rekey MUST be performed to establish a new Counter Management: A rekey MUST be performed to establish a new
master key before the (ROC,SEQ) pair cycles back master key before the (ROC,SEQ) pair cycles
to its original value. back to its original value.
SSRC Management The set of all SSRC values must be partitioned SSRC Management: For a given master key, the set of all SSRC
into disjoint pools, one pool for each endpoint values used with that master key must be
using the master key to originate outbound partitioned into disjoint pools, one pool for
data. Each such endpoint MUST only issue SSRC each endpoint using that master key to
values from the pool it has been assigned. originate outbound data. Each such originating
Further, each endpoint MUST maintain a history endpoint MUST only issue SSRC values from the
of outbound SSRC identifiers that it has issued pool it has been assigned. Further, each
within the lifetime of the current master key, originating endpoint MUST maintain a history of
and when a new synchronization source requests outbound SSRC identifiers that it has issued
an SSRC identifier it MUST NOT be given an within the lifetime of the current master key,
identifier that has been previously issued. A and when a new synchronization source requests
rekey MUST be performed before its pool of SSRC an SSRC identifier it MUST NOT be given an
values is exhausted. identifier that has been previously issued. A
rekey MUST be performed before any of the
originating endpoints using that master key
exhausts its pool of SSRC values.
10. AES-GCM/CCM Processing of SRTCP Compound Packets 10. AES-GCM/CCM Processing of SRTCP Compound Packets
All SRTCP compound packets MUST be authenticated, but unlike SRTP, All SRTCP compound packets MUST be authenticated, but unlike SRTP,
SRTCP packet encryption is optional. A sender can select which SRTCP packet encryption is optional. A sender can select which
packets to encrypt, and indicates this choice with a 1-bit encryption packets to encrypt, and indicates this choice with a 1-bit encryption
flag (located just before the 31-bit SRTCP index) flag (located just before the 31-bit SRTCP index)
10.1. SRTCP IV formation for AES-GCM and AES-CCM 10.1. SRTCP IV formation for AES-GCM and AES-CCM
skipping to change at page 11, line 52 skipping to change at page 12, line 20
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| Encryption Salt |->(+) | Encryption Salt |->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| Initialization Vector |<--+ | Initialization Vector |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: SRTCP Initialization Vector formation 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 octets are the
invocation field.
10.2. Data Types in Encrypted SRTCP Compound Packets 10.2. Data Types in Encrypted SRTCP Compound Packets
When the encryption flag is set to 1, the SRTCP packet is broken into When the encryption flag is set to 1, the SRTCP packet is broken into
plaintext, associated data, and raw (untouched) data as listed below plaintext, associated data, and raw (untouched) data as listed below
(see figure 4): (see figure 4):
Associated Data The packet version (2 bits), padding flag (1 bit), Associated Data: The packet version (2 bits), padding flag (1
reception report count (5 bits), packet type (8 bit), reception report count (5 bits), packet
bits), length (2 octets), SSRC (4 octets), type (8 bits), length (2 octets), SSRC (4
encryption flag (1 bit) and SRTCP index (31 octets), encryption flag (1 bit) and SRTCP index
bits). (31 bits).
Raw Data The 32-bit optional SRTCP MKI index and 32-bit Raw Data: The 32-bit optional SRTCP MKI index and 32-bit
SRTCP authentication tag (whose use is NOT SRTCP authentication tag (whose use is NOT
RECOMMENDED). RECOMMENDED).
Plaintext All other data. Plaintext: All other data.
Note that the plaintext comes in one contiguous field. Since the 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 cipher is larger than the plaintext by exactly the length of the
AEAD authentication tag, the corresponding SRTCP encrypted packet AEAD authentication tag, the corresponding SRTCP encrypted packet
replaces the plaintext field with a slightly larger field containing replaces the plaintext field with a slightly larger field containing
the cipher. Even if the plaintext field is empty, AEAD encryption the cipher. Even if the plaintext field is empty, AEAD encryption
must still be performed, with the resulting cipher consisting solely must still be performed, with the resulting cipher consisting solely
of the authentication tag. This tag is to be placed immediately of the authentication tag. This tag is to be placed immediately
before the encryption flag and SRTCP index. before the encryption flag and SRTCP index.
skipping to change at page 13, line 47 skipping to change at page 13, line 47
R = 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.
10.3. Data Types in Unencrypted SRTCP Compound Packets 10.3. Data Types in Unencrypted SRTCP Compound Packets
When the encryption flag is set to 0, the SRTCP compound packet is When the encryption flag is set to 0, the SRTCP compound packet is
broken into plaintext, associated data, and raw (untouched) data as broken into plaintext, associated data, and raw (untouched) data as
follows (see figure 5): follows (see figure 5):
Plaintext None. Plaintext: None.
Raw Data The 32-bit optional SRTCP MKI index and 32-bit Raw Data: The 32-bit optional SRTCP MKI index and 32-bit
SRTCP authentication tag (whose use is NOT SRTCP authentication tag (whose use is NOT
RECOMMENDED). RECOMMENDED).
Associated Data All other data. Associated Data: All other data.
Even though there is no plaintext in this RTCP packet, AEAD Even though there is no plaintext in this RTCP packet, AEAD
encryption returns a cipher field which is precisely the length of encryption returns a cipher field which is precisely the length of
the AEAD authentication tag. This cipher is to be placed before the the AEAD authentication tag. This cipher is to be placed before the
Encryption flag and the SRTCP index in the authenticated SRTCP Encryption flag and the SRTCP index in the authenticated SRTCP
packet. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 18 skipping to change at page 15, line 18
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.
11.1. Generic AEAD Parameter Constraints 11.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 12 octets.
length length
N_MAX maximum nonce (IV) MUST be at least 12 octets N_MAX maximum nonce (IV) MUST be 12 octets.
length length
C_MAX maximum ciphertext GCM: MUST be at most 2^36-16 octets C_MAX maximum ciphertext GCM: MUST be at most 2^36-16 octets.
length per invocation CCM: MUST be at most 2^24+16 octets length per invocation CCM: MUST be at most 2^24+16 octets
C_MAX values less than 2232
are discouraged
The upper bound on C_MAX are based on purely cryptographic The values for C_MAX are based on purely cryptographic
considerations. The lower bound on C_MAX is obtained by subtracting considerations.
away a 20-octet IP header, 8-octet UDP header, and 12-octet RTP
header from the maximum transmission unit (MTU) of 2272.
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 AEAD 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 24 bits for CCM, Block Counter size MUST be 24 bits for CCM,
MUST be 32 bits for GCM MUST be 32 bits for GCM
The reader is reminded that the ciphertext is longer than the The reader is reminded that the ciphertext is longer than the
plaintext by exactly the length of the AEAD authentication tag. plaintext by exactly the length of the AEAD authentication tag.
11.2. AES-GCM for SRTP/SRTCP 11.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 AEAD 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
skipping to change at page 16, line 31 skipping to change at page 16, line 27
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-CCM 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]. Four of the six CCM algorithms used in this be found in [RFC5116]. Four of the six CCM algorithms used in this
document are defined in previous RFCs, while two, AEAD_AES_128_CCM_12 document are defined in previous RFCs, while two, AEAD_AES_128_CCM_12
and AEAD_AES_256_CCM_12, are defined in section 7 of this document. and AEAD_AES_256_CCM_12, are defined in section 7 of this document.
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 AEAD Tag Size Reference
================================================================ ================================================================
AEAD_AES_128_CCM 128 bits 16 octets [RFC5116] AEAD_AES_128_CCM 128 bits 16 octets [RFC5116]
AEAD_AES_256_CCM 256 bits 16 octets [RFC5116] AEAD_AES_256_CCM 256 bits 16 octets [RFC5116]
AEAD_AES_128_CCM_12 128 bits 12 octets see section 7 AEAD_AES_128_CCM_12 128 bits 12 octets see section 7
AEAD_AES_256_CCM_12 256 bits 12 octets see section 7 AEAD_AES_256_CCM_12 256 bits 12 octets see section 7
AEAD_AES_128_CCM_8 128 bits 8 octets [RFC6655] AEAD_AES_128_CCM_8 128 bits 8 octets [RFC6655]
AEAD_AES_256_CCM_8 256 bits 8 octets [RFC6655] AEAD_AES_256_CCM_8 256 bits 8 octets [RFC6655]
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 flag octet used in counter node encryptionn, In addition to the flag octet used in counter mode encryption,
AES-CCM authentications also useus a flag octet that conveys AES-CCM authentications also uses a flag octet that conveys
information about the length of the authentication tag, length of the information about the length of the authentication tag, length of the
block counter, and presence of additional authenticated data (see block counter, and presence of additional authenticated data (see
section 2.2 of [RFC 3610]). For AES-CCM in SRTP/SRTCP, the flag section 2.2 of [RFC 3610]). For AES-CCM in SRTP/SRTCP, the flag
octet has the hex value 5A if an 8-octet authentication tag is used, octet has the hex value 5A if an 8-octet AEAD authentication tag is
6A if a 12-octet authentication tag is used, and 7A if a 16-octet used, 6A if a 12-octet AEAD authentication tag is used, and 7A if a
authentication tag is used. The flag octet is one of the inputs to 16-octet AEAD authentication tag is used. The flag octet is one of
AES during the counter mode encryption of the plaintext. the inputs to AES during the counter mode encryption of the
plaintext.
12. Key Derivation Functions 12. 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
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].
13. Security Considerations 13. Security Considerations
skipping to change at page 19, line 15 skipping to change at page 19, line 14
14.2. DTLS 14.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, we request IANA register the following SRTP Protection DTLS-SRTP, we request IANA register the following SRTP Protection
Profiles: Profiles:
AEAD_AES_128_CCM AEAD_AES_128_CCM
cipher: AES_128_CCM cipher: AES_128_CCM
cipher_key_length: 128 bits cipher_key_length: 128 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 16 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_CCM AEAD_AES_256_CCM
cipher: AES_256_CCM cipher: AES_256_CCM
cipher_key_length: 256 bits cipher_key_length: 256 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 16 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_CCM_8 AEAD_AES_128_CCM_8
cipher: AES_128_CCM cipher: AES_128_CCM
cipher_key_length: 128 bits cipher_key_length: 128 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 8 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_CCM_8 AEAD_AES_256_CCM_8
cipher: AES_256_CCM cipher: AES_256_CCM
cipher_key_length: 256 bits cipher_key_length: 256 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 8 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_CCM_12 AEAD_AES_128_CCM_12
cipher: AES_128_CCM cipher: AES_128_CCM
cipher_key_length: 128 bits cipher_key_length: 128 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 12 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_CCM_12 AEAD_AES_256_CCM_12
cipher: AES_256_CCM cipher: AES_256_CCM
cipher_key_length: 256 bits cipher_key_length: 256 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 12 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_GCM AEAD_AES_128_GCM
cipher: AES_128_GCM cipher: AES_128_GCM
cipher_key_length: 128 bits cipher_key_length: 128 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 16 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_GCM AEAD_AES_256_GCM
cipher: AES_256_GCM cipher: AES_256_GCM
cipher_key_length: 256 bits cipher_key_length: 256 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 16 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_GCM_8 AEAD_AES_128_GCM_8
cipher: AES_128_GCM cipher: AES_128_GCM
cipher_key_length: 128 bits cipher_key_length: 128 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 8 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_GCM_8 AEAD_AES_256_GCM_8
cipher: AES_256_GCM cipher: AES_256_GCM
cipher_key_length: 256 bits cipher_key_length: 256 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 8 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_128_GCM_12 AEAD_AES_128_GCM_12
cipher: AES_128_GCM cipher: AES_128_GCM
cipher_key_length: 128 bits cipher_key_length: 128 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 12 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets
AEAD_AES_256_GCM_12 AEAD_AES_256_GCM_12
cipher: AES_256_GCM cipher: AES_256_GCM
cipher_key_length: 256 bits cipher_key_length: 256 bits
cipher_salt_length: 96 bits cipher_salt_length: 96 bits
maximum lifetime: at most 2^31 SRTCP packets and aead_auth_tag_length: 12 octets
at most 2^48 SRTP packets auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
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 Note that these SRTP Protection Profiles do not specify an
auth_function, auth_key_length, or auth_tag_length because all of auth_function, auth_key_length, or auth_tag_length because all of
these profiles use AEAD algorithms, and thus do not use a separate these profiles use AEAD algorithms, and thus do not use a separate
auth_function, auth_key, or auth_tag. auth_function, auth_key, or auth_tag. The term aead_auth_tag_length
is used to emphasize that this refers to the authentication tag
provided by the AEAD algorithm and that this tag is not located in
the authentication tag field provided by SRTP/SRTCP.
14.3. MIKEY 14.3. MIKEY
In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830],
IANA maintains several Payload Name Spaces under Multimedia Internet IANA maintains several Payload Name Spaces under Multimedia Internet
KEYing (MIKEY). This document requires additions to two of the lists KEYing (MIKEY). This document requires additions to two of the lists
maintained under MIKEY Security Protocol Parameters. maintained under MIKEY Security Protocol Parameters.
On the SRTP policy Type/Value list (derived from Table 6.10.1.a of On the SRTP policy Type/Value list (derived from Table 6.10.1.a of
[RFC3830]) we request the following addition: [RFC3830]) we request the following addition:
Type | Meaning | Possible values Type | Meaning | Possible values
---------------------------------------------------------------- ----------------------------------------------------------------
skipping to change at page 21, line 21 skipping to change at page 22, line 17
Type | Meaning | Possible values Type | Meaning | Possible values
---------------------------------------------------------------- ----------------------------------------------------------------
TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) TBD | AEAD authentication tag length | 8, 12, or 16 (in octets)
On the Encryption Algorithm List (derived from Table 6.10.1.b of On the Encryption Algorithm List (derived from Table 6.10.1.b of
[RFC3830]) we request the following additions: [RFC3830]) we request the following additions:
SRTP encr alg. | Value | Default Session Encr. Key Length SRTP encr alg. | Value | Default Session Encr. Key Length
----------------------------------------------------------- -----------------------------------------------------------
AES-CCM | TBD | 16 octets AES-CCM | TBD | 16 octets
AES-GCM | TBD | 16 octets AES-GCM | TBD | 16 octets
The SRTP encryption algorithm, session encryption key length, and The SRTP encryption algorithm, session encryption key length, and
AEAD authentication tag values received from MIKEY fully determine AEAD authentication tag values received from MIKEY fully determine
the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is
described in section 15. described in section 15.
14.4. AEAD registry 14.4. AEAD registry
We request that IANA make the following additions to the AEAD We request that IANA make the following additions to the AEAD
registry: registry:
AEAD_AES_128_CCM_12 = TBD AEAD_AES_128_CCM_12 = TBD
AEAD_AES_256_CCM_12 = TBD AEAD_AES_256_CCM_12 = TBD
15. Parameters for use with MIKEY 15. Parameters for use with MIKEY
MIKEY specifies the algorithm family separately from the key length MIKEY specifies the algorithm family separately from the key length
(which is specified by the Session Encryption key length ) and the (which is specified by the Session Encryption key length ) and the
authentication tag length (specified by AEAD Auth. tag length). authentication tag length (specified by AEAD Auth. tag length).
+------------+-------------+-------------+ +------------+-------------+-------------+
| Encryption | Encryption | AEAD Auth. | | Encryption | Encryption | AEAD Auth. |
| Algorithm | Key Length | Tag Length | | Algorithm | Key Length | Tag Length |
skipping to change at page 23, line 23 skipping to change at page 24, line 23
[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.
[RFC3550] Casner, S., Frederick, R., and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 3550,
July 2003.
[RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, March 2004. CBC-MAC (CCM)", RFC 3610, March 2004.
[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, September 2003. (SRTP)", RFC 3711, September 2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and
Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
 End of changes. 68 change blocks. 
207 lines changed or deleted 271 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/