draft-ietf-avtcore-srtp-aes-gcm-05.txt   draft-ietf-avtcore-srtp-aes-gcm-06.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 26, 2013 National Security Agency Expires: November 21, 2013 National Security Agency
February 22, 2013 May 20, 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-05 draft-ietf-avtcore-srtp-aes-gcm-06
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 26, 2013. This Internet-Draft will expire on November 21, 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.....................................................4 1. Introduction.....................................................3
2. Conventions Used In This Document................................4 2. Conventions Used In This Document................................3
3. Overview of the SRTP/SRTCP Security Architecture.................5 3. Overview of the SRTP/SRTCP Security Architecture.................4
4. Terminology......................................................5 4. Terminology......................................................4
5. Generic AEAD Processing..........................................6 5. Generic AEAD Processing..........................................5
5.1. Types of Input Data.........................................6 5.1. Types of Input Data.........................................5
5.2. AEAD Invocation Inputs and Outputs..........................6 5.2. AEAD Invocation Inputs and Outputs..........................5
5.2.1. Encrypt Mode...........................................6 5.2.1. Encrypt Mode...........................................5
5.2.2. Decrypt Mode...........................................7 5.2.2. Decrypt Mode...........................................6
5.3. Handling of AEAD Authentication.............................7 5.3. Handling of AEAD Authentication.............................6
6. Counter Mode Encryption..........................................8 6. Counter Mode Encryption..........................................7
7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................9 7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................8
8. Unneeded SRTP/SRTCP Fields.......................................9 8. Unneeded SRTP/SRTCP Fields.......................................8
8.1. SRTP/SRTCP Authentication Field.............................9 8.1. SRTP/SRTCP Authentication Field.............................8
8.2. RTP Padding................................................10 8.2. RTP Padding.................................................9
9. AES-GCM/CCM processing for SRTP.................................10 9. AES-GCM/CCM processing for SRTP..................................9
9.1. SRTP IV formation for AES-GCM and AES-CCM..................10 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..................................9
9.3. Handling Header Extensions.................................12 9.3. Handling Header Extensions.................................11
9.4. Prevention of SRTP IV Reuse................................12 9.4. Prevention of SRTP IV Reuse................................11
10. AES-GCM/CCM Processing of SRTCP Compound Packets...............13 10. AES-GCM/CCM Processing of SRTCP Compound Packets...............12
10.1. SRTCP IV formation for AES-GCM and AES-CCM................13 10.1. SRTCP IV formation for AES-GCM and AES-CCM................12
10.2. Data Types in Encrypted SRTCP Compound Packets............13 10.2. Data Types in Encrypted SRTCP Compound Packets............12
10.3. Data Types in Unencrypted SRTCP Compound Packets..........14 10.3. Data Types in Unencrypted SRTCP Compound Packets..........13
10.4. Prevention of SRTCP IV Reuse..............................15 10.4. Prevention of SRTCP IV Reuse..............................14
11. Constraints on AEAD for SRTP and SRTCP.........................16 11. Constraints on AEAD for SRTP and SRTCP.........................15
11.1. Generic AEAD Parameter Constraints........................16 11.1. Generic AEAD Parameter Constraints........................15
11.2. AES-GCM for SRTP/SRTCP....................................17 11.2. AES-GCM for SRTP/SRTCP....................................16
11.3. AES-CCM for SRTP/SRTCP....................................17 11.3. AES-CCM for SRTP/SRTCP....................................16
12. Key Derivation Functions.......................................18 12. Key Derivation Functions.......................................17
13. Security Considerations........................................18 13. Security Considerations........................................17
13.1. Handling of Security Critical Parameters..................18 13.1. Handling of Security Critical Parameters..................17
13.2. Size of the Authentication Tag............................18 13.2. Size of the Authentication Tag............................17
14. IANA Considerations............................................19 14. IANA Considerations............................................18
14.1. SDES......................................................19 14.1. SDES......................................................18
14.2. DTLS......................................................20 14.2. DTLS......................................................19
14.3. MIKEY.....................................................23 14.3. MIKEY.....................................................22
14.4. AEAD registry.............................................23 14.4. AEAD registry.............................................22
15. Parameters for use with MIKEY..................................23 15. Parameters for use with MIKEY..................................22
16. Acknowledgements...............................................24 16. Acknowledgements...............................................23
17. References.....................................................25 17. References.....................................................24
17.1. Normative References......................................25 17.1. Normative References......................................24
17.2. Informative References....................................27 17.2. Informative References....................................26
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 44 skipping to change at page 10, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R : SRTP MKI (optional) : R : SRTP MKI (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R : authentication tag (NOT RECOMMENDED) : R : 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 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 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. Handling Header Extensions 9.3. Handling Header Extensions
RTP header extensions were first defined in RFC 3550. RFC XXXX RTP header extensions were first defined in RFC 3550. RFC 6904
[RFCXXX] describes how these header extensions are to be encrypted in [RFC6904] describes how these header extensions are to be encrypted
SRTP. in SRTP.
When RFC XXXX 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 [RFCXXX] using the AES_128_CM transform. For the manner defined in [RFC6904] using the AES_128_CM transform. For
the AEAD_AES_256_GCM and the AEAD_AES_256_CCM algorithms, the 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 keystream MUST be generated in the manner defined for the AES_256_CM
transform. The originator must perform any required header extension transform. The originator must perform any required header extension
encryption before the AEAD algorithm is invoked. encryption before the AEAD algorithm is invoked.
As with the other fields contained within the RTP header, both As with the other fields contained within the RTP header, both
encrypted and unencrypted header extensions are to be treated by the encrypted and unencrypted header extensions are to be treated by the
AEAD algorithm as Additional Authenticated Data (AAD). Thus the AEAD AEAD algorithm as Additional Authenticated Data (AAD). Thus the AEAD
algorithm does not provide any additional privacy for the header algorithm does not provide any additional privacy for the header
extensions, but does provide integrity and authentication. extensions, but does provide integrity and authentication.
skipping to change at page 16, line 35 skipping to change at page 15, line 35
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 at most 2^36-16 octets. C_MAX maximum ciphertext GCM: MUST be at most 2^36-16
length per invocation CCM: MUST be at most 2^24+16 octets octets.
length per invocation CCM: MUST be at most 2^24+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 17, line 55 skipping to change at page 17, line 5
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 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 [RFC 3610]). For AES-CCM in SRTP/SRTCP, the flag section 2.2 of [RFC3610]). For AES-CCM in SRTP/SRTCP, the flag octet
octet has the hex value 5A if an 8-octet AEAD authentication tag is has the hex value 5A if an 8-octet AEAD authentication tag is used,
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
plaintext. 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
skipping to change at page 19, line 46 skipping to change at page 18, line 48
| 16 | 2^98 tries | 2^108 tries | 2^118 tries | | 16 | 2^98 tries | 2^108 tries | 2^118 tries |
+=================+============+=============+==============+ +=================+============+=============+==============+
Table 3: Probability of a compromise occurring for a given Table 3: Probability of a compromise occurring for a given
number of forgery attempts and tag size. number of forgery attempts and tag size.
14. IANA Considerations 14. IANA Considerations
14.1. SDES 14.1. SDES
Security description [RFC 4568] defines SRTP "crypto suites"; a Security description [RFC4568] defines SRTP "crypto suites"; a crypto
crypto suite corresponds to a particular AEAD algorithm in SRTP. In suite corresponds to a particular AEAD algorithm in SRTP. In order
order to allow SDP to signal the use of the algorithms defined in to allow SDP to signal the use of the algorithms defined in this
this document, IANA will register the following crypto suites into document, IANA will register the following crypto suites into the
the subregistry for SRTP crypto suites under the SRTP transport of subregistry for SRTP crypto suites under the SRTP transport of the
the SDP Security Descriptions: SDP Security Descriptions:
srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / srtp-crypto-suite-ext = "AEAD_AES_128_GCM" /
"AEAD_AES_256_GCM" / "AEAD_AES_256_GCM" /
"AEAD_AES_128_GCM_8" / "AEAD_AES_128_GCM_8" /
"AEAD_AES_256_GCM_8" / "AEAD_AES_256_GCM_8" /
"AEAD_AES_128_GCM_12" / "AEAD_AES_128_GCM_12" /
"AEAD_AES_256_GCM_12" / "AEAD_AES_256_GCM_12" /
"AEAD_AES_128_CCM" / "AEAD_AES_128_CCM" /
"AEAD_AES_256_CCM" / "AEAD_AES_256_CCM" /
srtp-crypto-suite-ext srtp-crypto-suite-ext
skipping to change at page 25, line 9 skipping to change at page 24, line 9
16. Acknowledgements 16. 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 and many other reviewers who
provided valuable comments on earlier drafts of this document. provided valuable comments on earlier drafts of this document.
17. References 17. References
17.1. Normative References 17.1. Normative References
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM
Mode for Authentication and Confidentiality", U.S.
National Institute of Standards and Technology http://
csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf.
[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 [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.
[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, 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.
[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
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" [RFC6655] McGrwe, D. and D. Bailey, "AES-CCM Cipher Suites for
RFC 6188, March 2011. Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC6655] McGrew,D. and D. Bailey,"AES-CCM Cipher Suites for Transport [RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure
Layer Security (TLS)", July 2012. Real-Time Transport Protocol (SRTP)", January 2013.
[RFCXXXX] J. Lennox, "Encryption of Header Extensions in the Secure , January 2013.
Real-Time Transport", January 2013.
[RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)", 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
and Key Establishment", Springer, 2003 .
[CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/
CryptoToolkit/modes/800-38_Series_Publications/
SP800-38B.pdf.
[EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and
provably repairing the SSH authenticated encryption
scheme: A case study of the Encode-then-Encrypt-and-MAC
paradigm", ACM Transactions on Information and System Secu
rity, http://www-cse.ucsd.edu/users/tkohno/papers/
TISSEC04/.
[GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder
than Real: Security Challenges in Virtual Machine Based
Computing Environments", Proceedings of the 10th Workshop
on Hot Topics in Operating Systems http://
www.stanford.edu/~talg/papers/HOTOS05/
virtual-harder-hotos05.pdf.
[J02] Jonsson, J., "On the Security of CTR + CBC-MAC",
Proceedings of the 9th Annual Workshop on Selected Areas
on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/
proposedmodes/ccm/ccm-ad1.pdf, 2002.
[MODES] Dworkin, M., "NIST Special Publication 800-38:
Recommendation for Block Cipher Modes of Operation", U.S.
National Institute of Standards and Technology http://
csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.
[MV04] McGrew, D. and J. Viega, "The Security and Performance of
the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT
'04, http://eprint.iacr.org/2004/193, December 2004.
[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-
Hashing for Message Authentication", RFC 2104,
February 1997.
[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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with
Requirements for Security", BCP 106, RFC 4086, June 2005. CBC-MAC (CCM)", RFC 3610, March 2004.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real- Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007. time Transport Protocol (SRTP)", RFC 4771, January 2007.
Author's Address Author's Address
David A. McGrew David A. McGrew
Cisco Systems, Inc. Cisco Systems, Inc.
510 McCarthy Blvd. 510 McCarthy Blvd.
 End of changes. 20 change blocks. 
135 lines changed or deleted 79 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/