draft-ietf-avtcore-srtp-aes-gcm-11.txt   draft-ietf-avtcore-srtp-aes-gcm-12.txt 
Network Working Group D. McGrew Network Working Group D. McGrew
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Intended Status: Standards Track K. Igoe Intended Status: Standards Track K. Igoe
Expires: October 03, 2014 National Security Agency Expires: November 22, 2014 National Security Agency
April 01, 2014 May 21, 2014
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-11 draft-ietf-avtcore-srtp-aes-gcm-12
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 October 03, 2014. This Internet-Draft will expire on November 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
5.2.2. Decrypt Mode...........................................6 5.2.2. Decrypt Mode...........................................6
5.3. Handling of AEAD Authentication.............................7 5.3. Handling of AEAD Authentication.............................7
6. Counter Mode Encryption..........................................7 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.............................9 8.1. SRTP/SRTCP Authentication Field.............................9
8.2. RTP Padding.................................................9 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.................................10 9.2. Data Types in SRTP Packets.................................10
9.3. Handling Header Extensions.................................12 9.3. Handling Header Extensions.................................11
9.4. Prevention of SRTP IV Reuse................................13 9.4. Prevention of SRTP IV Reuse................................12
10. AES-GCM/CCM Processing of SRTCP Compound Packets...............14 10. AES-GCM/CCM Processing of SRTCP Compound Packets...............13
10.1. SRTCP IV formation for AES-GCM and AES-CCM................14 10.1. SRTCP IV formation for AES-GCM and AES-CCM................13
10.2. Data Types in Encrypted SRTCP Compound Packets............14 10.2. Data Types in Encrypted SRTCP Compound Packets............14
10.3. Data Types in Unencrypted SRTCP Compound Packets..........16 10.3. Data Types in Unencrypted SRTCP Compound Packets..........15
10.4. Prevention of SRTCP IV Reuse..............................17 10.4. Prevention of SRTCP IV Reuse..............................16
11. Constraints on AEAD for SRTP and SRTCP.........................17 11. Constraints on AEAD for SRTP and SRTCP.........................16
12. Key Derivation Functions.......................................18 12. Key Derivation Functions.......................................17
13. Summary of Algorithm Characteristics...........................19 13. Summary of Algorithm Characteristics...........................17
13.1. AES-GCM for SRTP/SRTCP....................................19 13.1. AES-GCM for SRTP/SRTCP....................................17
13.2. AES-CCM for SRTP/SRTCP....................................21 13.2. AES-CCM for SRTP/SRTCP....................................20
14. Security Considerations........................................24 14. Security Considerations........................................22
14.1. Handling of Security Critical Parameters..................24 14.1. Handling of Security Critical Parameters..................23
14.2. Size of the Authentication Tag............................25 14.2. Size of the Authentication Tag............................23
15. IANA Considerations............................................26 15. IANA Considerations............................................24
15.1. SDES......................................................26 15.1. SDES......................................................25
15.2. DTLS......................................................27 15.2. DTLS......................................................25
15.3. MIKEY.....................................................30 15.3. MIKEY.....................................................28
15.4. AEAD registry.............................................31 15.4. AEAD registry.............................................29
16. Parameters for use with MIKEY..................................31 16. Parameters for use with MIKEY..................................29
17. Acknowledgements...............................................32 17. Acknowledgements...............................................30
18. References.....................................................33 18. References.....................................................31
18.1. Normative References......................................33 18.1. Normative References......................................31
18.2. Informative References....................................35 18.2. Informative References....................................32
1. Introduction 1. Introduction
The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
of the Real-time Transport Protocol (RTP) [RFC3550], which can of the Real-time Transport Protocol (RTP) [RFC3550], which can
provide confidentiality, message authentication, and replay provide confidentiality, message authentication, and replay
protection to the RTP traffic and to the control traffic for RTP, the protection to the RTP traffic and to the control traffic for RTP, the
Real-time Transport Control Protocol (RTCP). It is important to note Real-time Transport Control Protocol (RTCP). It is important to note
that the outgoing SRTP packets from a single endpoint may be that the outgoing SRTP packets from a single endpoint may be
originating from several independent data sources. originating from several independent data sources.
skipping to change at page 8, line 8 skipping to change at page 8, line 8
key_stream = truncate( key_stream, Plaintext_len ) key_stream = truncate( key_stream, Plaintext_len )
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 concatenation 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 application 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, key_stream) pair is formed as follows: (first_key_block, key_stream) pair is formed as follows:
def CCM_keystream( Plaintext_len, IV, Encryption_key ): def CCM_keystream( Plaintext_len, IV, Encryption_key ):
assert Plaintext_len <= (2**28)-16 ## measured in octets assert Plaintext_len <= (2**24)-1 ## measured in octets
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)<Plaintext_len: while len(key_stream)<Plaintext_len:
block_counter = block_counter + 1 block_counter = block_counter + 1
key_block = AES_ENC( data=0x02||IV||block_counter, key_block = AES_ENC( data=0x02||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, Plaintext_len ) key_stream = truncate( key_stream, Plaintext_len )
return (first_key_block, key_stream ) return (first_key_block, key_stream )
These keystream generation processes allow for a keystream of length These keystream generation processes allow for a keystream of length
up to (2^28)-16 octets for AES-CCM and up to (2^36)-32 octets for up to (2^24)-1 octets for AES-CCM and up to (2^36)-32 octets for
AES-GCM. AES-GCM.
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 GCM section 9.1 of RFC 3711, this is a cryptographic disaster. For GCM
the consequences are even worse as also the integrity is compromised, the consequences are even worse since such a reuse compromises GCM's
and not only for the current packet stream, but for all future use of integrity mechanism not only for the current packet stream but for
encryption_key. all future uses of the current encryption_key.
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_AES_128_CCM and AEAD_AES_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_AES_128_CCM_8 and an authentication tag length of 16-octets. AEAD_AES_128_CCM_8 and
AEAD_AES_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
skipping to change at page 9, line 34 skipping to change at page 9, line 34
Neither AES-GCM nor AES-CCM requires that the data be padded out to a Neither AES-GCM nor 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 RECOMMENDED that the RTP padding mechanism provided by RTP. It is RECOMMENDED that the RTP padding mechanism
not 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
SRTP is formed by first concatenating 2-octets of zeroes, the 4-octet
SSRC, the 4-octet Rollover Counter (ROC) and the two octet sequence
number SEQ. The resulting 12-octet value is then XORed to the
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 | ROC | SEQ |---+ |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.
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
SSRC, the 4-octet Rollover Counter (ROC) and the two octet sequence
number SEQ. The resulting 12-octet value is then XORed to the
12-octet salt to form the 12-octet IV.
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 V (2 bits), padding flag P (1 bit), Associated Data: The version V (2 bits), padding flag P (1 bit),
extension flag X (1 bit), CSRC count CC (4 bits), extension flag X (1 bit), CSRC count CC (4 bits),
marker M (1 bit), the Payload Type PT (8 bits), marker M (1 bit), the Payload Type PT (8 bits),
skipping to change at page 12, line 5 skipping to change at page 11, line 5
P | +-------------------------------+ P | +-------------------------------+
P | | RTP padding | RTP pad count | P | | RTP padding | RTP pad count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
Figure 2: Structure of an SRTP packet before Authenticated Figure 2: Structure of an SRTP packet before Authenticated
Encryption Encryption
Since the AEAD ciphertext is larger than the plaintext by exactly the
length of the AEAD authentication tag, the corresponding SRTP
encrypted packet replaces the plaintext field by a slightly larger
field containing the cipher. Even if the plaintext field is empty,
AEAD encryption must still be performed, with the resulting cipher
consisting solely of the authentication tag. This tag is to be
placed immediately before the optional SRTP MKI and SRTP
authentication tag fields.
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| PT | sequence number | A |V=2|P|X| CC |M| PT | 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) |
skipping to change at page 12, line 36 skipping to change at page 11, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C = Cipertext (encrypted and authenticated) C = Cipertext (encrypted and authenticated)
A = Associated Data (authenticated only) A = Associated Data (authenticated only)
R = neither encrypted nor authenticated, added R = neither encrypted nor authenticated, added
after authenticated encryption completed after authenticated encryption completed
Figure 3: Structure of an SRTP packet after Authenticated Figure 3: Structure of an SRTP packet after Authenticated
Encryption Encryption
Since the AEAD ciphertext is larger than the plaintext by exactly the
length of the AEAD authentication tag, the corresponding SRTP
encrypted packet replaces the plaintext field by a slightly larger
field containing the cipher. Even if the plaintext field is empty,
AEAD encryption must still be performed, with the resulting cipher
consisting solely of the authentication tag. This tag is to be
placed immediately before the optional SRTP MKI and SRTP
authentication tag fields.
9.3. Handling Header Extensions 9.3. Handling Header Extensions
RTP header extensions were first defined in RFC 3550. RFC 6904 RTP header extensions were first defined in RFC 3550. RFC 6904
[RFC6904] describes how these header extensions are to be encrypted [RFC6904] describes how these header extensions are to be encrypted
in SRTP. in SRTP.
When RFC 6904 is in use, a separate keystream is generated to encrypt When RFC 6904 is in use, a separate keystream is generated to encrypt
selected RTP header extension elements. For the AEAD_AES_128_GCM and selected RTP header extension elements. For the AEAD_AES_128_GCM and
the AEAD_AES_128_CCM algorithms, this keystream MUST be generated in the AEAD_AES_128_CCM algorithms, this keystream MUST be generated in
the manner defined in [RFC6904] using the AES_128_CM transform. For the manner defined in [RFC6904] using the AES_128_CM transform. For
skipping to change at page 14, line 45 skipping to change at page 14, line 7
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+ |
| Initialization Vector |<--+ | Initialization Vector |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: SRTCP Initialization Vector formation Figure 4: SRTCP Initialization Vector formation
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
plaintext, associated data, and raw (untouched) data as listed below
(see figure 5):
Associated Data: The packet version V (2 bits), padding flag P (1
bit), reception report count RC (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 SRTCP encrypted packet
replaces the plaintext field with a slightly larger field containing
the cipher. Even if the plaintext field is empty, AEAD encryption
must still be performed, with the resulting cipher consisting solely
of the authentication tag. This tag is to be placed immediately
before the encryption flag and SRTCP index.
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | report block 1 : P | report block 1 :
skipping to change at page 16, line 42 skipping to change at page 14, line 44
R : SRTCP authentication tag (NOT RECOMMENDED) : R : SRTCP 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)
R = neither encrypted nor authenticated, added after R = neither encrypted nor authenticated, added after
encryption encryption
Figure 5: AEAD SRTCP inputs when encryption flag = 1. Figure 5: AEAD SRTCP inputs when encryption flag = 1.
10.3. Data Types in Unencrypted 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 shown above
When the encryption flag is set to 0, the SRTCP compound packet is in figure 5):
broken into plaintext, associated data, and raw (untouched) data as
follows (see figure 6):
Plaintext: None. Associated Data: The packet version V (2 bits), padding flag P (1
bit), reception report count RC (5 bits), packet
type (8 bits), length (2 octets), SSRC (4
octets), encryption flag (1 bit) and SRTCP index
(31 bits).
Raw Data: The variable length optional SRTCP MKI index and 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. Plaintext: All other data.
Even though there is no plaintext in this RTCP packet, AEAD Note that the plaintext comes in one contiguous field. Since the
encryption returns a cipher field which is precisely the length of AEAD cipher is larger than the plaintext by exactly the length of the
the AEAD authentication tag. This cipher is to be placed before the AEAD authentication tag, the corresponding SRTCP encrypted packet
Encryption flag and the SRTCP index in the authenticated SRTCP replaces the plaintext field with a slightly larger field containing
packet. the cipher. Even if the plaintext field is empty, AEAD encryption
must still be performed, with the resulting cipher consisting solely
of the authentication tag. This tag is to be placed immediately
before the encryption flag and SRTCP index.
10.3. Data Types in Unencrypted SRTCP Compound Packets
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 17, line 45 skipping to change at page 16, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R : authentication tag (NOT RECOMMENDED) : R : authentication tag (NOT RECOMMENDED) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A = Associated Data (to be authenticated only) A = Associated Data (to be authenticated only)
R = neither encrypted nor authenticated, added after R = neither encrypted nor authenticated, added after
encryption encryption
Figure 6: AEAD SRTCP inputs when encryption flag = 0 Figure 6: AEAD SRTCP inputs when encryption flag = 0
When the encryption flag is set to 0, the SRTCP compound packet is
broken into plaintext, associated data, and raw (untouched) data as
follows (see figure 6):
Plaintext: None.
Raw Data: The variable length optional SRTCP MKI index and
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.
10.4. Prevention of SRTCP IV Reuse 10.4. Prevention of SRTCP IV Reuse
A new master key MUST be established before the 31-bit SRTCP index A new master key MUST be established before the 31-bit SRTCP index
cycles back to its original value. Ideally, a rekey should be cycles back to its original value. Ideally, a rekey should be
performed and a new master key put in place well before the SRTCP performed and a new master key put in place well before the SRTCP
cycles back to the starting value. cycles back to the starting value.
The comments on SSRC management in section 9.4 also apply. The comments on SSRC management in section 9.4 also apply.
11. Constraints on AEAD for SRTP and SRTCP 11. Constraints on AEAD for SRTP and SRTCP
skipping to change at page 18, line 4 skipping to change at page 16, line 33
10.4. Prevention of SRTCP IV Reuse 10.4. Prevention of SRTCP IV Reuse
A new master key MUST be established before the 31-bit SRTCP index A new master key MUST be established before the 31-bit SRTCP index
cycles back to its original value. Ideally, a rekey should be cycles back to its original value. Ideally, a rekey should be
performed and a new master key put in place well before the SRTCP performed and a new master key put in place well before the SRTCP
cycles back to the starting value. cycles back to the starting value.
The comments on SSRC management in section 9.4 also apply. The comments on SSRC management in section 9.4 also apply.
11. Constraints on AEAD for SRTP and SRTCP 11. 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.
All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three All AEAD algorithms used with SRTP/SRTCP MUST satisfy the five
constraints listed below: constraints listed below:
PARAMETER Meaning Value PARAMETER Meaning Value
A_MAX maximum associated MUST be at least 12 octets. A_MAX maximum associated MUST be at least 12 octets.
data length data length
N_MIN minimum nonce (IV) MUST be 12 octets. N_MIN minimum nonce (IV) MUST be 12 octets.
length length
N_MAX maximum nonce (IV) MUST be 12 octets. N_MAX maximum nonce (IV) MUST be 12 octets.
length length
P_MAX maximum plaintext GCM: MUST be <= 2^36-32 octets.
length per invocation CCM: MUST be <= 2^24-1 octets.
C_MAX maximum ciphertext GCM: MUST be <= 2^36-16 octets. C_MAX maximum ciphertext GCM: MUST be <= 2^36-16 octets.
length per invocation CCM: MUST be <= 2^28 octets. length per invocation CCM: MUST be <= 2^24+15 octets.
The values for C_MAX are based on purely cryptographic For GCM the value of P_MAX is based on purely cryptographic
considerations. considerations. CCM requires the lenght of the plaintext, measured
in octets, must fit in a 24-bit field. Hence P_MAX is 2^24-1..
For sake of clarity we specify two additional parameters: For sake of clarity we specify two additional parameters:
AEAD 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
skipping to change at page 18, line 49 skipping to change at page 17, line 32
plaintext by exactly the length of the AEAD authentication tag. plaintext by exactly the length of the AEAD authentication tag.
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 [RFC6188] use the AES_256_CM_PRF Key Derivation Function described in
. [RFC6188].
13. Summary of Algorithm Characteristics 13. Summary of Algorithm Characteristics
For convenience, much of the information about the use of AES-GCM and For convenience, much of the information about the use of AES-GCM and
AES-CCM algorithms in SRTP is collected in the tables contained in AES-CCM algorithms in SRTP is collected in the tables contained in
this section. this section.
13.1. AES-GCM for SRTP/SRTCP 13.1. 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
skipping to change at page 21, line 42 skipping to change at page 20, line 28
13.2. AES-CCM for SRTP/SRTCP 13.2. 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-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.
Any implementation of AES-CCM SRTP/SRTCP MUST support both
AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet
AEAD authentication tags), and MAY support the other four variants.
Name Key Size AEAD 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]
Table 8: AES-CCM algorithms for SRTP/SRTCP
Any implementation of AES-CCM SRTP/SRTCP MUST support both Table 8: AES-CCM algorithms for SRTP/SRTCP
AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet
AEAD authentication tags), and MAY support the other four variants.
In addition to the flag octet used in counter mode encryption, In addition to the flag octet used in counter mode encryption,
AES-CCM authentications also uses 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 [RFC3610]). For AES-CCM in SRTP/SRTCP, the flag octet section 2.2 of [RFC3610]). For AES-CCM in SRTP/SRTCP, the flag octet
has the hex value 5A if an 8-octet AEAD authentication tag is used, has the hex value 5A if an 8-octet AEAD authentication tag is used,
6A if a 12-octet AEAD authentication tag is used, and 7A if a 6A if a 12-octet AEAD authentication tag is used, and 7A if a
16-octet AEAD authentication tag is used. The flag octet is one of 16-octet AEAD authentication tag is used. The flag octet is one of
the inputs to AES during the counter mode encryption of the the inputs to AES during the counter mode encryption of the
skipping to change at page 32, line 15 skipping to change at page 30, line 49
algorithm is used. Note that, according to Section 6.10.1 in algorithm is used. Note that, according to Section 6.10.1 in
[RFC3830], the input key length of the Key Derivation Function (i.e. [RFC3830], the input key length of the Key Derivation Function (i.e.
the SRTP master key length) is always equal to the session encryption 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 key length. This means, for example, that AEAD_AES_256_GCM will use
AES_256_CM_PRF as the Key Derivation Function. AES_256_CM_PRF as the Key Derivation Function.
17. Acknowledgements 17. 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,
Magnus Westerland, Oscar Ohllson, Woo-Hwan Kim, John Mattsson, Magnus Westerland, Oscar Ohllson, Woo-Hwan Kim, John Mattsson,
Richard Barnes and many other reviewers who provided valuable Richard Barnes, John Mattisson, Morris Dworkin and many other
comments on earlier drafts of this document. reviewers who provided valuable comments on earlier drafts of this
document.
18. References 18. References
18.1. Normative References 18.1. Normative References
[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 [RFC3550] Casner, S., Frederick, R., and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 3550, Transport Protocol for Real-Time Applications", RFC 3550,
 End of changes. 29 change blocks. 
98 lines changed or deleted 104 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/