draft-ietf-avtcore-srtp-aes-gcm-02.txt   draft-ietf-avtcore-srtp-aes-gcm-03.txt 
Network Working Group D. McGrew Network Working Group D. McGrew
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Intended Status: Informational K.M. Igoe Intended Status: Informational K. Igoe
Expires: February 16, 2013 National Security Agency Expires: March 22, 2013 National Security Agency
August 15, 2012 September 18, 2012
AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)
draft-ietf-avtcore-srtp-aes-gcm-02 draft-ietf-avtcore-srtp-aes-gcm-03
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 February 16, 2013. This Internet-Draft will expire on March 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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..........................................6
7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................7 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.................................................8
9. AES-GCM/CCM processing for SRTP..................................8 9. AES-GCM/CCM processing for SRTP..................................9
9.1. SRTP IV formation for AES-GCM and AES-CCM...................8 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................................10
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
skipping to change at page 2, line 54 skipping to change at page 2, line 54
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.....................................................20
14.4. AEAD registry.............................................21 14.4. AEAD registry.............................................21
15. Parameters for use with MIKEY..................................21 15. Parameters for use with MIKEY..................................21
16. Acknowledgements...............................................22 16. Acknowledgements...............................................22
17. References.....................................................23 17. References.....................................................23
17.1. Normative References......................................23 17.1. Normative References......................................23
17.2. Informative References....................................24 17.2. Informative References....................................25
1. Introduction 1. Introduction
The Secure Real-time Transport Protocol (SRTP) is a profile of the The Secure Real-time Transport Protocol (SRTP) is a profile of the
Real-time Transport Protocol (RTP), which can provide Real-time Transport Protocol (RTP), which can provide
confidentiality, message authentication, and replay protection to the confidentiality, message authentication, and replay protection to the
RTP traffic and to the control traffic for RTP, the Real-time RTP traffic and to the control traffic for RTP, the Real-time
Transport Control Protocol (RTCP). It is important to note that the Transport Control Protocol (RTCP). It is important to note that the
outgoing SRTP packets from a single endpoint may be originating from outgoing SRTP packets from a single endpoint may be originating from
several independent data sources. several independent data sources.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
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 Bit string of variable length Associated_Data Bit string of variable length
Plaintext Bit string of variable length Plaintext Bit string of variable length
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.
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
Outputs Outputs
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 has the hex value 5A if an 8-octet The Tag_Size_Flag, used in AES-CCM authentication, has the hex value
authentication tag is used, 6A if a 12-octet authentication tag is 5A if an 8-octet authentication tag is used, 6A if a 12-octet
used, and 7A if a 16-octet authentication tag is used. authentication tag is used, and 7A if a 16-octet authentication tag
is used.
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
Each outbound packet uses a 12 octet IV and encryption key to form a In both GCM and CCM, each outbound packet uses a 12-octet IV and an
keystream of bits which is XORed to the plaintext to form cipher. encryption key to form two outputs, a 16-octet first_key_block which
is used informing the authentication tag and keystream of octets
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, with a 4-octet
block counter forms the input to AES. This is used to build a block counter forms the input to AES. This is used to build a
key_stream as follows: 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
while len(key_stream) < len(plaintext): first_key_block = AES_ENC( data=IV||block_counter,
key=Encryption_key )
while len(key_stream) < len(Plaintext):
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
block_counter = block_counter + 1 key_stream = truncate( key_stream, len(Plaintext) )
key_stream = truncate( key_stream, len(plaintext) ) return (first_key_block, key_stream )
last_key_block = AES_ENC( data=IV||block_counter,
key=Encryption_key )
return (key_stream, last_key_block )
The last_key_block is reserved to form the GMAC of the message by
encrypting the GHASH of the message. It is not required for CCM.
When CCM is used, the AES input is the concatenation of a 12-octet In AES-CCM counter mode encryption, the AES data input consists of
IV, a 1-octet Tag_Size_Flag, and a 4-octet block counter. A the concatenaton of a 1-octet flag,, a 12-octet IV, and a 3-octet
keystream is formed as follows: block counter. Note that in this apllication the flag octet will
always have the value 0x02 (see section 2.3 of [RFC3610]). A
(first_key_block, keystream) pair is formed as follows:
def CCM_keystream( plaintext, IV, Tag_Size_Flag, Encryption_key ): def CCM_keystream( Plaintext, IV, Encryption_key ):
assert len(plaintext) <= 2**28 assert len(Plaintext) <= (2**28)-16
key_stream = "" key_stream = ""
block_counter = 0 block_counter = 0
while len(key_stream)<len(plaintext): first_key_block = AES_ENC( data=0x02||IV||block_counter,
key_block = AES_ENC( data=IV||Tag_Size_Flag||block_counter, key=Encryption_key )
key=Encryption_key ) while len(key_stream)<len(Plaintext):
key_stream = key_stream || key_block
block_counter = block_counter + 1 block_counter = block_counter + 1
key_stream = truncate( key_stream, len(plaintext) ) key_block = AES_ENC( data=0x02||IV||block_counter,
return key_stream key=Encryption_key )
key_stream = key_stream || key_block
key_stream = truncate( key_stream, len(Plaintext) )
return (first_key_block, key_stream )
These keystream generation processes allows for a keystream of length These keystream generation processes allows for a keystream of length
of up to 2^24 octets for AES-CCM and up to 2^36-32 octets for of up to (2^24)-16 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 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
skipping to change at page 10, line 37 skipping to change at page 10, line 38
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 R = neither encrypted nor authenticated
Note: The RTP padding and RTP padding count fields are optional Note: The RTP padding and RTP padding count fields are optional
and are not recommended and are not recommended
Figure 2: AEAD inputs from an SRTP packet Figure 2: AEAD inputs from an SRTP packet
Since the AEAD cipher is larger that the plaintext by exactly the Since the AEAD cipher is larger than the plaintext by exactly the
length of the AEAD authentication tag, the corresponding SRTP length of the AEAD authentication tag, the corresponding SRTP
encrypted packet replaces the plaintext field by a slightly larger encrypted packet replaces the plaintext field by a slightly larger
field containing the cipher. Even if the plaintext field is empty, field containing the cipher. Even if the plaintext field is empty,
AEAD encryption must still be performed, with the resulting cipher AEAD encryption must still be performed, with the resulting cipher
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
skipping to change at page 16, line 43 skipping to change at page 16, line 43
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.
AES-CCM uses a flag octet that conveys information about the length In addition to the flag octet used in counter node encryptionn,
of the authentication tag, length of the block counter, and presence AES-CCM authentications also useus a flag octet that conveys
of additional authenticated data. For AES-CCM in SRTP/SRTCP, the information about the length of the authentication tag, length of the
flag octet has the hex value 5A if an 8-octet authentication tag is block counter, and presence of additional authenticated data (see
used, 6A if a 12-octet authentication tag is used, and 7A if a section 2.2 of [RFC 3610]). For AES-CCM in SRTP/SRTCP, the flag
16-octet authentication tag is used. The flag octet is one of the octet has the hex value 5A if an 8-octet authentication tag is used,
inputs to AES during the counter mode encryption of the plaintext. 6A if a 12-octet authentication tag is used, and 7A if a 16-octet
authentication tag is used. The flag octet is one of the 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 23, line 23 skipping to change at page 23, 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.
[RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with
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, March 2004. (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.
[RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session
Description Protocol (SDP): Security Descriptions for Description Protocol (SDP): Security Descriptions for
Media Streams", RFC 4568, July 2006. Media Streams", RFC 4568, July 2006.
[RFC5116] McGrew, D., "An Interface and Algorithms for [RFC5116] McGrew, D., "An Interface and Algorithms for
Authenticated Encryption with Associated Data", RFC 5116, Authenticated Encryption with Associated Data", RFC 5116,
January 2008. January 2008.
[RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption
 End of changes. 24 change blocks. 
50 lines changed or deleted 59 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/