Network Working Group M. Peck
Internet Draft The MITRE Corporation
Intended Status: Informational K. Igoe
Expires: June 29, 2014 National Security Agency
December 26, 2013
Suite B Profile for Datagram Transport Layer Security / Secure
Real-time Transport Protocol (DTLS-SRTP)
draft-peck-suiteb-dtls-srtp-04
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Peck and Igoe Informational [Page 1]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
Abstract
The United States government has published guidelines for "NSA Suite
B Cryptography", which defines cryptographic algorithm policy for
national security applications. This document describes the use of
Suite B cryptography with the Datagram Transport Layer Security
(DTLS) protocol, the Secure Real-Time Transport Protocol (SRTP), and
the Secure Real-Time Transport Control Protocol (SRTCP) to provide a
robust architecture for securing real-time data.
Table of Contents
1. Introduction.....................................................3
1.1. Requirements Terminology....................................3
2. Suite B Requirements.............................................3
3. Minimum Security Levels for Suite B Compliant Implementations....4
3.1. DTLS Cryptographic Suites for minLOS_128 and minLOS_192.....5
3.2. Suite B DTLS Authentication.................................5
3.3. Digital Signatures and Certificates.........................6
4. Client and Server Handshake to Create DTLS Premaster Secret......6
5. DTLS Master Secret...............................................7
6. SRTP Master Key and Master Salt..................................7
7. Suite B SRTP Protection Profiles.................................8
8. DTLS Cipher Suite and SRTP Protection Profile Negotiation........9
9. SRTP Key Derivation..............................................9
10. Security Considerations........................................10
11. IANA Considerations............................................10
12. References.....................................................10
12.1. Normative References......................................10
12.2. Informative References....................................11
Peck and Igoe Informational [Page 2]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
1. Introduction
This document specifies the conventions for using NSA Suite B
Cryptography [SuiteB] with the Datagram Transport Layer Security
(DTLS) protocol, the Secure Real-time Transport Protocol (SRTP), and
the Secure Real-time Transport Control Protocol (SRTCP) to provide a
robust architecture for securing real-time data.
The Secure Real-time Transport Protocol (SRTP) provides
confidentiality and message authentication to RTP traffic. The
Secure Real-time Transport Control Protocol (SRTCP) provides message
authentication and optional confidentiality to the Real-time
Transport Control Protocol (RTCP) [RFC3711]. SRTP and SRTCP depend
upon external key management to provide secret master keys from which
to form encryption and authentication keys. RTP and RTCP are usually
run over the User Datagram Protocol, UDP.
Datagram Transport Layer Security (DTLS), based upon the Transport
Layer Security protocol (TLS), provides communication security for
datagram protocols such as UDP [RFC6347]. DTLS-SRTP is an extension
for DTLS that provides key management to SRTP and SRTCP as well as a
choice of algorithms and parameters for the SRTP and SRTCP sessions
[RFC5764].
[RFC6460] describes a Suite B profile for TLS and DTLS. This
document builds upon RFC 6460, adding additional components to
provide a Suite B profile for DTLS-SRTP.
1.1 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Suite B Requirements
Suite B requires that key establishment and signature algorithms be
based upon Elliptic Curve Cryptography and that the encryption
algorithm be AES [FIPS197]. Suite B algorithms are defined to
support two minimum levels of security: 128 and 192 bits. Suite B
includes [SuiteB]:
Encryption Advanced Encryption Standard (AES) (key sizes
of 128 and 256 bits)
Digital Signature Elliptic Curve Digital Signature Algorithm
(ECDSA) [FIPS186-4] (using the curves with 256-
Peck and Igoe Informational [Page 3]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
and 384-bit prime moduli as specified in FIPS
PUB 186-4)
Key Agreement Elliptic Curve Diffie-Hellman (ECDH)
[SP800-56A] (using the curves with 256- and
384-bit prime moduli as specified in FIPS PUB
186-4)
Secure Hash SHA-256 and SHA-384 [FIPS180-4]
The curves with 256- and 384-bit prime moduli are described in NIST
FIPS 186-4 [FIPS186-4]. They are referred to as P-256 and P-384,
respectively. These elliptic curves appear in the literature under
two different names. For sake of clarity, we list both names below:
Curve NIST name SECG name
------------------------------------
P-256 nistp256 secp256r1
P-384 nistp384 secp384r1
3. Minimum Security Levels for Suite B Compliant Implementations
Suite B provides for two levels of cryptographic security, namely a
128-bit minimum level of security (minLOS_128) and a 192-bit minimum
level of security (minLOS_192). Each level defines a minimum
strength that all cryptographic algorithms must provide. We divide
the Suite B non-signature primitives into two columns as shown in
Table 1.
Column 1 Column 2
+-------------------+------------------+
Encryption | AES-128 | AES-256 |
+-------------------+------------------+
Key Agreement | ECDH on P-256 | ECDH on P-384 |
+-------------------+------------------+
Hash for PRF/MAC | SHA-256 | SHA-384 |
+-------------------+------------------+
Table 1: Suite B Cryptographic
Non-Signature Primitives
At the 128-bit minimum level of security the non-signature primitives
MUST either come exclusively from Column 1 or exclusively from Column
2.
Peck and Igoe Informational [Page 4]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
At the 192-bit minimum level of security the non-signature primitives
MUST come exclusively from Column 2.
3.1. DTLS Cryptographic Suites for minLOS_128 and minLOS_192
Each system MUST specify a security level of a minimum of 128 bits or
192 bits. The security level determines which suites from the Suite
B compliant profile of [RFC6460] are allowed.
The two Suite B combinations, "SuiteB_Combination_1" or
"SuiteB_Combination_2" from section 3.1 of [RFC6460], satisfy the
requirements of section 3 of this document for the DTLS connection.
For a system to implement the Suite B compliant DLTS-SRTP profile, it
MUST follow the requirements of [RFC6460] for the DTLS connection.
The cipher suite rules from section 4 of [RFC6460] are summarized
here:
o A Suite B compliant DTLS MUST use version 1.2 or higher.
o A system configured at a minimum level of security of 128 bits
MUST use either TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, with
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 being the preferred
choice.
o If configured at a minimum level of security of 192 bits, the
system MUST use TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
o The choice of curve used in the ECDH key exchange MUST agree
with the requirements listed in Table 1 of section 3.
3.2. Suite B DTLS Authentication
Digital signatures using ECDSA MUST be used for authentication by
Suite B compliant implementations. Using the notation of [RFC6460],
"ECDSA-256" represents an instantiation of the ECDSA algorithm using
the P-256 curve and the SHA-256 hash function. "ECDSA-384" represents
an instantiation of the ECDSA algorithm using the P-384 curve and the
SHA-384 hash function.
When running in Suite B compliant mode, a system configured at a
minimum level of security of 128 bits MUST use either ECDSA-256 or
ECDSA-384 for client and server authentication. It is allowable for
one party to authenticate with ECDSA-256 and the other party to
authenticate with ECDSA-384. This flexibility will allow
Peck and Igoe Informational [Page 5]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
interoperability between a client and a server that have different
sizes of ECDSA authentication keys.
In Suite B compliant mode, clients and servers in a system configured
at a minimum level of security of 128 bits MUST be able to verify
ECDSA-256 signatures and SHOULD be able to verify ECDSA-384
signatures unless it is absolutely certain that the implementation
will never need to verify certificates from an authority which uses
an ECDSA-384 signing key.
A system compliant with the Suite B profile and configured at a
minimum level of security of 192 bits MUST use ECDSA-384 for both
client and server DTLS authentication.
Clients and servers in a system configured at a minimum level of
security of 192 bits MUST be able to verify ECDSA-384 signatures.
When in Suite B compliant mode, authentication methods other than
ECDSA-256 and ECDSA-384 MUST NOT be used for DTLS authentication. If
a relying party receives a message signed with any other
authentication method, it MUST return a DTLS error and stop the DTLS
handshake.
Mutual authentication MUST be performed by client and server
[RFC5764].
3.3. Digital Signatures and Certificates
The initiator and responder, at both minimum levels of security, MUST
each have an X.509 certificate that complies with the end entity
signature certificate format defined in section 4.5.3 of "Suite B
Certificate and Certificate Revocation List (CRL) Profile" [RFC5759].
4. Client and Server Handshake to Create DTLS Premaster Secret
DTLS-SRTP is defined for point-to-point media sessions, in which
there are exactly two participants [RFC5764]. Two DTLS peers MUST
follow the guidelines in [RFC6460] in order to be Suite B compliant.
Two peers who wish to implement the Suite B DTLS-SRTP profile MUST
implement DTLS 1.2 or later.
The peers MUST each generate an ephemeral elliptic curve key pair for
key agreement using either the P-256 or P-384 curve. The curve
chosen will depend upon the selected cipher suite, following the
requirements of section 3. The peers will then execute the elliptic
curve Diffie-Hellman (ECDH) key agreement to obtain a DTLS premaster
Peck and Igoe Informational [Page 6]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
secret [SP800-56A, section 6.1.2.2]).
The DTLS premaster secret will be 32 bytes in length when using the
P-256 curve and 48 bytes in length when using the P-384 curve.
Two Suite B DTLS-SRTP compliant peers MUST each have an X.509
certificate that complies with the Suite B end entity digital
signature certificate profile [RFC5759]. The peer acting as the DTLS
server will use his key and the ECDSA algorithm to sign the DTLS
server key exchange message. For DTLS-SRTP implementations
[RFC5764], the peer acting as server will send the CertificateRequest
message. The peer acting as the client MUST then use his key and the
ECDSA algorithm to sign the CertificateVerify message.
Peers compliant with Suite B for DTLS-SRTP MUST follow the
certificate guidance in section 4.3 of [RFC6460].
5. DTLS Master Secret
For Suite B applications using DTLS 1.2 or later versions, the PRF
used to compute the DTLS master secret will be:
When selecting the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher
suite, the TLS PRF with SHA-256 as the hash function MUST be used
as in [RFC5246].
When selecting the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher
suite, the TLS PRF with SHA-384 as the hash function MUST be used
as in [RFC5246].
The master secret will be 48 bytes in length for both PRFs.
6. SRTP Master Key and Master Salt
The DTLS master key is used in DTLS-SRTP to create SRTP master key
and salt pairs for the two peers acting as client and server via the
TLS exporter [RFC5764]. In particular, the PRF used to compute each
SRTP master key and salt is the following:
o When the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite is
chosen, the TLS PRF with SHA-256 as the hash function MUST be
used. The SRTP master keys exported for the client and server
MUST be 128 bits in size. The SRTP master salt values for the
client and server MUST be 112 bits.
o When the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite is
Peck and Igoe Informational [Page 7]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
chosen, the TLS PRF with SHA-384 as the hash function MUST be
used. The SRTP master keys exported for the client and server
MUST be 256 bits in size. The SRTP master salt values for the
client and server MUST be 112 bits.
7. Suite B SRTP Protection Profiles
For Suite B applications, AES in Galois Counter Mode, AES-GCM, MUST
be used to protect SRTP and SRTCP packets. Note that encryption is
OPTIONAL but message authentication is MANDATORY for SRTCP packets
[RFC3711]. Section 14.2 of [srtp-gcm] defines the DTLS-SRTP "SRTP
Protection Profiles" used for Suite B.
The following AES_128 based SRTP protection profiles are applicable
when using the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite
for DTLS:
AEAD_AES_128_GCM_8
AEAD_AES_128_GCM_12
The following AES_256 based SRTP protection profiles are applicable
when using the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite
for DTLS:
AEAD_AES_256_GCM_8
AEAD_AES_256_GCM_12
Any Suite B compliant DTLS-SRTP application MUST use one of the
above, no other encryption or integrity algorithms are allowed. In
addition, the following constraints are imposed upon on any Suite B
compliant DTLS-SRTP applications:
o Any application running at the 192-bit minimum level of security
MUST support AEAD_AES_256_GCM_8 and SHOULD support
AEAD_AES_256_GCM_12. The AES_128 based profiles MUST NOT be
used.
o For applications running at the 128-bit minimum level of
security, there are three options:
o Option 1 (AES_128 based): The application MUST support
AEAD_AES_128_GCM_8 and and SHOULD support
AEAD_AES_128_GCM_12.
o Option 2 (AES_256 based): The application MUST support
AEAD_AES_256_GCM_8 and and SHOULD support
AEAD_AES_256_GCM_12.
Peck and Igoe Informational [Page 8]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
o Option 3 (both AES_128 and AES_256): The application MUST
support both AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8 and
SHOULD support AEAD_AES_128_GCM_12 and AEAD_AES_256_GCM_12.
o Since the AES_128 based profiles are the preferred choice at
the 128-bit minimum level of security, if Option 3 is used
the AES_128 based profiles MUST be offered before the AES_256
based profiles.
8. DTLS Cipher Suite and SRTP Protection Profile Negotiation
As described in [RFC5764], the DTLS-SRTP peer acting as the client
signals its acceptable SRTP protection profiles to the DTLS-SRTP peer
acting as the server with the "use_srtp" DTLS extension. For Suite
B, the client determines its acceptable SRTP protection profiles
based on its offered TLS cipher suites.
o If the client offers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
then the client MUST offer AEAD_AES_128_GCM_8 and MAY offer
AEAD_AES_128_GCM_12.
o If the client offers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
then the client MUST offer AEAD_AES_256_GCM_8 and MAY offer
AEAD_AES_256_GCM_12.
The client MAY offer other cipher suites or protection profiles, but
if used, the connection will not be Suite B compliant.
For Suite B, the DTLS-SRTP peer acting as the server chooses the DTLS
cipher suite from the client's offerings and also chooses the SRTP
protection profile from the client's offerings.
o If the server chooses TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
then it MUST choose AEAD_AES_128_GCM_8 or AEAD_AES_128_GCM_12.
o If the server chooses TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
then it MUST choose AEAD_AES_256_GCM_8 or AEAD_AES_256_GCM_12.
The server MAY choose other cipher suites or protection profiles, but
if used, the connection will not be Suite B compliant. The client
and server each have the option to terminate the connection if the
chosen cipher suite and protection profile are not acceptable.
9. SRTP/SRTCP Key Derivation
The AES Counter Mode based key derivation function is used to derive
Peck and Igoe Informational [Page 9]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
session keys and salts for SRTP/SRTCP [RFC3711]. The session keys
and salts MUST have the following bit sizes:
When using the AEAD_AES_128_GCM_8 or AEAD_AES_128_GCM_12
protection profile:
SRTP master key (generated from DTLS): 128 bits
SRTP master salt (generated from DTLS): 112 bits
SRTP session encryption key: 128 bits
SRTP session authentication key: not used for GCM
SRTP session salting key: 96 bits
When using the AEAD_AES_256_GCM_8 or AEAD_AES_256_GCM_12
protection profile:
SRTP master key (generated from DTLS): 256 bits
SRTP master salt (generated from DTLS): 112 bits
SRTP session encryption key: 256 bits
SRTP session authentication key: not used for GCM
SRTP session salting key: 96 bits
10. Security Considerations
The security considerations of this document follow those in [srtp-
gcm], [RFC3711], [RFC5759], [RFC5764], [RFC6347], and [RFC6460].
11. IANA Considerations
This document has no actions for IANA.
12. References
12.1. Normative References
[FIPS180-4] National Institute of Standards and Technology,
FIPS Publication 180-4: "Secure Hash Standard",
March 2012.
[FIPS186-4] National Institute of Standards and Technology,
FIPS Publication 186-4: "Digital Signature Standard
(DSS)", July 2013.
[FIPS197] National Institute of Standards and Technology,
"Advanced Encryption Standard (AES)", FIPS
Publication 197, November 2001.
[srtp-gcm] McGrew, D., and K. Igoe, "AES-GCM and AES-CCM
Peck and Igoe Informational [Page 10]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
Authenticated Encryption in Secure RTP (SRTP)",
draft-ietf-avtcore-srtp-aes-gcm-10, Work in Progress,
September 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3711] Baugher, M. McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, May
2008.
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and
Certificate Revocation List (CRL) Profile",
RFC 5759, January 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for
Secure Real-time Transport Protocol (SRTP)", RFC
5764, May 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport
Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6460] Salter, M. and R. Housley, "Suite B
Profile for Transport Layer Security (TLS)",
RFC 6460, January 2012.
12.2. Informative References
[SuiteB] U.S. National Security Agency, "NSA Suite B
Cryptography", January 2009,
<http://www.nsa.gov/ia/programs/suiteb_cryptography/>.
[SP800-56A] National Institute of Standards and Technology, Special
Publication 800-56A: "Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm
Cryptography (Revised)", March 2007.
Authors' Addresses
Michael A. Peck
The MITRE Corporation
Email: mpeck@mitre.org
Peck and Igoe Informational [Page 11]
Internet Draft draft-peck-suiteb-dtls-srtp-04 December 26, 2013
Kevin M. Igoe
NSA/CSS Commercial Solutions Center
National Security Agency
Email: kmigoe@nsa.gov
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Peck and Igoe Informational [Page 12]