draft-ietf-avtcore-srtp-aes-gcm-04.txt   draft-ietf-avtcore-srtp-aes-gcm-05.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: August 08, 2013 National Security Agency Expires: August 26, 2013 National Security Agency
February 04, 2013 February 22, 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-04 draft-ietf-avtcore-srtp-aes-gcm-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current. Drafts is at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 08, 2013. This Internet-Draft will expire on August 26, 2013.
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 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
This document defines how AES-GCM and AES-CCM Authenticated This document defines how AES-GCM and AES-CCM Authenticated
Encryption with Associated Data algorithms can be used to provide Encryption with Associated Data algorithms can be used to provide
confidentiality and data authentication in the SRTP protocol. confidentiality and data authentication in the SRTP protocol.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction.....................................................4
2. Conventions Used In This Document................................3 2. Conventions Used In This Document................................4
3. Overview of the SRTP/SRTCP Security Architecture.................4 3. Overview of the SRTP/SRTCP Security Architecture.................5
4. Terminology......................................................4 4. Terminology......................................................5
5. Generic AEAD Processing..........................................5 5. Generic AEAD Processing..........................................6
5.1. Types of Input Data.........................................5 5.1. Types of Input Data.........................................6
5.2. AEAD Invocation Inputs and Outputs..........................5 5.2. AEAD Invocation Inputs and Outputs..........................6
5.2.1. Encrypt Mode...........................................5 5.2.1. Encrypt Mode...........................................6
5.2.2. Decrypt Mode...........................................6 5.2.2. Decrypt Mode...........................................7
5.3. Handling of AEAD Authentication.............................6 5.3. Handling of AEAD Authentication.............................7
6. Counter Mode Encryption..........................................7 6. Counter Mode Encryption..........................................8
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......................9
8. Unneeded SRTP/SRTCP Fields.......................................8 8. Unneeded SRTP/SRTCP Fields.......................................9
8.1. SRTP/SRTCP Authentication Field.............................8 8.1. SRTP/SRTCP Authentication Field.............................9
8.2. RTP Padding.................................................9 8.2. RTP Padding................................................10
9. AES-GCM/CCM processing for SRTP..................................9 9. AES-GCM/CCM processing for SRTP.................................10
9.1. SRTP IV formation for AES-GCM and AES-CCM...................9 9.1. SRTP IV formation for AES-GCM and AES-CCM..................10
9.2. Data Types in SRTP Packets..................................9 9.2. Data Types in SRTP Packets.................................10
9.3. Prevention of SRTP IV Reuse................................11 9.3. Handling Header Extensions.................................12
10. AES-GCM/CCM Processing of SRTCP Compound Packets...............11 9.4. Prevention of SRTP IV Reuse................................12
10.1. SRTCP IV formation for AES-GCM and AES-CCM................11 10. AES-GCM/CCM Processing of SRTCP Compound Packets...............13
10.2. Data Types in Encrypted SRTCP Compound Packets............12 10.1. SRTCP IV formation for AES-GCM and AES-CCM................13
10.3. Data Types in Unencrypted SRTCP Compound Packets..........13 10.2. Data Types in Encrypted SRTCP Compound Packets............13
10.4. Prevention of SRTCP IV Reuse..............................14 10.3. Data Types in Unencrypted SRTCP Compound Packets..........14
11. Constraints on AEAD for SRTP and SRTCP.........................14 10.4. Prevention of SRTCP IV Reuse..............................15
11.1. Generic AEAD Parameter Constraints........................15 11. Constraints on AEAD for SRTP and SRTCP.........................16
11.2. AES-GCM for SRTP/SRTCP....................................15 11.1. Generic AEAD Parameter Constraints........................16
11.3. AES-CCM for SRTP/SRTCP....................................16 11.2. AES-GCM for SRTP/SRTCP....................................17
12. Key Derivation Functions.......................................16 11.3. AES-CCM for SRTP/SRTCP....................................17
13. Security Considerations........................................17 12. Key Derivation Functions.......................................18
13.1. Handling of Security Critical Parameters..................17 13. Security Considerations........................................18
13.2. Size of the Authentication Tag............................17 13.1. Handling of Security Critical Parameters..................18
14. IANA Considerations............................................18 13.2. Size of the Authentication Tag............................18
14.1. SDES......................................................18 14. IANA Considerations............................................19
14.2. DTLS......................................................19 14.1. SDES......................................................19
14.3. MIKEY.....................................................21 14.2. DTLS......................................................20
14.4. AEAD registry.............................................22 14.3. MIKEY.....................................................23
15. Parameters for use with MIKEY..................................22 14.4. AEAD registry.............................................23
16. Acknowledgements...............................................23 15. Parameters for use with MIKEY..................................23
17. References.....................................................24 16. Acknowledgements...............................................24
17.1. Normative References......................................24 17. References.....................................................25
17.2. Informative References....................................26 17.1. Normative References......................................25
17.2. Informative References....................................27
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 11, line 7 skipping to change at page 12, line 7
Since the AEAD cipher is larger than 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. Handling Header Extensions
RTP header extensions were first defined in RFC 3550. RFC XXXX
[RFCXXX] describes how these header extensions are to be encrypted in
SRTP.
When RFC XXXX is in use, a separate keystream is generated to encrypt
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 manner defined in [RFCXXX] using the AES_128_CM transform. For
the AEAD_AES_256_GCM and the AEAD_AES_256_CCM algorithms, the
keystream MUST be generated in the manner defined for the AES_256_CM
transform. The originator must perform any required header extension
encryption before the AEAD algorithm is invoked.
As with the other fields contained within the RTP header, both
encrypted and unencrypted header extensions are to be treated by the
AEAD algorithm as Additional Authenticated Data (AAD). Thus the AEAD
algorithm does not provide any additional privacy for the header
extensions, but does provide integrity and authentication.
9.4. 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 master key before the (ROC,SEQ) pair cycles
back to its original value. back to its original value.
SSRC Management: For a given master key, the set of all SSRC SSRC Management: For a given master key, the set of all SSRC
skipping to change at page 25, line 6 skipping to change at page 26, line 6
[RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP" [RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP"
RFC 6188, March 2011 RFC 6188, March 2011.
[RFC6655] McGrew,D. and D. Bailey,"AES-CCM Cipher Suites for Transport [RFC6655] McGrew,D. and D. Bailey,"AES-CCM Cipher Suites for Transport
Layer Security (TLS)", July 2012 Layer Security (TLS)", July 2012.
[RFCXXXX] J. Lennox, "Encryption of Header Extensions in the Secure
Real-Time Transport", January 2013.
17.2. Informative References 17.2. Informative References
[BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption:
Relations among notions and analysis of the generic Relations among notions and analysis of the generic
composition paradigm", Proceedings of ASIACRYPT 2000, composition paradigm", Proceedings of ASIACRYPT 2000,
Springer-Verlag, LNCS 1976, pp. 531-545 http:// Springer-Verlag, LNCS 1976, pp. 531-545 http://
www-cse.ucsd.edu/users/mihir/papers/oem.html. www-cse.ucsd.edu/users/mihir/papers/oem.html.
[BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication
skipping to change at page 27, line 5 skipping to change at page 28, line 5
[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.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", (GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005. RFC 4106, June 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
 End of changes. 9 change blocks. 
50 lines changed or deleted 78 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/