Network Working Group                                          M.A. Peck
Internet Draft                                     The MITRE Corporation
Intended Status: Informational                                 K.M. Igoe
Expires: October 10, 2011                       National Security Agency
                                                          April 08, 2011


     Suite B Profile for Datagram Transport Layer Security / Secure
                Real-time Transport Protocol (DTLS-SRTP)
                     draft-peck-suiteb-dtls-srtp-00


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 10, 2011.

Copyright Notice

   Copyright (c) 2011 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 BSD License.





Igoe and Peck                   Informational                   [Page 1]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


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 Protocol (SRTP), and the Secure
   Real-Time Control Protocol (SRTCP) to provide a robust architecture
   for securing real-time data.


Table of Contents

   1. Introduction.....................................................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.............................................10
   10. Security Considerations........................................11
   11.  References....................................................11
      11.1. Normative References......................................11
      11.2. Informative References....................................11

























Igoe and Peck                   Informational                   [Page 2]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011



1. Introduction

   The Fact Sheet on National Security Agency (NSA) Suite B Cryptography
   [NSA] states:

      A Cryptographic Interoperability Strategy (CIS) was developed to
      find ways to increase assured rapid sharing of information both
      within the U.S.  and between the U.S.  and her partners through
      the use of a common suite of public standards, protocols,
      algorithms and modes referred to as the "Secure Sharing Suite".
      The implementation of CIS will facilitate the development of a
      broader range of secure cryptographic products which will be
      available to a wide customer base.  The use of selected public
      cryptographic standards and protocols and Suite B is the core of
      CIS.

      In 2005, NSA announced Suite B Cryptography which built on the
      National Policy on the use of the Advanced Encryption Standard
      (AES) to Protect National Security Systems and National Security
      Information (CNSSP-15).  In addition to the AES, Suite B includes
      cryptographic algorithms for key exchange, digital signature and
      hashing.  Suite B cryptography has been selected from cryptography
      that has been approved by NIST for use by U.S.  Government and
      specified in NIST standards or recommendations.

   The Secure Real-time Transport Protocol, (SRTP) provides
   confidentiality and message authentication to RTP traffic and to
   control traffic for RTP, the Real-time Control Protocol (RTCP).
   [RFC3711].  SRTP depends upon external key management to provide it
   with 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 [DTLS].  DTLS-SRTP is an extension for
   DTLS that provides key management to SRTP as well as a choice of
   algorithms and parameters for the SRTP session [RFC5764].

   [RFC5430bis] describes a Suite B profile for TLS that is applicable
   to DTLS as well.  This document builds upon draft RFC5430bis, adding
   additional components to provide a Suite B profile for DTLS-SRTP.


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 [AES].  Suite B algorithms are defined to support
   two minimum levels of security: 128 and 192 bits.  Suite B includes
   [NSA]:


Igoe and Peck                   Informational                   [Page 3]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011



   Encryption            Advanced Encryption Standard (AES) (key sizes
                         of 128 and 256 bits)

   Digital Signature     Elliptic Curve Digital Signature Algorithm
                         (ECDSA) [FIPS186-3] (using the curves with 256-
                         and 384-bit prime moduli as specified in FIPS
                         PUB 186-3)

   Key Agreement         Elliptic Curve Diffie-Hellman (ECDH)
                         [NIST800-56A] (using the curves with 256- and
                         384-bit prime moduli as specified in FIPS PUB
                         186-3)

   Secure Hash           SHA-256 and SHA-384 [FIPS180-3]

   The curves with 256- and 384-bit prime moduli are described in NIST
   FIPS 186-3 [FIPS186-3].  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


Igoe and Peck                   Informational                   [Page 4]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


   2.

   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 [RFC5430bis] are allowed.

   The two Suite B combinations, "SuiteB_Combination_1" or
   "SuiteB_Combination_2" from [RFC5430bis, section 3.1], satisfy the
   requirements of section 3 of this document for the DTLS connection.

   Section 4 of [RFC5430bis] describes acceptable cipher suites for use
   in a Suite B compliant system.  Only two of these cipher suites are
   allowed for use in Suite B DTLS-SRTP, namely:

      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

   For a system to implement the Suite B compliant DLTS-SRTP profile, it
   MUST follow the requirements of [RFC5430bis] for the DTLS
   connection.  The following cipher suite rules from section 4 of
   [RFC5430bis] will be 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
   [RFC5430bis], "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.



Igoe and Peck                   Informational                   [Page 5]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


   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
   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 compiant 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 [RFC5430bis] 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


Igoe and Peck                   Informational                   [Page 6]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


   requirements of section 3.  The peers will then execute the elliptic
   curve Diffie-Hellman (ECDH) key agreement to obtain a DTLS premaster
   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 [RFC5430bis].


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
        chosen, the TLS PRF with SHA-384 as the hash function MUST be
        used.  The SRTP master keys exported for the client and server


