draft-ietf-avtcore-srtp-aes-gcm-07.txt   draft-ietf-avtcore-srtp-aes-gcm-08.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: January 04, 2014 National Security Agency Expires: February 27, 2014 National Security Agency
July 03, 2013 August 26, 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-07 draft-ietf-avtcore-srtp-aes-gcm-08
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 January 04, 2014. This Internet-Draft will expire on February 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 7, line 11 skipping to change at page 7, line 11
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.
As mentioned in section 5.2.1, only three tag lengths are supported As mentioned in section 5.2.1, only three tag lengths are supported
for use in SRTP/SRTCP, namely 8 octetes, 12 octets and 16 octets. for use in SRTP/SRTCP, namely 8 octets, 12 octets and 16 octets.
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
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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 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, IV, Encryption_key ): def CCM_keystream( Plaintext, IV, Encryption_key ):
assert len(Plaintext) <= (2**32)-16 ## measured in octets assert len(Plaintext) <= (2**28)-16 ## 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)<len(Plaintext): while len(key_stream)<len(Plaintext):
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, len(Plaintext) ) key_stream = truncate( key_stream, len(Plaintext) )
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^32)-16 octets for AES-CCM and up to (2^36)-32 octets for up to (2^28)-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. section 9.1 of RFC 3711, this is a cryptographic disaster.
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
skipping to change at page 16, line 24 skipping to change at page 16, line 24
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 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
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^24-16 octets. length per invocation CCM: MUST be <= 2^28-16 octets.
The values for C_MAX are based on purely cryptographic The values for C_MAX are based on purely cryptographic
considerations. considerations.
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
skipping to change at page 29, line 17 skipping to change at page 29, line 17
we require that the SRTP PRF has value AES-CM whenever an AEAD we require that the SRTP PRF has value AES-CM whenever an AEAD
algorithm is used. Note that, according to Section 6.10.1 in algorithm is used. Note that, according to Section 6.10.1 in
[RFC3830], the key length of the Key Derivation Function (i.e. the [RFC3830], the key length of the Key Derivation Function (i.e. the
SRTP master key length) is always equal to the session encryption key SRTP master key length) is always equal to the session encryption key
length. This means, for example, that AEAD_AES_256_GCM will use 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 and many other reviewers who Magnus Westerland, Oscar Ohllson, Woo-Hwan Kim and many other
provided valuable 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
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.", U.S. National
Institute of Standards and Technology http://
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 [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,
July 2003. July 2003.
[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.
skipping to change at page 32, line 13 skipping to change at page 32, line 13
Real-Time Transport Protocol (SRTP)", January 2013. Real-Time Transport Protocol (SRTP)", January 2013.
18.2. Informative References 18.2. Informative References
[BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption:
Relations among notions and analysis of the generic Relations among notions and analysis of the generic
composition paradigm", Proceedings of ASIACRYPT 2000, composition paradigm", Proceedings of ASIACRYPT 2000,
Springer-Verlag, LNCS 1976, pp. 531-545 http:// Springer-Verlag, LNCS 1976, pp. 531-545 http://
www-cse.ucsd.edu/users/mihir/papers/oem.html. www-cse.ucsd.edu/users/mihir/papers/oem.html.
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.", U.S. National
Institute of Standards and Technology http://
csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf.
[R02] Rogaway, P., "Authenticated encryption with Associated- [R02] Rogaway, P., "Authenticated encryption with Associated-
Data", ACM Conference on Computer and Communication Data", ACM Conference on Computer and Communication
Security (CCS'02), pp. 98-107, ACM Press, Security (CCS'02), pp. 98-107, ACM Press,
2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with
 End of changes. 10 change blocks. 
16 lines changed or deleted 17 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/