Igoe and Peck                   Informational                   [Page 7]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


        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].  [srtp-aes-gcm] defines the following SRTP protection
   profiles that will be used for Suite B.  The applicable profiles for
   each suite and their transform parameters will be listed below.  Per
   [RFC5764], the parameters: cipher_key_length, cipher_salt_length,
   auth_key_length and auth_tag_length express the number of bits in the
   values to which they refer.  The maximum_lifetime parameter indicates
   the maximum number of packets that can be protected with each single
   set of keys when the parameter profile is in use.  All of these
   parameters apply to both RTP and RTCP unless the RTCP parameters are
   separately specified.

   The following AES_126 based SRTP protection profiles are applicable
   when using the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite
   for DTLS:

         SRTP_AEAD_AES_128_GCM_8
                cipher:               AES_128_GCM
                cipher_key_length:            128
                cipher_salt_length:            96
                maximum_lifetime:            2^31
                auth_function:                N/A
                auth_key_length:              N/A
                auth_tag_length:               64

         SRTP_AEAD_AES_128_GCM_12
                cipher:               AES_128_GCM
                cipher_key_length:            128
                cipher_salt_length:            96
                maximum_lifetime:            2^31
                auth_function:                N/A
                auth_key_length:              N/A
                auth_tag_length:               96

   The following AES_256 SRTP protection profiles are applicable when
   using the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite for
   DTLS:

         SRTP_AEAD_AES_256_GCM_8
                cipher:               AES_256_GCM
                cipher_key_length:            256
                cipher_salt_length:            96
                maximum_lifetime:            2^31
                auth_function:                N/A


Igoe and Peck                   Informational                   [Page 8]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


                auth_key_length:              N/A
                auth_tag_length:               64

         SRTP_AEAD_AES_256_GCM_12
                cipher:               AES_256_GCM
                cipher_key_length:            256
                cipher_salt_length:            96
                maximum_lifetime:            2^31
                auth_function:                N/A
                auth_key_length:              N/A
                auth_tag_length:               96

   Any Suite B compliant DTLS-SRTP application MUST use one of the
   above, no other encryption of 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 SRTP_AEAD_AES_256_GCM_8 and SHOULD support
        SRTP_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
           SRTP_AEAD_AES_128_GCM_8 and and SHOULD support
           SRTP_AEAD_AES_128_GCM_12.

         o Option 2 (AES_256 based): The application MUST support
           SRTP_AEAD_AES_256_GCM_8 and and SHOULD support
           SRTP_AEAD_AES_256_GCM_12.

         o Option 3 (both AES_128 and AES_256): The application MUST
           support both SRTP_AEAD_AES_128_GCM_8 and
           SRTP_AEAD_AES_256_GCM_8 and SHOULD support
           SRTP_AEAD_AES_128_GCM_12 and SRTP_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.



Igoe and Peck                   Informational                   [Page 9]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


      o If the client offers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
        then the client MUST offer SRTP_AEAD_AES_128_GCM_8 and MAY offer
        SRTP_AEAD_AES_128_GCM_12.

      o If the client offers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
        then the client MUST offer SRTP_AEAD_AES_256_GCM_8 and MAY offer
        SRTP_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 SRTP_AEAD_AES_128_GCM_8 or
        SRTP_AEAD_AES_128_GCM_12.

      o If the server chooses TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
        then it MUST choose SRTP_AEAD_AES_256_GCM_8 or
        SRTP_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 Key Derivation

   The AES Counter Mode based key derivation function is used to derive
   session keys and salts for SRTP [RFC3711].  The session keys and
   salts MUST have the following bit sizes:

      When using the SRTP_AEAD_AES_128_GCM_8 or SRTP_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 SRTP_AEAD_AES_256_GCM_8 or SRTP_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


Igoe and Peck                  Informational                   [Page 10]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011




10. Security Considerations

   The security considerations of this document follow those in [srtp-
   aes-gcm], [RFC5764], [RFC5430bis], [RFC5759] and [RFC3711].


11.  References


11.1. Normative References

   [DTLS]          Rescorla, E., Modadugu, N., "Datagram Transport Layer
                   Security Version 1.2", draft-ietf-tls-rfc4347-bis,
                   July 2010.

   [FIPS180-3]     National Institute of Standards and Technology,
                   FIPS Publication 180-3: "Secure Hash Standard",
                   October 2008.

   [FIPS186-3]     National Institute of Standards and Technology,
                   FIPS Publication 186-3: "Digital Signature Standard
                   (DSS)", June 2009.

   [srtp-aes-gcm]  McGrew, D., Igoe, K., "AES-GCM and AES-CCM
                   Authenticated Encryption in Secure RTP (SRTP)",
                   draft-ietf-avt-srtp-aes-gcm, July 2009.

   [RFC3711]       Baugher, M. McGrew, D., Naslund, M., Carrara, E.,
                   Norrman, K., "The Secure Real-time Transport Protocol
                   (SRTP)", RFC 3711, March 2004.

   [RFC5430bis]    Salter, M., Rescorla, E. Housley, R., "Suite B
                   Profile for Transport Layer Security (TLS)",
                   July 2010.

   [RFC5759]       Solinas, J., Zieglar, L., "Suite B Certificate and
                   Certificate Revocation List (CRL) Profile",
                   January 2010.

   [RFC5764]       McGrew, D., Rescorla, E., "Datagram Transport Layer
                   Security (DTLS) Extension to Establish Keys for Secure
                   Real-time Transport Protocol (SRTP)", RFC 5764,
                   May 2010.


11.2. Informative References

   [extractor]     Rescorla, E., "Keying Material Exporters for
                   Transport Layer Security (TLS)",RFC 5705, March 2010.



Igoe and Peck                  Informational                   [Page 11]


Internet Draft        draft-peck-suiteb-dtls-srtp-00        Apr 08, 2011


   [NSA]           National Security Agency, "Fact Sheet NSA Suite B
                   Cryptography",
                   www.nsa.gov/ia/Industry/crypto_suite_b.cfm.

   [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.

   [SP800-57]      National Institute of Standards and Technology,
                   Special Publication 800-57: "Recommendation for Key
                   Management, Part 1", March 2007.



Authors Addresses
    Michael A. Peck
    The MITRE Corporation
    Email: mpeck@mitre.org

    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).























Igoe and Peck                  Informational                   [Page 12]