"Know thy self, know thy enemy. A thousand battles, a thousand victories." - Sun Tzu
Monday, January 31, 2011
Thursday, January 20, 2011
the Secure Shell Transport Layer Protocol
Network Working Group K. Igoe
Request for Comments: 5647 J. Solinas
Category: Informational National Security Agency
August 2009
AES Galois Counter Mode for
the Secure Shell Transport Layer Protocol
Abstract
Secure shell (SSH) is a secure remote-login protocol. SSH provides
for algorithms that provide authentication, key agreement,
confidentiality, and data-integrity services. The purpose of this
document is to show how the AES Galois Counter Mode can be used to
provide both confidentiality and data integrity to the SSH Transport
Layer Protocol.
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Igoe & Solinas Informational [Page 1]
RFC 5647 AES-GCM for Secure Shell August 2009
Table of Contents
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. Applicability Statement .........................................3
4. Properties of Galois Counter Mode ...............................3
4.1. AES GCM Authenticated Encryption ...........................3
4.2. AES GCM Authenticated Decryption ...........................3
5. Review of Secure Shell ..........................................4
5.1. Key Exchange ...............................................4
5.2. Secure Shell Binary Packets ................................5
6. AES GCM Algorithms for Secure Shell .............................6
6.1. AEAD_AES_128_GCM ...........................................6
6.2. AEAD_AES_256_GCM ...........................................6
6.3. Size of the Authentication Tag .............................6
7. Processing Binary Packets in AES-GCM Secure Shell ...............7
7.1. IV and Counter Management ..................................7
7.2. Formation of the Binary Packet .............................7
7.3. Treatment of the Packet Length Field .......................8
8. Security Considerations .........................................8
8.1. Use of the Packet Sequence Number in the AT ................8
8.2. Non-Encryption of Packet Length ............................8
9. IANA Considerations .............................................9
10. References ....................................................10
10.1. Normative References .....................................10
1. Introduction
Galois Counter Mode (GCM) is a block-cipher mode of operation that
provides both confidentiality and data-integrity services. GCM uses
counter mode to encrypt the data, an operation that can be
efficiently pipelined. Further, GCM authentication uses operations
that are particularly well suited to efficient implementation in
hardware, making it especially appealing for high-speed
implementations or for implementations in an efficient and compact
circuit. The purpose of this document is to show how GCM with either
AES-128 or AES-256 can be integrated into the Secure Shell Transport
Layer Protocol [RFC4253].
2. 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].
Igoe & Solinas Informational [Page 2]
RFC 5647 AES-GCM for Secure Shell August 2009
3. Applicability Statement
Using AES-GCM to provide both confidentiality and data integrity is
generally more efficient than using two separate algorithms to
provide these security services.
4. Properties of Galois Counter Mode
Galois Counter Mode (GCM) is a mode of operation for block ciphers
that provides both confidentiality and data integrity. National
Institute of Standards and Technology (NIST) Special Publication SP
800 38D [GCM] gives an excellent explanation of Galois Counter Mode.
In this document, we shall focus on AES GCM, the use of the Advanced
Encryption Algorithm (AES) in Galois Counter Mode. AES-GCM is an
example of an "algorithm for authenticated encryption with associated
data" (AEAD algorithm) as described in [RFC5116].
4.1. AES GCM Authenticated Encryption
An invocation of AES GCM to perform an authenticated encryption has
the following inputs and outputs:
GCM Authenticated Encryption
Inputs:
octet_string PT ; // Plain Text, to be both
// authenticated and encrypted
octet_string AAD; // Additional Authenticated Data,
// authenticated but not encrypted
octet_string IV; // Initialization Vector
octet_string BK; // Block Cipher Key
Outputs:
octet_string CT; // Cipher Text
octet_string AT; // Authentication Tag
Note: in [RFC5116], the IV is called the nonce.
For a given block-cipher key BK, it is critical that no IV be used
more than once. Section 7.1 addresses how this goal is to be
achieved in secure shell.
4.2. AES GCM Authenticated Decryption
An invocation of AES GCM to perform an authenticated decryption has
the following inputs and outputs:
Igoe & Solinas Informational [Page 3]
RFC 5647 AES-GCM for Secure Shell August 2009
GCM Authenticated Decryption
Inputs:
octet_string CT ; // Cipher text, to be both
// authenticated and decrypted
octet_string AAD; // Additional Authenticated Data,
// authenticated only
octet_string AT; // Authentication Tag
octet_string IV; // Initialization Vector
octet_string BK; // Block Cipher Key
Output:
Failure_Indicator; // Returned if the authentication tag
// is invalid
octet_string PT; // Plain Text, returned if and only if
// the authentication tag is valid
AES-GCM is prohibited from returning any portion of the plaintext
until the authentication tag has been validated. Though this feature
greatly simplifies the security analysis of any system using AES-GCM,
this creates an incompatibility with the requirements of secure
shell, as we shall see in Section 7.3.
5. Review of Secure Shell
The goal of secure shell is to establish two secure tunnels between a
client and a server, one tunnel carrying client-to-server
communications and the other carrying server-to-client
communications. Each tunnel is encrypted, and a message
authentication code is used to ensure data integrity.
5.1. Key Exchange
These tunnels are initialized using the secure shell key exchange
protocol as described in Section 7 of [RFC4253]. This protocol
negotiates a mutually acceptable set of cryptographic algorithms and
produces a secret value K and an exchange hash H that are shared by
the client and server. The initial value of H is saved for use as
the session_id.
If AES-GCM is selected as the encryption algorithm for a given
tunnel, AES-GCM MUST also be selected as the Message Authentication
Code (MAC) algorithm. Conversely, if AES-GCM is selected as the MAC
algorithm, it MUST also be selected as the encryption algorithm.
As described in Section 7.2 of [RFC4253], a hash-based key derivation
function (KDF) is applied to the shared secret value K to generate
the required symmetric keys. Each tunnel gets a distinct set of
Igoe & Solinas Informational [Page 4]
RFC 5647 AES-GCM for Secure Shell August 2009
symmetric keys. The keys are generated as shown in Figure 1. The
sizes of these keys varies depending upon which cryptographic
algorithms are being used.
Initial IV
Client-to-Server HASH( K || H ||"A"|| session_id)
Server-to-Client HASH( K || H ||"B"|| session_id)
Encryption Key
Client-to-Server HASH( K || H ||"C"|| session_id)
Server-to-Client HASH( K || H ||"D"|| session_id)
Integrity Key
Client-to-Server HASH( K || H ||"E"|| session_id)
Server-to-Client HASH( K || H ||"F"|| session_id)
Figure 1: Key Derivation in Secure Shell
As we shall see below, SSH AES-GCM requires a 12-octet Initial IV and
an encryption key of either 16 or 32 octets. Because an AEAD
algorithm such as AES-GCM uses the encryption key to provide both
confidentiality and data integrity, the integrity key is not used
with AES-GCM.
Either the server or client may at any time request that the secure
shell session be rekeyed. The shared secret value K, the exchange
hash H, and all the above symmetric keys will be updated. Only the
session_id will remain unchanged.
5.2. Secure Shell Binary Packets
Upon completion of the key exchange protocol, all further secure
shell traffic is parsed into a data structure known as a secure shell
binary packet as shown below in Figure 2 (see also Section 6 of
[RFC4253]).
uint32 packet_length; // 0 <= packet_length < 2^32
byte padding_length; // 4 <= padding_length < 256
byte[n1] payload; // n1 = packet_length-padding_length-1
byte[n2] random_padding; // n2 = padding_length
byte[m] mac; // m = mac_length
Figure 2: Structure of a Secure Shell Binary Packet
The authentication tag produced by AES-GCM authenticated encryption
will be placed in the MAC field at the end of the secure shell binary
packet.
Igoe & Solinas Informational [Page 5]
RFC 5647 AES-GCM for Secure Shell August 2009
6. AES GCM Algorithms for Secure Shell
6.1. AEAD_AES_128_GCM
AEAD_AES_128_GCM is specified in Section 5.1 of [RFC5116]. Due to
the format of secure shell binary packets, the buffer sizes needed to
implement AEAD_AES_128_GCM are smaller than those required in
[RFC5116]. Using the notation defined in [RFC5116], the input and
output lengths for AEAD_AES_128_GCM in secure shell are as follows:
PARAMETER Meaning Value
K_LEN AES key length 16 octets
P_MAX maximum plaintext length 2^32 - 32 octets
A_MAX maximum additional 4 octets
authenticated data length
N_MIN minimum nonce (IV) length 12 octets
N_MAX maximum nonce (IV) length 12 octets
C_MAX maximum cipher length 2^32 octets
6.2. AEAD_AES_256_GCM
AEAD_AES_256_GCM is specified in Section 5.2 of [RFC5116]. Due to
the format of secure shell binary packets, the buffer sizes needed
to implement AEAD_AES_256_GCM are smaller than those required in
[RFC5116]. Using the notation defined in [RFC5116], the input and
output lengths for AEAD_AES_256_GCM in secure shell are as follows:
PARAMETER Meaning Value
K_LEN AES key length 32 octets
P_MAX maximum plaintext length 2^32 - 32 octets
A_MAX maximum additional 4 octets
authenticated data length
N_MIN minimum nonce (IV) length 12 octets
N_MAX maximum nonce (IV) length 12 octets
C_MAX maximum cipher length 2^32 octets
6.3. Size of the Authentication Tag
Both AEAD_AES_128_GCM and AEAD_AES_256_GCM produce a 16-octet
Authentication Tag ([RFC5116] calls this a "Message Authentication
Code"). Some applications allow use of a truncated version of this
tag. This is not allowed in AES-GCM secure shell. All
implementations of AES-GCM secure shell MUST use the full 16-octet
Authentication Tag.
Igoe & Solinas Informational [Page 6]
RFC 5647 AES-GCM for Secure Shell August 2009
7. Processing Binary Packets in AES-GCM Secure Shell
7.1. IV and Counter Management
With AES-GCM, the 12-octet IV is broken into two fields: a 4-octet
fixed field and an 8-octet invocation counter field. The invocation
field is treated as a 64-bit integer and is incremented after each
invocation of AES-GCM to process a binary packet.
uint32 fixed; // 4 octets
uint64 invocation_counter; // 8 octets
Figure 3: Structure of an SSH AES-GCM Nonce
AES-GCM produces a keystream in blocks of 16-octets that is used to
encrypt the plaintext. This keystream is produced by encrypting the
following 16-octet data structure:
uint32 fixed; // 4 octets
uint64 invocation_counter; // 8 octets
uint32 block_counter; // 4 octets
Figure 4: Structure of an AES Input for SSH AES-GCM
The block_counter is initially set to one (1) and incremented as each
block of key is produced.
The reader is reminded that SSH requires that the data to be
encrypted MUST be padded out to a multiple of the block size
(16-octets for AES-GCM).
7.2. Formation of the Binary Packet
In AES-GCM secure shell, the inputs to the authenticated encryption
are:
PT (Plain Text)
byte padding_length; // 4 <= padding_length < 256
byte[n1] payload; // n1 = packet_length-padding_length-1
byte[n2] random_padding; // n2 = padding_length
AAD (Additional Authenticated Data)
uint32 packet_length; // 0 <= packet_length < 2^32
IV (Initialization Vector)
As described in section 7.1.
BK (Block Cipher Key)
The appropriate Encryption Key formed during the Key Exchange.
Igoe & Solinas Informational [Page 7]
RFC 5647 AES-GCM for Secure Shell August 2009
As required in [RFC4253], the random_padding MUST be at least 4
octets in length but no more than 255 octets. The total length of
the PT MUST be a multiple of 16 octets (the block size of AES). The
binary packet is the concatenation of the 4-octet packet_length, the
cipher text (CT), and the 16-octet authentication tag (AT).
7.3. Treatment of the Packet Length Field
Section 6.3 of [RFC4253] requires that the packet length, padding
length, payload, and padding fields of each binary packet be
encrypted. This presents a problem for SSH AES-GCM because:
1) The tag cannot be verified until we parse the binary packet.
2) The packet cannot be parsed until the packet_length has been
decrypted.
3) The packet_length cannot be decrypted until the tag has been
verified.
When using AES-GCM with secure shell, the packet_length field is to
be treated as additional authenticated data, not as plaintext. This
violates the requirements of [RFC4253]. The repercussions of this
decision are discussed in the following Security Considerations
section.
8. Security Considerations
The security considerations in [RFC4251] apply.
8.1. Use of the Packet Sequence Number in the AT
[RFC4253] requires that the formation of the AT involve the packet
sequence_number, a 32-bit value that counts the number of binary
packets that have been sent on a given SSH tunnel. Since the
sequence_number is, up to an additive constant, just the low 32 bits
of the invocation_counter, the presence of the invocation_counter
field in the IV ensures that the sequence_number is indeed involved
in the formation of the integrity tag, though this involvement
differs slightly from the requirements in Section 6.4 of [RFC4253].
8.2. Non-Encryption of Packet Length
As discussed in Section 7.3, there is an incompatibility between
GCM's requirement that no plaintext be returned until the
authentication tag has been verified, secure shell's requirement that
the packet length be encrypted, and the necessity of decrypting the
packet length field to locate the authentication tag. This document
Igoe & Solinas Informational [Page 8]
RFC 5647 AES-GCM for Secure Shell August 2009
addresses this dilemma by requiring that, in AES-GCM, the packet
length field will not be encrypted but will instead be processed as
additional authenticated data.
In theory, one could argue that encryption of the entire binary
packet means that the secure shell dataflow becomes a featureless
octet stream. But in practice, the secure shell dataflow will come
in bursts, with the length of each burst strongly correlated to the
length of the underlying binary packets. Encryption of the packet
length does little in and of itself to disguise the length of the
underlying binary packets. Secure shell provides two other
mechanisms, random padding and SSH_MSG_IGNORE messages, that are far
more effective than encrypting the packet length in masking any
structure in the underlying plaintext stream that might be revealed
by the length of the binary packets.
9. IANA Considerations
IANA added the following two entries to the secure shell Encryption
Algorithm Names registry described in [RFC4250]:
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.2 |
+--------------------+-------------+
IANA added the following two entries to the secure shell MAC
Algorithm Names registry described in [RFC4250]:
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.2 |
+--------------------+-------------+
Igoe & Solinas Informational [Page 9]
RFC 5647 AES-GCM for Secure Shell August 2009
10. References
10.1. Normative References
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-30D, November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
Authors' Addresses
Kevin M. Igoe
NSA/CSS Commercial Solutions Center
National Security Agency
USA
EMail: kmigoe@nsa.gov
Jerome A. Solinas
National Information Assurance Research Laboratory
National Security Agency
USA
EMail: jasolin@orion.ncsc.mil
Igoe & Solinas Informational [Page 10]
Html markup produced by rfcmarkup 1.91, available from http://tools.ietf.org/tools/rfcmarkup/
Request for Comments: 5647 J. Solinas
Category: Informational National Security Agency
August 2009
AES Galois Counter Mode for
the Secure Shell Transport Layer Protocol
Abstract
Secure shell (SSH) is a secure remote-login protocol. SSH provides
for algorithms that provide authentication, key agreement,
confidentiality, and data-integrity services. The purpose of this
document is to show how the AES Galois Counter Mode can be used to
provide both confidentiality and data integrity to the SSH Transport
Layer Protocol.
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Igoe & Solinas Informational [Page 1]
RFC 5647 AES-GCM for Secure Shell August 2009
Table of Contents
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. Applicability Statement .........................................3
4. Properties of Galois Counter Mode ...............................3
4.1. AES GCM Authenticated Encryption ...........................3
4.2. AES GCM Authenticated Decryption ...........................3
5. Review of Secure Shell ..........................................4
5.1. Key Exchange ...............................................4
5.2. Secure Shell Binary Packets ................................5
6. AES GCM Algorithms for Secure Shell .............................6
6.1. AEAD_AES_128_GCM ...........................................6
6.2. AEAD_AES_256_GCM ...........................................6
6.3. Size of the Authentication Tag .............................6
7. Processing Binary Packets in AES-GCM Secure Shell ...............7
7.1. IV and Counter Management ..................................7
7.2. Formation of the Binary Packet .............................7
7.3. Treatment of the Packet Length Field .......................8
8. Security Considerations .........................................8
8.1. Use of the Packet Sequence Number in the AT ................8
8.2. Non-Encryption of Packet Length ............................8
9. IANA Considerations .............................................9
10. References ....................................................10
10.1. Normative References .....................................10
1. Introduction
Galois Counter Mode (GCM) is a block-cipher mode of operation that
provides both confidentiality and data-integrity services. GCM uses
counter mode to encrypt the data, an operation that can be
efficiently pipelined. Further, GCM authentication uses operations
that are particularly well suited to efficient implementation in
hardware, making it especially appealing for high-speed
implementations or for implementations in an efficient and compact
circuit. The purpose of this document is to show how GCM with either
AES-128 or AES-256 can be integrated into the Secure Shell Transport
Layer Protocol [RFC4253].
2. 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].
Igoe & Solinas Informational [Page 2]
RFC 5647 AES-GCM for Secure Shell August 2009
3. Applicability Statement
Using AES-GCM to provide both confidentiality and data integrity is
generally more efficient than using two separate algorithms to
provide these security services.
4. Properties of Galois Counter Mode
Galois Counter Mode (GCM) is a mode of operation for block ciphers
that provides both confidentiality and data integrity. National
Institute of Standards and Technology (NIST) Special Publication SP
800 38D [GCM] gives an excellent explanation of Galois Counter Mode.
In this document, we shall focus on AES GCM, the use of the Advanced
Encryption Algorithm (AES) in Galois Counter Mode. AES-GCM is an
example of an "algorithm for authenticated encryption with associated
data" (AEAD algorithm) as described in [RFC5116].
4.1. AES GCM Authenticated Encryption
An invocation of AES GCM to perform an authenticated encryption has
the following inputs and outputs:
GCM Authenticated Encryption
Inputs:
octet_string PT ; // Plain Text, to be both
// authenticated and encrypted
octet_string AAD; // Additional Authenticated Data,
// authenticated but not encrypted
octet_string IV; // Initialization Vector
octet_string BK; // Block Cipher Key
Outputs:
octet_string CT; // Cipher Text
octet_string AT; // Authentication Tag
Note: in [RFC5116], the IV is called the nonce.
For a given block-cipher key BK, it is critical that no IV be used
more than once. Section 7.1 addresses how this goal is to be
achieved in secure shell.
4.2. AES GCM Authenticated Decryption
An invocation of AES GCM to perform an authenticated decryption has
the following inputs and outputs:
Igoe & Solinas Informational [Page 3]
RFC 5647 AES-GCM for Secure Shell August 2009
GCM Authenticated Decryption
Inputs:
octet_string CT ; // Cipher text, to be both
// authenticated and decrypted
octet_string AAD; // Additional Authenticated Data,
// authenticated only
octet_string AT; // Authentication Tag
octet_string IV; // Initialization Vector
octet_string BK; // Block Cipher Key
Output:
Failure_Indicator; // Returned if the authentication tag
// is invalid
octet_string PT; // Plain Text, returned if and only if
// the authentication tag is valid
AES-GCM is prohibited from returning any portion of the plaintext
until the authentication tag has been validated. Though this feature
greatly simplifies the security analysis of any system using AES-GCM,
this creates an incompatibility with the requirements of secure
shell, as we shall see in Section 7.3.
5. Review of Secure Shell
The goal of secure shell is to establish two secure tunnels between a
client and a server, one tunnel carrying client-to-server
communications and the other carrying server-to-client
communications. Each tunnel is encrypted, and a message
authentication code is used to ensure data integrity.
5.1. Key Exchange
These tunnels are initialized using the secure shell key exchange
protocol as described in Section 7 of [RFC4253]. This protocol
negotiates a mutually acceptable set of cryptographic algorithms and
produces a secret value K and an exchange hash H that are shared by
the client and server. The initial value of H is saved for use as
the session_id.
If AES-GCM is selected as the encryption algorithm for a given
tunnel, AES-GCM MUST also be selected as the Message Authentication
Code (MAC) algorithm. Conversely, if AES-GCM is selected as the MAC
algorithm, it MUST also be selected as the encryption algorithm.
As described in Section 7.2 of [RFC4253], a hash-based key derivation
function (KDF) is applied to the shared secret value K to generate
the required symmetric keys. Each tunnel gets a distinct set of
Igoe & Solinas Informational [Page 4]
RFC 5647 AES-GCM for Secure Shell August 2009
symmetric keys. The keys are generated as shown in Figure 1. The
sizes of these keys varies depending upon which cryptographic
algorithms are being used.
Initial IV
Client-to-Server HASH( K || H ||"A"|| session_id)
Server-to-Client HASH( K || H ||"B"|| session_id)
Encryption Key
Client-to-Server HASH( K || H ||"C"|| session_id)
Server-to-Client HASH( K || H ||"D"|| session_id)
Integrity Key
Client-to-Server HASH( K || H ||"E"|| session_id)
Server-to-Client HASH( K || H ||"F"|| session_id)
Figure 1: Key Derivation in Secure Shell
As we shall see below, SSH AES-GCM requires a 12-octet Initial IV and
an encryption key of either 16 or 32 octets. Because an AEAD
algorithm such as AES-GCM uses the encryption key to provide both
confidentiality and data integrity, the integrity key is not used
with AES-GCM.
Either the server or client may at any time request that the secure
shell session be rekeyed. The shared secret value K, the exchange
hash H, and all the above symmetric keys will be updated. Only the
session_id will remain unchanged.
5.2. Secure Shell Binary Packets
Upon completion of the key exchange protocol, all further secure
shell traffic is parsed into a data structure known as a secure shell
binary packet as shown below in Figure 2 (see also Section 6 of
[RFC4253]).
uint32 packet_length; // 0 <= packet_length < 2^32
byte padding_length; // 4 <= padding_length < 256
byte[n1] payload; // n1 = packet_length-padding_length-1
byte[n2] random_padding; // n2 = padding_length
byte[m] mac; // m = mac_length
Figure 2: Structure of a Secure Shell Binary Packet
The authentication tag produced by AES-GCM authenticated encryption
will be placed in the MAC field at the end of the secure shell binary
packet.
Igoe & Solinas Informational [Page 5]
RFC 5647 AES-GCM for Secure Shell August 2009
6. AES GCM Algorithms for Secure Shell
6.1. AEAD_AES_128_GCM
AEAD_AES_128_GCM is specified in Section 5.1 of [RFC5116]. Due to
the format of secure shell binary packets, the buffer sizes needed to
implement AEAD_AES_128_GCM are smaller than those required in
[RFC5116]. Using the notation defined in [RFC5116], the input and
output lengths for AEAD_AES_128_GCM in secure shell are as follows:
PARAMETER Meaning Value
K_LEN AES key length 16 octets
P_MAX maximum plaintext length 2^32 - 32 octets
A_MAX maximum additional 4 octets
authenticated data length
N_MIN minimum nonce (IV) length 12 octets
N_MAX maximum nonce (IV) length 12 octets
C_MAX maximum cipher length 2^32 octets
6.2. AEAD_AES_256_GCM
AEAD_AES_256_GCM is specified in Section 5.2 of [RFC5116]. Due to
the format of secure shell binary packets, the buffer sizes needed
to implement AEAD_AES_256_GCM are smaller than those required in
[RFC5116]. Using the notation defined in [RFC5116], the input and
output lengths for AEAD_AES_256_GCM in secure shell are as follows:
PARAMETER Meaning Value
K_LEN AES key length 32 octets
P_MAX maximum plaintext length 2^32 - 32 octets
A_MAX maximum additional 4 octets
authenticated data length
N_MIN minimum nonce (IV) length 12 octets
N_MAX maximum nonce (IV) length 12 octets
C_MAX maximum cipher length 2^32 octets
6.3. Size of the Authentication Tag
Both AEAD_AES_128_GCM and AEAD_AES_256_GCM produce a 16-octet
Authentication Tag ([RFC5116] calls this a "Message Authentication
Code"). Some applications allow use of a truncated version of this
tag. This is not allowed in AES-GCM secure shell. All
implementations of AES-GCM secure shell MUST use the full 16-octet
Authentication Tag.
Igoe & Solinas Informational [Page 6]
RFC 5647 AES-GCM for Secure Shell August 2009
7. Processing Binary Packets in AES-GCM Secure Shell
7.1. IV and Counter Management
With AES-GCM, the 12-octet IV is broken into two fields: a 4-octet
fixed field and an 8-octet invocation counter field. The invocation
field is treated as a 64-bit integer and is incremented after each
invocation of AES-GCM to process a binary packet.
uint32 fixed; // 4 octets
uint64 invocation_counter; // 8 octets
Figure 3: Structure of an SSH AES-GCM Nonce
AES-GCM produces a keystream in blocks of 16-octets that is used to
encrypt the plaintext. This keystream is produced by encrypting the
following 16-octet data structure:
uint32 fixed; // 4 octets
uint64 invocation_counter; // 8 octets
uint32 block_counter; // 4 octets
Figure 4: Structure of an AES Input for SSH AES-GCM
The block_counter is initially set to one (1) and incremented as each
block of key is produced.
The reader is reminded that SSH requires that the data to be
encrypted MUST be padded out to a multiple of the block size
(16-octets for AES-GCM).
7.2. Formation of the Binary Packet
In AES-GCM secure shell, the inputs to the authenticated encryption
are:
PT (Plain Text)
byte padding_length; // 4 <= padding_length < 256
byte[n1] payload; // n1 = packet_length-padding_length-1
byte[n2] random_padding; // n2 = padding_length
AAD (Additional Authenticated Data)
uint32 packet_length; // 0 <= packet_length < 2^32
IV (Initialization Vector)
As described in section 7.1.
BK (Block Cipher Key)
The appropriate Encryption Key formed during the Key Exchange.
Igoe & Solinas Informational [Page 7]
RFC 5647 AES-GCM for Secure Shell August 2009
As required in [RFC4253], the random_padding MUST be at least 4
octets in length but no more than 255 octets. The total length of
the PT MUST be a multiple of 16 octets (the block size of AES). The
binary packet is the concatenation of the 4-octet packet_length, the
cipher text (CT), and the 16-octet authentication tag (AT).
7.3. Treatment of the Packet Length Field
Section 6.3 of [RFC4253] requires that the packet length, padding
length, payload, and padding fields of each binary packet be
encrypted. This presents a problem for SSH AES-GCM because:
1) The tag cannot be verified until we parse the binary packet.
2) The packet cannot be parsed until the packet_length has been
decrypted.
3) The packet_length cannot be decrypted until the tag has been
verified.
When using AES-GCM with secure shell, the packet_length field is to
be treated as additional authenticated data, not as plaintext. This
violates the requirements of [RFC4253]. The repercussions of this
decision are discussed in the following Security Considerations
section.
8. Security Considerations
The security considerations in [RFC4251] apply.
8.1. Use of the Packet Sequence Number in the AT
[RFC4253] requires that the formation of the AT involve the packet
sequence_number, a 32-bit value that counts the number of binary
packets that have been sent on a given SSH tunnel. Since the
sequence_number is, up to an additive constant, just the low 32 bits
of the invocation_counter, the presence of the invocation_counter
field in the IV ensures that the sequence_number is indeed involved
in the formation of the integrity tag, though this involvement
differs slightly from the requirements in Section 6.4 of [RFC4253].
8.2. Non-Encryption of Packet Length
As discussed in Section 7.3, there is an incompatibility between
GCM's requirement that no plaintext be returned until the
authentication tag has been verified, secure shell's requirement that
the packet length be encrypted, and the necessity of decrypting the
packet length field to locate the authentication tag. This document
Igoe & Solinas Informational [Page 8]
RFC 5647 AES-GCM for Secure Shell August 2009
addresses this dilemma by requiring that, in AES-GCM, the packet
length field will not be encrypted but will instead be processed as
additional authenticated data.
In theory, one could argue that encryption of the entire binary
packet means that the secure shell dataflow becomes a featureless
octet stream. But in practice, the secure shell dataflow will come
in bursts, with the length of each burst strongly correlated to the
length of the underlying binary packets. Encryption of the packet
length does little in and of itself to disguise the length of the
underlying binary packets. Secure shell provides two other
mechanisms, random padding and SSH_MSG_IGNORE messages, that are far
more effective than encrypting the packet length in masking any
structure in the underlying plaintext stream that might be revealed
by the length of the binary packets.
9. IANA Considerations
IANA added the following two entries to the secure shell Encryption
Algorithm Names registry described in [RFC4250]:
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.2 |
+--------------------+-------------+
IANA added the following two entries to the secure shell MAC
Algorithm Names registry described in [RFC4250]:
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.2 |
+--------------------+-------------+
Igoe & Solinas Informational [Page 9]
RFC 5647 AES-GCM for Secure Shell August 2009
10. References
10.1. Normative References
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-30D, November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
Authors' Addresses
Kevin M. Igoe
NSA/CSS Commercial Solutions Center
National Security Agency
USA
EMail: kmigoe@nsa.gov
Jerome A. Solinas
National Information Assurance Research Laboratory
National Security Agency
USA
EMail: jasolin@orion.ncsc.mil
Igoe & Solinas Informational [Page 10]
Html markup produced by rfcmarkup 1.91, available from http://tools.ietf.org/tools/rfcmarkup/
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
Network Working Group R. Housley
Request for Comments: 5008 Vigil Security
Category: Informational J. Solinas
NSA
September 2007
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document specifies the conventions for using the United States
National Security Agency's Suite B algorithms in Secure/Multipurpose
Internet Mail Extensions (S/MIME) as specified in RFC 3851.
1. Introduction
This document specifies the conventions for using the United States
National Security Agency's Suite B algorithms [SuiteB] in
Secure/Multipurpose Internet Mail Extensions (S/MIME) [MSG]. S/MIME
makes use of the Cryptographic Message Syntax (CMS) [CMS]. In
particular, the signed-data and the enveloped-data content types are
used.
Since many of the Suite B algorithms enjoy uses in other environments
as well, the majority of the conventions needed for the Suite B
algorithms are already specified in other documents. This document
references the source of these conventions, and the relevant details
are repeated to aid developers that choose to support Suite B. In a
few cases, additional algorithm identifiers are needed, and they are
provided in this document.
1.1. 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 RFC 2119 [STDWORDS].
Housley & Solinas Informational [Page 1]
RFC 5008 Suite B in S/MIME September 2007
1.2. ASN.1
CMS values are generated using ASN.1 [X.208-88], the Basic Encoding
Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)
[X.509-88].
1.3. Suite B Security Levels
Suite B offers two security levels: Level 1 and Level 2. Security
Level 2 offers greater cryptographic strength by using longer keys.
For S/MIME signed messages, Suite B follows the direction set by RFC
3278 [CMSECC], but some additional algorithm identifiers are
assigned. Suite B uses these algorithms:
Security Level 1 Security Level 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
For S/MIME-encrypted messages, Suite B follows the direction set by
RFC 3278 [CMSECC] and follows the conventions set by RFC 3565
[CMSAES]. Again, additional algorithm identifiers are assigned.
Suite B uses these algorithms:
Security Level 1 Security Level 2
---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC
2. SHA-256 and SHA-256 Message Digest Algorithms
This section specifies the conventions employed by implementations
that support SHA-256 or SHA-384 [SHA2]. In Suite B, Security Level
1, the SHA-256 message digest algorithm MUST be used. In Suite B,
Security Level 2, SHA-384 MUST be used.
Within the CMS signed-data content type, message digest algorithm
identifiers are located in the SignedData digestAlgorithms field and
the SignerInfo digestAlgorithm field. Also, message digest values
are located in the Message Digest authenticated attribute. In
addition, message digest values are input into signature algorithms.
The SHA-256 and SHA-384 message digest algorithms are defined in FIPS
Pub 180-2 [SHA2, EH]. The algorithm identifier for SHA-256 is:
Housley & Solinas Informational [Page 2]
RFC 5008 Suite B in S/MIME September 2007
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
The algorithm identifier for SHA-384 is:
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
There are two possible encodings for the AlgorithmIdentifier
parameters field. The two alternatives arise from the fact that when
the 1988 syntax for AlgorithmIdentifier was translated into the 1997
syntax, the OPTIONAL associated with the AlgorithmIdentifier
parameters got lost. Later, the OPTIONAL was recovered via a defect
report, but by then many people thought that algorithm parameters
were mandatory. Because of this history some implementations encode
parameters as a NULL element and others omit them entirely. The
correct encoding for the SHA-256 and SHA-384 message digest
algorithms is to omit the parameters field; however, to ensure
compatibility, implementations ought to also handle a SHA-256 and
SHA-384 AlgorithmIdentifier parameters field, which contains a NULL.
For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters
field is OPTIONAL, and if present, the parameters field MUST contain
a NULL. Implementations MUST accept SHA-256 and SHA-384
AlgorithmIdentifiers with absent parameters. Implementations MUST
accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters.
Implementations SHOULD generate SHA-256 and SHA-384
AlgorithmIdentifiers with absent parameters.
3. ECDSA Signature Algorithm
This section specifies the conventions employed by implementations
that support Elliptic Curve Digital Signature Algorithm (ECDSA). The
direction set by RFC 3278 [CMSECC] is followed, but additional
message digest algorithms and additional elliptic curves are
employed. In Suite B, Security Level 1, ECDSA MUST be used with the
SHA-256 message digest algorithm and the P-256 elliptic curve. In
Suite B, Security Level 2, ECDSA MUST be used with the SHA-384
message digest algorithm and the P-384 elliptic curve. The P-256 and
P-384 elliptic curves are specified in [DSS].
Within the CMS signed-data content type, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field of
SignedData. In addition, signature algorithm identifiers are located
in the SignerInfo signatureAlgorithm field of countersignature
attributes.
Housley & Solinas Informational [Page 3]
RFC 5008 Suite B in S/MIME September 2007
Within the CMS signed-data content type, signature values are located
in the SignerInfo signature field of SignedData. In addition,
signature values are located in the SignerInfo signature field of
countersignature attributes.
As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve
Diffie-Hellman (ECDH) use the same algorithm identifier for subject
public keys in certificates, and it is repeated here:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) keyType(2) 1 }
This object identifier is used in public key certificates for both
ECDSA signature keys and ECDH encryption keys. The intended
application for the key may be indicated in the key usage field (see
RFC 3280 [PKIX1]). The use of separate keys for signature and
encryption purposes is RECOMMENDED; however, the use of a single key
for both signature and encryption purposes is not forbidden.
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same
encoding for subject public keys in certificates, and it is repeated
here:
ECPoint ::= OCTET STRING
The elliptic curve public key (an OCTET STRING) is mapped to a
subject public key (a BIT STRING) as follows: the most significant
bit of the OCTET STRING becomes the most significant bit of the BIT
STRING, and the least significant bit of the OCTET STRING becomes the
least significant bit of the BIT STRING. Note that this octet string
may represent an elliptic curve point in compressed or uncompressed
form. Implementations that support elliptic curves according to this
specification MUST support the uncompressed form and MAY support the
compressed form.
ECDSA and ECDH require use of certain parameters with the public key.
The parameters may be inherited from the certificate issuer,
implicitly included through reference to a named curve, or explicitly
included in the certificate. As specified in RFC 3279 [PKIX1ALG],
the parameter structure is:
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
Housley & Solinas Informational [Page 4]
RFC 5008 Suite B in S/MIME September 2007
In Suite B, the namedCurve CHOICE MUST be used. The object
identifier for P-256 is:
ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) curves(3) prime(1) 7 }
The object identifier for P-384 is:
secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 }
The algorithm identifier used in CMS for ECDSA with SHA-256 signature
values is:
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
The algorithm identifier used in CMS for ECDSA with SHA-384 signature
values is:
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm
identifier is used, the AlgorithmIdentifier parameters field MUST be
absent.
When signing, the ECDSA algorithm generates two values, commonly
called r and s. To transfer these two values as one signature, they
MUST be encoded using the Ecdsa-Sig-Value type specified in RFC 3279
[PKIX1ALG]:
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
4. Key Management
CMS accommodates the following general key management techniques: key
agreement, key transport, previously distributed symmetric key-
encryption keys, and passwords. In Suite B, ephemeral-static key
agreement MUST be used as described in Section 4.1.
When a key agreement algorithm is used, a key-encryption algorithm is
also needed. In Suite B, the Advanced Encryption Standard (AES) Key
Wrap, as specified in RFC 3394 [AESWRAP, SH], MUST be used as the
key-encryption algorithm. AES Key Wrap is discussed further in
Section 4.2. The key-encryption key used with the AES Key Wrap
Housley & Solinas Informational [Page 5]
RFC 5008 Suite B in S/MIME September 2007
algorithm is obtained from a key derivation function (KDF). In Suite
B, there are two KDFs, one based on SHA-256 and one based on SHA-384.
These KDFs are discussed further in Section 4.3.
4.1. ECDH Key Agreement Algorithm
This section specifies the conventions employed by implementations
that support ECDH. The direction set by RFC 3278 [CMSECC] is
followed, but additional key derivation functions and key wrap
algorithms are employed. S/MIME is used in store-and-forward
communications, which means that ephemeral-static ECDH is always
employed. This means that the message originator uses an ephemeral
ECDH key and that the message recipient uses a static ECDH key, which
is obtained from an X.509 certificate. In Suite B, Security Level 1,
ephemeral-static ECDH MUST be used with the SHA-256 KDF, AES-128 Key
Wrap, and the P-256 elliptic curve. In Suite B, Security Level 2,
ephemeral-static ECDH MUST be used with the SHA-384 KDF, AES-256 Key
Wrap, and the P-384 elliptic curve.
Within the CMS enveloped-data content type, key agreement algorithm
identifiers are located in the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same
conventions for carrying a subject public key in a certificate.
These conventions are discussed in Section 3.
Ephemeral-static ECDH key agreement is defined in [SEC1] and
[IEEE1363]. When using ephemeral-static ECDH, the EnvelopedData
RecipientInfos keyAgreeRecipientInfo field is used as follows:
version MUST be 3.
originator MUST be the originatorKey alternative. The
originatorKey algorithm field MUST contain the id-ecPublicKey
object identifier (see Section 3) with NULL parameters. The
originatorKey publicKey field MUST contain the message
originator's ephemeral public key, which is a DER-encoded ECPoint
(see Section 3). The ECPoint SHOULD be represented in
uncompressed form.
ukm can be present or absent. However, message originators SHOULD
include the ukm. As specified in RFC 3852 [CMS], implementations
MUST support ukm message recipient processing, so interoperability
is not a concern if the ukm is present or absent. When present,
the ukm is used to ensure that a different key-encryption key is
generated, even when the ephemeral private key is improperly used
Housley & Solinas Informational [Page 6]
RFC 5008 Suite B in S/MIME September 2007
more than once. See [RANDOM] for guidance on generation of random
values.
keyEncryptionAlgorithm MUST be one of the two algorithm
identifiers listed below, and the algorithm identifier parameter
field MUST be present and identify the key wrap algorithm. The
key wrap algorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key-
encryption key generated using the ephemeral-static ECDH key
agreement algorithm (see Section 4.3). In Suite B, Security Level
1, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-
sha256kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be
a KeyWrapAlgorithm containing id-aes128-wrap (see Section 4.2).
In Suite B, Security Level 2, the keyEncryptionAlgorithm MUST be
dhSinglePass-stdDH-sha384kdf-scheme, and the
keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm
containing id-aes256-wrap (see Section 4.2). The algorithm
identifier for dhSinglePass-stdDH-sha256kdf-scheme and
dhSinglePass-stdDH-sha384kdf-scheme are:
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
Both of these algorithm identifiers use KeyWrapAlgorithm as the
type for their parameter:
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static ECDH public key.
RecipientEncryptedKey EncryptedKey MUST contain the content-
encryption key encrypted with the ephemeral-static, ECDH-generated
pairwise key-encryption key using the algorithm specified by the
KeyWrapAlgorithm (see Section 4.3).
Housley & Solinas Informational [Page 7]
RFC 5008 Suite B in S/MIME September 2007
4.2. AES Key Wrap
CMS offers support for symmetric key-encryption key management;
however, it is not used in Suite B. Rather, the AES Key Wrap key-
encryption algorithm, as specified in RFC 3394 [AESWRAP, SH], is used
to encrypt the content-encryption key with a pairwise key-encryption
key that is generated using ephemeral-static ECDH. In Suite B,
Security Level 1, AES-128 Key Wrap MUST be used as the key-encryption
algorithm. In Suite B, Security Level 2, AES-256 Key Wrap MUST be
used as the key-encryption algorithm.
Within the CMS enveloped-data content type, wrapped content-
encryption keys are located in the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, and
key wrap algorithm identifiers are located in the KeyWrapAlgorithm
parameters within the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
The algorithm identifiers for AES Key Wrap are specified in RFC 3394
[SH], and the ones needed for Suite B are repeated here:
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 }
4.3. Key Derivation Functions
CMS offers support for deriving symmetric key-encryption keys from
passwords; however, password-based key management is not used in
Suite B. Rather, KDFs based on SHA-256 and SHA-384 are used to
derive a pairwise key-encryption key from the shared secret produced
by ephemeral-static ECDH. In Suite B, Security Level 1, the KDF
based on SHA-256 MUST be used. In Suite B, Security Level 2, KDF
based on SHA-384 MUST be used.
As specified in Section 8.2 of RFC 3278 [CMSECC], using ECDH with the
CMS enveloped-data content type, the derivation of key-encryption
keys makes use of the ECC-CMS-SharedInfo type, which is repeated
here:
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
Housley & Solinas Informational [Page 8]
RFC 5008 Suite B in S/MIME September 2007
In Suite B, the fields of ECC-CMS-SharedInfo are used as follows:
keyInfo contains the object identifier of the key-encryption
algorithm that will be used to wrap the content-encryption key and
NULL parameters. In Suite B, Security Level 1, AES-128 Key Wrap
MUST be used, resulting in {id-aes128-wrap, NULL}. In Suite B,
Security Level 2, AES-256 Key Wrap MUST be used, resulting in
{id-aes256-wrap, NULL}.
entityUInfo optionally contains a random value provided by the
message originator. If the ukm is present, then the entityUInfo
MUST be present, and it MUST contain the ukm value. If the ukm is
not present, then the entityUInfo MUST be absent.
suppPubInfo contains the length of the generated key-encryption
key, in bits, represented as a 32-bit unsigned number, as
described in RFC 2631 [CMSDH]. In Suite B, Security Level 1, a
128-bit AES key MUST be used, resulting in 0x00000080. In Suite
B, Security Level 2, a 256-bit AES key MUST be used, resulting in
0x00000100.
ECC-CMS-SharedInfo is DER-encoded and used as input to the key
derivation function, as specified in Section 3.6.1 of [SEC1]. Note
that ECC-CMS-SharedInfo differs from the OtherInfo specified in
[CMSDH]. Here, a counter value is not included in the keyInfo field
because the KDF specified in [SEC1] ensures that sufficient keying
data is provided.
The KDF specified in [SEC1] provides an algorithm for generating an
essentially arbitrary amount of keying material from the shared
secret produced by ephemeral-static ECDH, which is called Z for the
remainder of this discussion. The KDF can be summarized as:
KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
To generate a key-encryption key, one or more KM blocks are
generated, incrementing Counter appropriately, until enough material
has been generated. The KM blocks are concatenated left to right:
KEK = KM ( counter=1 ) || KM ( counter=2 ) ...
The elements of the KDF are used as follows:
Hash is the one-way hash function, and it is either SHA-256 or
SHA-384 [SHA2]. In Suite B, Security Level 1, the SHA-256 MUST be
used. In Suite B, Security Level 2, SHA-384 MUST be used.
Housley & Solinas Informational [Page 9]
RFC 5008 Suite B in S/MIME September 2007
Z is the shared secret value generated by ephemeral-static ECDH.
Leading zero bits MUST be preserved. In Suite B, Security Level
1, Z MUST be exactly 256 bits. In Suite B, Security Level 2, Z
MUST be exactly 384 bits.
Counter is a 32-bit unsigned number, represented in network byte
order. Its initial value MUST be 0x00000001 for any key
derivation operation. In Suite B, Security Level 1 and Security
Level 2, exactly one iteration is needed; the Counter is not
incremented.
ECC-CMS-SharedInfo is composed as described above. It MUST be DER
encoded.
To generate a key-encryption key, one KM block is generated, with a
Counter value of 0x00000001:
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
In Suite B, Security Level 1, the key-encryption key MUST be the most
significant 128 bits of the SHA-256 output value. In Suite B,
Security Level 2, the key-encryption key MUST be the most significant
256 bits of the SHA-384 output value.
Note that the only source of secret entropy in this computation is Z.
The effective key space of the key-encryption key is limited by the
size of Z, in addition to any security level considerations imposed
by the elliptic curve that is used. However, if entityUInfo is
different for each message, a different key-encryption key will be
generated for each message.
5. AES CBC Content Encryption
This section specifies the conventions employed by implementations
that support content encryption using AES [AES] in Cipher Block
Chaining (CBC) mode [MODES]. The conventions in RFC 3565 [CMSAES]
are followed. In Suite B, Security Level 1, the AES-128 in CBC mode
MUST be used for content encryption. In Suite B, Security Level 2,
AES-256 in CBC mode MUST be used.
Within the CMS enveloped-data content type, content encryption
algorithm identifiers are located in the EnvelopedData
EncryptedContentInfo contentEncryptionAlgorithm field. The content
encryption algorithm is used to encipher the content located in the
EnvelopedData EncryptedContentInfo encryptedContent field.
The AES CBC content-encryption algorithm is described in [AES] and
[MODES]. The algorithm identifier for AES-128 in CBC mode is:
Housley & Solinas Informational [Page 10]
RFC 5008 Suite B in S/MIME September 2007
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 }
The algorithm identifier for AES-256 in CBC mode is:
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 42 }
The AlgorithmIdentifier parameters field MUST be present, and the
parameters field must contain AES-IV:
AES-IV ::= OCTET STRING (SIZE(16))
The 16-octet initialization vector is generated at random by the
originator. See [RANDOM] for guidance on generation of random
values.
6. Security Considerations
This document specifies the conventions for using the NSA's Suite B
algorithms in S/MIME. All of the algorithms have been specified in
previous documents, although a few new algorithm identifiers have
been assigned.
Two levels of security may be achieved using this specification.
Users must consider their risk environment to determine which level
is appropriate for their own use.
For signed and encrypted messages, Suite B provides a consistent
level of security for confidentiality and integrity of the message
content.
The security considerations in RFC 3852 [CMS] discuss the CMS as a
method for digitally signing data and encrypting data.
The security considerations in RFC 3370 [CMSALG] discuss
cryptographic algorithm implementation concerns in the context of the
CMS.
The security considerations in RFC 3278 [CMSECC] discuss the use of
elliptic curve cryptography (ECC) in the CMS.
The security considerations in RFC 3565 [CMSAES] discuss the use of
AES in the CMS.
Housley & Solinas Informational [Page 11]
RFC 5008 Suite B in S/MIME September 2007
7. References
7.1. Normative References
[AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AESWRAP] National Institute of Standards and Technology, "AES Key
Wrap Specification", 17 November 2001. [See
http://csrc.nist.gov/encryption/kms/key-wrap.pdf]
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-2, January 2000.
[ECDSA] American National Standards Institute, "Public Key
Cryptography For The Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI
X9.62-1998, 1999.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS)", RFC 3565, July 2003.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
Elliptic Curve Cryptography (ECC) Algorithms in
Cryptographic Message Syntax (CMS)", RFC 3278, April
2002.
[IEEE1363] Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography",
IEEE Std 1363, 2000.
[MODES] National Institute of Standards and Technology, "DES
Modes of Operation", FIPS Pub 81, 2 December 1980.
[MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
Housley & Solinas Informational [Page 12]
RFC 5008 Suite B in S/MIME September 2007
[PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[PKIX1ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", 2000. [See http://www.secg.org/
collateral/sec1.pdf.]
[SH] Schaad, J., and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[SHA2] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, 1 August 2002.
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
[X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988.
7.2. Informative References
[EH] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[SuiteB] National Security Agency, "Fact Sheet NSA Suite B
Cryptography", July 2005. [See http://www.nsa.gov/ia/
industry/crypto_Suite_b.cfm?MenuID=10.2.7)
Housley & Solinas Informational [Page 13]
RFC 5008 Suite B in S/MIME September 2007
Authors' Addresses
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Jerome A. Solinas
National Information Assurance Laboratory
National Security Agency
9800 Savage Road
Fort George G. Meade, MD 20755
USA
EMail: jasolin@orion.ncsc.mil
Housley & Solinas Informational [Page 14]
RFC 5008 Suite B in S/MIME September 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Housley & Solinas Informational [Page 15]
Request for Comments: 5008 Vigil Security
Category: Informational J. Solinas
NSA
September 2007
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document specifies the conventions for using the United States
National Security Agency's Suite B algorithms in Secure/Multipurpose
Internet Mail Extensions (S/MIME) as specified in RFC 3851.
1. Introduction
This document specifies the conventions for using the United States
National Security Agency's Suite B algorithms [SuiteB] in
Secure/Multipurpose Internet Mail Extensions (S/MIME) [MSG]. S/MIME
makes use of the Cryptographic Message Syntax (CMS) [CMS]. In
particular, the signed-data and the enveloped-data content types are
used.
Since many of the Suite B algorithms enjoy uses in other environments
as well, the majority of the conventions needed for the Suite B
algorithms are already specified in other documents. This document
references the source of these conventions, and the relevant details
are repeated to aid developers that choose to support Suite B. In a
few cases, additional algorithm identifiers are needed, and they are
provided in this document.
1.1. 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 RFC 2119 [STDWORDS].
Housley & Solinas Informational [Page 1]
RFC 5008 Suite B in S/MIME September 2007
1.2. ASN.1
CMS values are generated using ASN.1 [X.208-88], the Basic Encoding
Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)
[X.509-88].
1.3. Suite B Security Levels
Suite B offers two security levels: Level 1 and Level 2. Security
Level 2 offers greater cryptographic strength by using longer keys.
For S/MIME signed messages, Suite B follows the direction set by RFC
3278 [CMSECC], but some additional algorithm identifiers are
assigned. Suite B uses these algorithms:
Security Level 1 Security Level 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
For S/MIME-encrypted messages, Suite B follows the direction set by
RFC 3278 [CMSECC] and follows the conventions set by RFC 3565
[CMSAES]. Again, additional algorithm identifiers are assigned.
Suite B uses these algorithms:
Security Level 1 Security Level 2
---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC
2. SHA-256 and SHA-256 Message Digest Algorithms
This section specifies the conventions employed by implementations
that support SHA-256 or SHA-384 [SHA2]. In Suite B, Security Level
1, the SHA-256 message digest algorithm MUST be used. In Suite B,
Security Level 2, SHA-384 MUST be used.
Within the CMS signed-data content type, message digest algorithm
identifiers are located in the SignedData digestAlgorithms field and
the SignerInfo digestAlgorithm field. Also, message digest values
are located in the Message Digest authenticated attribute. In
addition, message digest values are input into signature algorithms.
The SHA-256 and SHA-384 message digest algorithms are defined in FIPS
Pub 180-2 [SHA2, EH]. The algorithm identifier for SHA-256 is:
Housley & Solinas Informational [Page 2]
RFC 5008 Suite B in S/MIME September 2007
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
The algorithm identifier for SHA-384 is:
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
There are two possible encodings for the AlgorithmIdentifier
parameters field. The two alternatives arise from the fact that when
the 1988 syntax for AlgorithmIdentifier was translated into the 1997
syntax, the OPTIONAL associated with the AlgorithmIdentifier
parameters got lost. Later, the OPTIONAL was recovered via a defect
report, but by then many people thought that algorithm parameters
were mandatory. Because of this history some implementations encode
parameters as a NULL element and others omit them entirely. The
correct encoding for the SHA-256 and SHA-384 message digest
algorithms is to omit the parameters field; however, to ensure
compatibility, implementations ought to also handle a SHA-256 and
SHA-384 AlgorithmIdentifier parameters field, which contains a NULL.
For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters
field is OPTIONAL, and if present, the parameters field MUST contain
a NULL. Implementations MUST accept SHA-256 and SHA-384
AlgorithmIdentifiers with absent parameters. Implementations MUST
accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters.
Implementations SHOULD generate SHA-256 and SHA-384
AlgorithmIdentifiers with absent parameters.
3. ECDSA Signature Algorithm
This section specifies the conventions employed by implementations
that support Elliptic Curve Digital Signature Algorithm (ECDSA). The
direction set by RFC 3278 [CMSECC] is followed, but additional
message digest algorithms and additional elliptic curves are
employed. In Suite B, Security Level 1, ECDSA MUST be used with the
SHA-256 message digest algorithm and the P-256 elliptic curve. In
Suite B, Security Level 2, ECDSA MUST be used with the SHA-384
message digest algorithm and the P-384 elliptic curve. The P-256 and
P-384 elliptic curves are specified in [DSS].
Within the CMS signed-data content type, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field of
SignedData. In addition, signature algorithm identifiers are located
in the SignerInfo signatureAlgorithm field of countersignature
attributes.
Housley & Solinas Informational [Page 3]
RFC 5008 Suite B in S/MIME September 2007
Within the CMS signed-data content type, signature values are located
in the SignerInfo signature field of SignedData. In addition,
signature values are located in the SignerInfo signature field of
countersignature attributes.
As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve
Diffie-Hellman (ECDH) use the same algorithm identifier for subject
public keys in certificates, and it is repeated here:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) keyType(2) 1 }
This object identifier is used in public key certificates for both
ECDSA signature keys and ECDH encryption keys. The intended
application for the key may be indicated in the key usage field (see
RFC 3280 [PKIX1]). The use of separate keys for signature and
encryption purposes is RECOMMENDED; however, the use of a single key
for both signature and encryption purposes is not forbidden.
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same
encoding for subject public keys in certificates, and it is repeated
here:
ECPoint ::= OCTET STRING
The elliptic curve public key (an OCTET STRING) is mapped to a
subject public key (a BIT STRING) as follows: the most significant
bit of the OCTET STRING becomes the most significant bit of the BIT
STRING, and the least significant bit of the OCTET STRING becomes the
least significant bit of the BIT STRING. Note that this octet string
may represent an elliptic curve point in compressed or uncompressed
form. Implementations that support elliptic curves according to this
specification MUST support the uncompressed form and MAY support the
compressed form.
ECDSA and ECDH require use of certain parameters with the public key.
The parameters may be inherited from the certificate issuer,
implicitly included through reference to a named curve, or explicitly
included in the certificate. As specified in RFC 3279 [PKIX1ALG],
the parameter structure is:
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
Housley & Solinas Informational [Page 4]
RFC 5008 Suite B in S/MIME September 2007
In Suite B, the namedCurve CHOICE MUST be used. The object
identifier for P-256 is:
ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) curves(3) prime(1) 7 }
The object identifier for P-384 is:
secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 }
The algorithm identifier used in CMS for ECDSA with SHA-256 signature
values is:
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
The algorithm identifier used in CMS for ECDSA with SHA-384 signature
values is:
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm
identifier is used, the AlgorithmIdentifier parameters field MUST be
absent.
When signing, the ECDSA algorithm generates two values, commonly
called r and s. To transfer these two values as one signature, they
MUST be encoded using the Ecdsa-Sig-Value type specified in RFC 3279
[PKIX1ALG]:
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
4. Key Management
CMS accommodates the following general key management techniques: key
agreement, key transport, previously distributed symmetric key-
encryption keys, and passwords. In Suite B, ephemeral-static key
agreement MUST be used as described in Section 4.1.
When a key agreement algorithm is used, a key-encryption algorithm is
also needed. In Suite B, the Advanced Encryption Standard (AES) Key
Wrap, as specified in RFC 3394 [AESWRAP, SH], MUST be used as the
key-encryption algorithm. AES Key Wrap is discussed further in
Section 4.2. The key-encryption key used with the AES Key Wrap
Housley & Solinas Informational [Page 5]
RFC 5008 Suite B in S/MIME September 2007
algorithm is obtained from a key derivation function (KDF). In Suite
B, there are two KDFs, one based on SHA-256 and one based on SHA-384.
These KDFs are discussed further in Section 4.3.
4.1. ECDH Key Agreement Algorithm
This section specifies the conventions employed by implementations
that support ECDH. The direction set by RFC 3278 [CMSECC] is
followed, but additional key derivation functions and key wrap
algorithms are employed. S/MIME is used in store-and-forward
communications, which means that ephemeral-static ECDH is always
employed. This means that the message originator uses an ephemeral
ECDH key and that the message recipient uses a static ECDH key, which
is obtained from an X.509 certificate. In Suite B, Security Level 1,
ephemeral-static ECDH MUST be used with the SHA-256 KDF, AES-128 Key
Wrap, and the P-256 elliptic curve. In Suite B, Security Level 2,
ephemeral-static ECDH MUST be used with the SHA-384 KDF, AES-256 Key
Wrap, and the P-384 elliptic curve.
Within the CMS enveloped-data content type, key agreement algorithm
identifiers are located in the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same
conventions for carrying a subject public key in a certificate.
These conventions are discussed in Section 3.
Ephemeral-static ECDH key agreement is defined in [SEC1] and
[IEEE1363]. When using ephemeral-static ECDH, the EnvelopedData
RecipientInfos keyAgreeRecipientInfo field is used as follows:
version MUST be 3.
originator MUST be the originatorKey alternative. The
originatorKey algorithm field MUST contain the id-ecPublicKey
object identifier (see Section 3) with NULL parameters. The
originatorKey publicKey field MUST contain the message
originator's ephemeral public key, which is a DER-encoded ECPoint
(see Section 3). The ECPoint SHOULD be represented in
uncompressed form.
ukm can be present or absent. However, message originators SHOULD
include the ukm. As specified in RFC 3852 [CMS], implementations
MUST support ukm message recipient processing, so interoperability
is not a concern if the ukm is present or absent. When present,
the ukm is used to ensure that a different key-encryption key is
generated, even when the ephemeral private key is improperly used
Housley & Solinas Informational [Page 6]
RFC 5008 Suite B in S/MIME September 2007
more than once. See [RANDOM] for guidance on generation of random
values.
keyEncryptionAlgorithm MUST be one of the two algorithm
identifiers listed below, and the algorithm identifier parameter
field MUST be present and identify the key wrap algorithm. The
key wrap algorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key-
encryption key generated using the ephemeral-static ECDH key
agreement algorithm (see Section 4.3). In Suite B, Security Level
1, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-
sha256kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be
a KeyWrapAlgorithm containing id-aes128-wrap (see Section 4.2).
In Suite B, Security Level 2, the keyEncryptionAlgorithm MUST be
dhSinglePass-stdDH-sha384kdf-scheme, and the
keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm
containing id-aes256-wrap (see Section 4.2). The algorithm
identifier for dhSinglePass-stdDH-sha256kdf-scheme and
dhSinglePass-stdDH-sha384kdf-scheme are:
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
Both of these algorithm identifiers use KeyWrapAlgorithm as the
type for their parameter:
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static ECDH public key.
RecipientEncryptedKey EncryptedKey MUST contain the content-
encryption key encrypted with the ephemeral-static, ECDH-generated
pairwise key-encryption key using the algorithm specified by the
KeyWrapAlgorithm (see Section 4.3).
Housley & Solinas Informational [Page 7]
RFC 5008 Suite B in S/MIME September 2007
4.2. AES Key Wrap
CMS offers support for symmetric key-encryption key management;
however, it is not used in Suite B. Rather, the AES Key Wrap key-
encryption algorithm, as specified in RFC 3394 [AESWRAP, SH], is used
to encrypt the content-encryption key with a pairwise key-encryption
key that is generated using ephemeral-static ECDH. In Suite B,
Security Level 1, AES-128 Key Wrap MUST be used as the key-encryption
algorithm. In Suite B, Security Level 2, AES-256 Key Wrap MUST be
used as the key-encryption algorithm.
Within the CMS enveloped-data content type, wrapped content-
encryption keys are located in the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, and
key wrap algorithm identifiers are located in the KeyWrapAlgorithm
parameters within the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
The algorithm identifiers for AES Key Wrap are specified in RFC 3394
[SH], and the ones needed for Suite B are repeated here:
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 }
4.3. Key Derivation Functions
CMS offers support for deriving symmetric key-encryption keys from
passwords; however, password-based key management is not used in
Suite B. Rather, KDFs based on SHA-256 and SHA-384 are used to
derive a pairwise key-encryption key from the shared secret produced
by ephemeral-static ECDH. In Suite B, Security Level 1, the KDF
based on SHA-256 MUST be used. In Suite B, Security Level 2, KDF
based on SHA-384 MUST be used.
As specified in Section 8.2 of RFC 3278 [CMSECC], using ECDH with the
CMS enveloped-data content type, the derivation of key-encryption
keys makes use of the ECC-CMS-SharedInfo type, which is repeated
here:
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
Housley & Solinas Informational [Page 8]
RFC 5008 Suite B in S/MIME September 2007
In Suite B, the fields of ECC-CMS-SharedInfo are used as follows:
keyInfo contains the object identifier of the key-encryption
algorithm that will be used to wrap the content-encryption key and
NULL parameters. In Suite B, Security Level 1, AES-128 Key Wrap
MUST be used, resulting in {id-aes128-wrap, NULL}. In Suite B,
Security Level 2, AES-256 Key Wrap MUST be used, resulting in
{id-aes256-wrap, NULL}.
entityUInfo optionally contains a random value provided by the
message originator. If the ukm is present, then the entityUInfo
MUST be present, and it MUST contain the ukm value. If the ukm is
not present, then the entityUInfo MUST be absent.
suppPubInfo contains the length of the generated key-encryption
key, in bits, represented as a 32-bit unsigned number, as
described in RFC 2631 [CMSDH]. In Suite B, Security Level 1, a
128-bit AES key MUST be used, resulting in 0x00000080. In Suite
B, Security Level 2, a 256-bit AES key MUST be used, resulting in
0x00000100.
ECC-CMS-SharedInfo is DER-encoded and used as input to the key
derivation function, as specified in Section 3.6.1 of [SEC1]. Note
that ECC-CMS-SharedInfo differs from the OtherInfo specified in
[CMSDH]. Here, a counter value is not included in the keyInfo field
because the KDF specified in [SEC1] ensures that sufficient keying
data is provided.
The KDF specified in [SEC1] provides an algorithm for generating an
essentially arbitrary amount of keying material from the shared
secret produced by ephemeral-static ECDH, which is called Z for the
remainder of this discussion. The KDF can be summarized as:
KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
To generate a key-encryption key, one or more KM blocks are
generated, incrementing Counter appropriately, until enough material
has been generated. The KM blocks are concatenated left to right:
KEK = KM ( counter=1 ) || KM ( counter=2 ) ...
The elements of the KDF are used as follows:
Hash is the one-way hash function, and it is either SHA-256 or
SHA-384 [SHA2]. In Suite B, Security Level 1, the SHA-256 MUST be
used. In Suite B, Security Level 2, SHA-384 MUST be used.
Housley & Solinas Informational [Page 9]
RFC 5008 Suite B in S/MIME September 2007
Z is the shared secret value generated by ephemeral-static ECDH.
Leading zero bits MUST be preserved. In Suite B, Security Level
1, Z MUST be exactly 256 bits. In Suite B, Security Level 2, Z
MUST be exactly 384 bits.
Counter is a 32-bit unsigned number, represented in network byte
order. Its initial value MUST be 0x00000001 for any key
derivation operation. In Suite B, Security Level 1 and Security
Level 2, exactly one iteration is needed; the Counter is not
incremented.
ECC-CMS-SharedInfo is composed as described above. It MUST be DER
encoded.
To generate a key-encryption key, one KM block is generated, with a
Counter value of 0x00000001:
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
In Suite B, Security Level 1, the key-encryption key MUST be the most
significant 128 bits of the SHA-256 output value. In Suite B,
Security Level 2, the key-encryption key MUST be the most significant
256 bits of the SHA-384 output value.
Note that the only source of secret entropy in this computation is Z.
The effective key space of the key-encryption key is limited by the
size of Z, in addition to any security level considerations imposed
by the elliptic curve that is used. However, if entityUInfo is
different for each message, a different key-encryption key will be
generated for each message.
5. AES CBC Content Encryption
This section specifies the conventions employed by implementations
that support content encryption using AES [AES] in Cipher Block
Chaining (CBC) mode [MODES]. The conventions in RFC 3565 [CMSAES]
are followed. In Suite B, Security Level 1, the AES-128 in CBC mode
MUST be used for content encryption. In Suite B, Security Level 2,
AES-256 in CBC mode MUST be used.
Within the CMS enveloped-data content type, content encryption
algorithm identifiers are located in the EnvelopedData
EncryptedContentInfo contentEncryptionAlgorithm field. The content
encryption algorithm is used to encipher the content located in the
EnvelopedData EncryptedContentInfo encryptedContent field.
The AES CBC content-encryption algorithm is described in [AES] and
[MODES]. The algorithm identifier for AES-128 in CBC mode is:
Housley & Solinas Informational [Page 10]
RFC 5008 Suite B in S/MIME September 2007
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 }
The algorithm identifier for AES-256 in CBC mode is:
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 42 }
The AlgorithmIdentifier parameters field MUST be present, and the
parameters field must contain AES-IV:
AES-IV ::= OCTET STRING (SIZE(16))
The 16-octet initialization vector is generated at random by the
originator. See [RANDOM] for guidance on generation of random
values.
6. Security Considerations
This document specifies the conventions for using the NSA's Suite B
algorithms in S/MIME. All of the algorithms have been specified in
previous documents, although a few new algorithm identifiers have
been assigned.
Two levels of security may be achieved using this specification.
Users must consider their risk environment to determine which level
is appropriate for their own use.
For signed and encrypted messages, Suite B provides a consistent
level of security for confidentiality and integrity of the message
content.
The security considerations in RFC 3852 [CMS] discuss the CMS as a
method for digitally signing data and encrypting data.
The security considerations in RFC 3370 [CMSALG] discuss
cryptographic algorithm implementation concerns in the context of the
CMS.
The security considerations in RFC 3278 [CMSECC] discuss the use of
elliptic curve cryptography (ECC) in the CMS.
The security considerations in RFC 3565 [CMSAES] discuss the use of
AES in the CMS.
Housley & Solinas Informational [Page 11]
RFC 5008 Suite B in S/MIME September 2007
7. References
7.1. Normative References
[AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AESWRAP] National Institute of Standards and Technology, "AES Key
Wrap Specification", 17 November 2001. [See
http://csrc.nist.gov/encryption/kms/key-wrap.pdf]
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-2, January 2000.
[ECDSA] American National Standards Institute, "Public Key
Cryptography For The Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI
X9.62-1998, 1999.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS)", RFC 3565, July 2003.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
Elliptic Curve Cryptography (ECC) Algorithms in
Cryptographic Message Syntax (CMS)", RFC 3278, April
2002.
[IEEE1363] Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography",
IEEE Std 1363, 2000.
[MODES] National Institute of Standards and Technology, "DES
Modes of Operation", FIPS Pub 81, 2 December 1980.
[MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
Housley & Solinas Informational [Page 12]
RFC 5008 Suite B in S/MIME September 2007
[PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[PKIX1ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", 2000. [See http://www.secg.org/
collateral/sec1.pdf.]
[SH] Schaad, J., and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[SHA2] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, 1 August 2002.
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
[X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988.
7.2. Informative References
[EH] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[SuiteB] National Security Agency, "Fact Sheet NSA Suite B
Cryptography", July 2005. [See http://www.nsa.gov/ia/
industry/crypto_Suite_b.cfm?MenuID=10.2.7)
Housley & Solinas Informational [Page 13]
RFC 5008 Suite B in S/MIME September 2007
Authors' Addresses
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Jerome A. Solinas
National Information Assurance Laboratory
National Security Agency
9800 Savage Road
Fort George G. Meade, MD 20755
USA
EMail: jasolin@orion.ncsc.mil
Housley & Solinas Informational [Page 14]
RFC 5008 Suite B in S/MIME September 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Housley & Solinas Informational [Page 15]
Suite B Profile for Transport Layer Security (TLS)
Network Working Group M. Salter
Request for Comments: 5430 National Security Agency
Category: Informational E. Rescorla
Network Resonance
R. Housley
Vigil Security
March 2009
Suite B Profile for Transport Layer Security (TLS)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Salter, et al. Informational [Page 1]
RFC 5430 Suite B for TLS March 2009
Abstract
The United States government has published guidelines for "NSA Suite
B Cryptography", which defines cryptographic algorithm policy for
national security applications. This document defines a profile of
Transport Layer Security (TLS) version 1.2 that is fully conformant
with Suite B. This document also defines a transitional profile for
use with TLS version 1.0 and TLS version 1.1 which employs Suite B
algorithms to the greatest extent possible.
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Suite B Requirements ............................................3
4. Suite B Compliance and Interoperability Requirements ............4
4.1. Security Levels ............................................7
4.2. Acceptable Curves ..........................................8
4.3. Certificates ...............................................8
4.4. signature_algorithms Extension .............................9
4.5. CertificateRequest Message .................................9
4.6. CertificateVerify Message .................................10
4.7. ServerKeyExchange Message Signature .......................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
1. Introduction
The United States government has posted the Fact Sheet on National
Security Agency (NSA) Suite B Cryptography [NSA], and at the time of
writing, it states:
To complement the existing policy for the use of the Advanced
Encryption Standard (AES) to protect national security systems
and information as specified in The National Policy on the use of
the Advanced Encryption Standard (AES) to Protect National
Security Systems and National Security Information (CNSSP-15),
the National Security Agency (NSA) announced Suite B Cryptography
at the 2005 RSA Conference. In addition to the AES, Suite B
includes cryptographic algorithms for hashing, digital
signatures, and key exchange.
Suite B only specifies the cryptographic algorithms to be
used. Many other factors need to be addressed in determining
whether a particular device implementing a particular set of
Salter, et al. Informational [Page 2]
RFC 5430 Suite B for TLS March 2009
cryptographic algorithms should be used to satisfy a particular
requirement.
Among those factors are "requirements for interoperability both
domestically and internationally".
This document does not define any new cipher suites; instead, it
defines two profiles:
o A Suite B compliant profile for use with TLS version 1.2 [RFC5246]
and the cipher suites defined in [RFC5289]. This profile uses
only Suite B algorithms.
o A transitional profile for use with TLS version 1.0 [RFC2246] or
TLS version 1.1 [RFC4346] and the cipher suites defined in
[RFC4492]. This profile uses the Suite B cryptographic algorithms
to the greatest extent possible and provides backward
compatibility. While the transitional profile is not Suite B
compliant, it provides a transition path towards the Suite B
compliant profile.
2. Conventions Used in This Document
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].
3. Suite B Requirements
The Fact Sheet on Suite B Cryptography requires that key
establishment and authentication algorithms be based on Elliptic
Curve Cryptography, and that the encryption algorithm be AES [AES].
Suite B defines two security levels, of 128 and 192 bits.
In particular, Suite B includes:
Encryption: Advanced Encryption Standard (AES) [AES] --
FIPS 197 (with key sizes of 128 and 256 bits)
Digital Signature: Elliptic Curve Digital Signature Algorithm
(ECDSA) [DSS] - FIPS 186-2 (using the
curves with 256- and 384-bit prime moduli)
Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) - NIST
Special Publication 800-56A [PWKE] (using the
curves with 256- and 384-bit prime moduli)
Salter, et al. Informational [Page 3]
RFC 5430 Suite B for TLS March 2009
The 128-bit security level corresponds to an elliptic curve size of
256 bits and AES-128; it also makes use of SHA-256 [SHS]. The 192-
bit security level corresponds to an elliptic curve size of 384 bits
and AES-256; it also makes use of SHA-384 [SHS].
Note: Some people refer to the two security levels based on the AES
key size that is employed instead of the overall security provided by
the combination of Suite B algorithms. At the 128-bit security
level, an AES key size of 128 bits is used, which does not lead to
any confusion. However, at the 192-bit security level, an AES key
size of 256 bits is used, which sometimes leads to an expectation of
more security than is offered by the combination of Suite B
algorithms.
To accommodate backward compatibility, a Suite B compliant client or
server can be configured to accept a cipher suite that is not part of
Suite B. However, whenever a Suite B compliant client and a Suite B
compliant server establish a TLS version 1.2 session, only Suite B
algorithms are employed.
4. Suite B Compliance and Interoperability Requirements
TLS version 1.1 [RFC4346] and earlier do not support Galois Counter
Mode (GCM) cipher suites [RFC5289]. However, TLS version 1.2
[RFC5246] and later do support GCM. For Suite B TLS compliance, GCM
cipher suites are REQUIRED to be used whenever both the client and
the server support the necessary cipher suites. Also, for Suite B
TLS compliance, Cipher Block Chaining (CBC) cipher suites are
employed when GCM cipher suites cannot be employed.
For a client to implement the Suite B compliant profile, it MUST
implement TLS version 1.2 or later, and the following cipher suite
rules apply:
o A Suite B compliant TLS version 1.2 or later client MUST offer at
least two cipher suites for each supported security level. For
the 128-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 MUST be offered in this
order in the ClientHello message. For the 192-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 MUST be offered in this
order in the ClientHello message. One of these cipher suites MUST
be the first (most preferred) cipher suite in the ClientHello
message.
Salter, et al. Informational [Page 4]
RFC 5430 Suite B for TLS March 2009
o A Suite B compliant TLS version 1.2 or later client that offers
backward compatibility with TLS version 1.1 or earlier servers MAY
offer an additional cipher suite for each supported security
level. If these cipher suites are offered, they MUST appear after
the ones discussed above. For the 128-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MAY be offered in the
ClientHello message. For the 192-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MAY be offered in the
ClientHello message.
o A Suite B compliant TLS version 1.2 or later client that offers
interoperability with non-Suite B compliant servers MAY offer
additional cipher suites. If any additional cipher suites are
offered, they MUST appear after the ones discussed above in the
ClientHello message.
For a client to implement the Suite B transitional profile, it MUST
implement TLS version 1.1 or earlier and the following cipher suite
rules apply:
o A Suite B transitional TLS version 1.1 or earlier client MUST
offer the cipher suite for the 128-bit security level, the cipher
suite for the 192-bit security level, or both. For the 128-bit
security level, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MUST be
offered in the ClientHello message. For the 192-bit security
level, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MUST be offered in the
ClientHello message. One of these cipher suites MUST be the first
(most preferred) cipher suite in the ClientHello message.
o A Suite B transitional TLS version 1.1 or earlier client that
offers interoperability with non-Suite B compliant servers MAY
offer additional cipher suites. If any additional cipher suites
are offered, they MUST appear after the ones discussed above in
the ClientHello message.
A Suite B compliant TLS server MUST be configured to support the 128-
bit security level, the 192-bit security level, or both security
levels. The cipher suite rules for each of these security levels is
described below. If a Suite B compliant TLS server is configured to
support both security levels, then the configuration MUST prefer one
security level over the other. In practice, this means that the
cipher suite rules associated with the cipher suites listed in
Section 4.1 for the preferred security level are processed before the
cipher suite rules for the less preferred security level.
Salter, et al. Informational [Page 5]
RFC 5430 Suite B for TLS March 2009
For a server to implement the Suite B conformant profile at the 128-
bit security level, the following cipher suite rules apply:
o A Suite B compliant TLS version 1.2 or later server MUST accept
the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite if it is
offered.
o If the preceding cipher suite is not offered, then a Suite B
compliant TLS version 1.2 or later server MUST accept the
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite if it is
offered.
o If neither of the preceding two cipher suites is offered, then a
Suite B compliant TLS version 1.2 or later server that offers
backward compatibility with TLS version 1.1 or earlier clients MAY
accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it
is offered.
o If the server is not offered any of the preceding three cipher
suites and interoperability with clients that are not compliant or
interoperable with Suite B is desired, then the server MAY accept
another offered cipher suite that is considered acceptable by the
server administrator.
For a server to implement the Suite B transitional profile at the
128-bit security level, the following cipher suite rules apply:
o A Suite B transitional TLS version 1.1 or earlier server MUST
accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it
is offered.
o If the server is not offered the preceding cipher suite and
interoperability with clients that are not Suite B transitional is
desired, then the server MAY accept another offered cipher suite
that is considered acceptable by the server administrator.
For a server to implement the Suite B conformant profile at the 192-
bit security level, the following cipher suite rules apply:
o A Suite B compliant TLS version 1.2 or later server MUST accept
the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite if it is
offered.
o If the preceding cipher suite is not offered, then a Suite B
compliant TLS version 1.2 or later server MUST accept the
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher suite if it is
offered.
Salter, et al. Informational [Page 6]
RFC 5430 Suite B for TLS March 2009
o If neither of the preceding two cipher suites is offered, then a
Suite B compliant TLS version 1.2 or later server that offers
backward compatibility with TLS version 1.1 or earlier clients MAY
accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it
is offered.
o If the server is not offered any of the preceding three cipher
suites and interoperability with clients that are not compliant or
interoperable with Suite B is desired, then the server MAY accept
another offered cipher suite that is considered acceptable by the
server administrator.
For a server to implement the Suite B transitional profile at the
192-bit security level, the following cipher suite rules apply:
o A Suite B transitional TLS version 1.1 or earlier server MUST
accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it
is offered.
o If the server is not offered the preceding cipher suite and
interoperability with clients that are not Suite B transitional is
desired, then the server MAY accept another offered cipher suite
that is considered acceptable by the server administrator.
Note that these rules explicitly permit the use of CBC cipher suites
in TLS version 1.2 connections in order to permit operation between
Suite B compliant and non-Suite B compliant implementations. For
instance, a Suite B compliant TLS version 1.2 client might offer TLS
version 1.2 with both GCM and CBC cipher suites when communicating
with a non-Suite B TLS version 1.2 server, which then selected the
CBC cipher suites. This connection would nevertheless meet the
requirements of this specification. However, any two Suite B
compliant implementations will negotiate a GCM cipher suite when
doing TLS version 1.2.
4.1. Security Levels
As described in Section 1, Suite B specifies two security levels:
128-bit and 192-bit. The following table lists the cipher suites for
each security level. Within each security level, the cipher suites
are listed in their preferred order for selection by a TLS version
1.2 implementation.
Salter, et al. Informational [Page 7]
RFC 5430 Suite B for TLS March 2009
+-----------------------------------------+----------------+
| Cipher Suite | Security Level |
+-----------------------------------------+----------------+
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128 |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | 128 |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | 128 |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192 |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | 192 |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | 192 |
+-----------------------------------------+----------------+
4.2. Acceptable Curves
RFC 4492 defines a variety of elliptic curves. For cipher suites
defined in this specification, only secp256r1(23) or secp384r1(24)
may be used. These are the same curves that appear in FIPS 186-2
[DSS] as P-256 and P-384, respectively. For cipher suites at the
128-bit security level, secp256r1 MUST be used. For cipher suites at
the 192-bit security level, secp384r1 MUST be used. RFC 4492
requires that the uncompressed(0) form be supported. The
ansiX962_compressed_prime(1) point formats MAY also be supported.
Clients desiring to negotiate only a Suite B compliant connection
MUST generate a "Supported Elliptic Curves Extension" containing only
the allowed curves. These curves MUST match the cipher suite
security levels being offered. Clients that are willing to do both
Suite B compliant and non-Suite B compliant connections MAY omit the
extension or send the extension but offer other curves as well as the
appropriate Suite B ones.
Servers desiring to negotiate a Suite B compliant connection SHOULD
check for the presence of the extension, but MUST NOT negotiate
inappropriate curves even if they are offered by the client. This
allows a client that is willing to do either Suite B compliant or
non-Suite B compliant modes to interoperate with a server that will
only do Suite B compliant modes. If the client does not advertise an
acceptable curve, the server MUST generate a fatal
"handshake_failure" alert and terminate the connection. Clients MUST
check the chosen curve to make sure it is acceptable.
4.3. Certificates
Server and client certificates used to establish a Suite B compliant
connection MUST be signed with ECDSA. Digital signatures MUST be
calculated using either the P-256 curve along with the SHA-256 hash
algorithm or calculated using the P-384 curve along with the SHA-384
hash algorithm. For certificates used at the 128-bit security level,
the subject public key MUST use the P-256 curve and be signed with
Salter, et al. Informational [Page 8]
RFC 5430 Suite B for TLS March 2009
either the P-384 curve or the P-256 curve. For certificates used at
the 192-bit security level, the subject public key MUST use the P-384
curve and be signed with the P-384 curve.
In TLS version 1.0 and TLS version 1.1, the key exchange algorithm
used in the TLS_ECDHE_ECDSA-collection of cipher suites requires the
server's certificate to be signed with a particular signature scheme.
TLS version 1.2 offers more flexibility. This specification does not
impose any additional restrictions on the server certificate
signature or the signature schemes used elsewhere in the
certification path. (Often such restrictions will be useful, and it
is expected that this will be taken into account in practices of
certification authorities. However, such restrictions are not
strictly required, even if it is beyond the capabilities of a client
to completely validate a given certification path, the client may be
able to validate the server's certificate by relying on a trusted
certification authority whose certificate appears as one of the
intermediate certificates in the certification path.)
Likewise, this specification does not impose restrictions on
signature schemes used in the certification path for the client's
certificate when mutual authentication is employed.
4.4. signature_algorithms Extension
The signature_algorithms extension is defined in Section 7.4.1.4.1 of
TLS version 1.2 [RFC5246]. A Suite B compliant TLS version 1.2 or
later client MUST include the signature_algorithms extension. For
the 128-bit security level, SHA-256 with ECDSA MUST be offered in the
signature_algorithms extension. For the 192-bit security level, SHA-
384 with ECDSA MUST be offered in the signature_algorithms extension.
Other offerings MAY be included to indicate the signature algorithms
that are acceptable in cipher suites that are offered for
interoperability with servers that are not compliant with Suite B and
to indicate the signature algorithms that are acceptable for
certification path validation.
4.5. CertificateRequest Message
A Suite B compliant TLS version 1.2 or later server MUST include SHA-
256 with ECDSA and/or SHA-384 with ECDSA in the
supported_signature_algorithms field of the CertificateRequest
message. For the 128-bit security level, SHA-256 with ECDSA MUST
appear in the supported_signature_algorithms field. For the 192-bit
security level, SHA-384 with ECDSA MUST appear in the
supported_signature_algorithms field.
Salter, et al. Informational [Page 9]
RFC 5430 Suite B for TLS March 2009
4.6. CertificateVerify Message
A Suite B compliant TLS version 1.2 or later client MUST use SHA-256
with ECDSA or SHA-384 with ECDSA for the signature in the
CertificateVerify message. For the 128-bit security level, SHA-256
with ECDSA MUST be used. For the 192-bit security level, SHA-384
with ECDSA MUST be used.
4.7. ServerKeyExchange Message Signature
In the TLS_ECDHE_ECDSA-collection of cipher suites, the server sends
its ephemeral ECDH public key and a specification of the
corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's certificate.
A TLS version 1.1 or earlier server MUST sign the ServerKeyExchange
message using SHA-1 with ECDSA.
A Suite B compliant TLS version 1.2 or later server MUST sign the
ServerKeyExchange message using either SHA-256 with ECDSA or SHA-384
with ECDSA. For the 128-bit security level, SHA-256 with ECDSA MUST
be used. For the 192-bit security level, SHA-384 with ECDSA MUST be
used.
5. Security Considerations
Most of the security considerations for this document are described
in "The Transport Layer Security (TLS) Protocol Version 1.2"
[RFC5246], "Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS)" [RFC4492], "AES Galois Counter Mode
(GCM) Cipher Suites for TLS" [RFC5288], and "TLS Elliptic Curve
Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)"
[RFC5289]. Readers should consult those documents.
In order to meet the goal of a consistent security level for the
entire cipher suite, in Suite B mode TLS implementations MUST ONLY
use the curves defined in Section 4.2. Otherwise, it is possible to
have a set of symmetric algorithms with much weaker or stronger
security properties than the asymmetric (ECC) algorithms.
6. Acknowledgements
Thanks to Pasi Eronen, Steve Hanna, and Paul Hoffman for their
review, comments, and insightful suggestions.
This work was supported by the US Department of Defense.
Salter, et al. Informational [Page 10]
RFC 5430 Suite B for TLS March 2009
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
August 2008.
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard", FIPS 186-2, January 2000.
[PWKE] National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography (Revised)", NIST
Special Publication 800-56A, March 2007.
[SHS] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, August 2002.
7.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008.
[NSA] National Security Agency, "Fact Sheet NSA Suite B
Cryptography",
.
Salter, et al. Informational [Page 11]
RFC 5430 Suite B for TLS March 2009
Authors' Addresses
Margaret Salter
National Security Agency
9800 Savage Rd.
Fort Meade 20755-6709
USA
EMail: msalter@restarea.ncsc.mil
Eric Rescorla
Network Resonance
2064 Edgewood Drive
Palo Alto 94303
USA
EMail: ekr@rtfm.com
Russ Housley
Vigil Security
918 Spring Knoll Drive
Herndon 21070
USA
EMail: housley@vigilsec.com
Salter, et al. Informational [Page 12]
Request for Comments: 5430 National Security Agency
Category: Informational E. Rescorla
Network Resonance
R. Housley
Vigil Security
March 2009
Suite B Profile for Transport Layer Security (TLS)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Salter, et al. Informational [Page 1]
RFC 5430 Suite B for TLS March 2009
Abstract
The United States government has published guidelines for "NSA Suite
B Cryptography", which defines cryptographic algorithm policy for
national security applications. This document defines a profile of
Transport Layer Security (TLS) version 1.2 that is fully conformant
with Suite B. This document also defines a transitional profile for
use with TLS version 1.0 and TLS version 1.1 which employs Suite B
algorithms to the greatest extent possible.
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Suite B Requirements ............................................3
4. Suite B Compliance and Interoperability Requirements ............4
4.1. Security Levels ............................................7
4.2. Acceptable Curves ..........................................8
4.3. Certificates ...............................................8
4.4. signature_algorithms Extension .............................9
4.5. CertificateRequest Message .................................9
4.6. CertificateVerify Message .................................10
4.7. ServerKeyExchange Message Signature .......................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
1. Introduction
The United States government has posted the Fact Sheet on National
Security Agency (NSA) Suite B Cryptography [NSA], and at the time of
writing, it states:
To complement the existing policy for the use of the Advanced
Encryption Standard (AES) to protect national security systems
and information as specified in The National Policy on the use of
the Advanced Encryption Standard (AES) to Protect National
Security Systems and National Security Information (CNSSP-15),
the National Security Agency (NSA) announced Suite B Cryptography
at the 2005 RSA Conference. In addition to the AES, Suite B
includes cryptographic algorithms for hashing, digital
signatures, and key exchange.
Suite B only specifies the cryptographic algorithms to be
used. Many other factors need to be addressed in determining
whether a particular device implementing a particular set of
Salter, et al. Informational [Page 2]
RFC 5430 Suite B for TLS March 2009
cryptographic algorithms should be used to satisfy a particular
requirement.
Among those factors are "requirements for interoperability both
domestically and internationally".
This document does not define any new cipher suites; instead, it
defines two profiles:
o A Suite B compliant profile for use with TLS version 1.2 [RFC5246]
and the cipher suites defined in [RFC5289]. This profile uses
only Suite B algorithms.
o A transitional profile for use with TLS version 1.0 [RFC2246] or
TLS version 1.1 [RFC4346] and the cipher suites defined in
[RFC4492]. This profile uses the Suite B cryptographic algorithms
to the greatest extent possible and provides backward
compatibility. While the transitional profile is not Suite B
compliant, it provides a transition path towards the Suite B
compliant profile.
2. Conventions Used in This Document
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].
3. Suite B Requirements
The Fact Sheet on Suite B Cryptography requires that key
establishment and authentication algorithms be based on Elliptic
Curve Cryptography, and that the encryption algorithm be AES [AES].
Suite B defines two security levels, of 128 and 192 bits.
In particular, Suite B includes:
Encryption: Advanced Encryption Standard (AES) [AES] --
FIPS 197 (with key sizes of 128 and 256 bits)
Digital Signature: Elliptic Curve Digital Signature Algorithm
(ECDSA) [DSS] - FIPS 186-2 (using the
curves with 256- and 384-bit prime moduli)
Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) - NIST
Special Publication 800-56A [PWKE] (using the
curves with 256- and 384-bit prime moduli)
Salter, et al. Informational [Page 3]
RFC 5430 Suite B for TLS March 2009
The 128-bit security level corresponds to an elliptic curve size of
256 bits and AES-128; it also makes use of SHA-256 [SHS]. The 192-
bit security level corresponds to an elliptic curve size of 384 bits
and AES-256; it also makes use of SHA-384 [SHS].
Note: Some people refer to the two security levels based on the AES
key size that is employed instead of the overall security provided by
the combination of Suite B algorithms. At the 128-bit security
level, an AES key size of 128 bits is used, which does not lead to
any confusion. However, at the 192-bit security level, an AES key
size of 256 bits is used, which sometimes leads to an expectation of
more security than is offered by the combination of Suite B
algorithms.
To accommodate backward compatibility, a Suite B compliant client or
server can be configured to accept a cipher suite that is not part of
Suite B. However, whenever a Suite B compliant client and a Suite B
compliant server establish a TLS version 1.2 session, only Suite B
algorithms are employed.
4. Suite B Compliance and Interoperability Requirements
TLS version 1.1 [RFC4346] and earlier do not support Galois Counter
Mode (GCM) cipher suites [RFC5289]. However, TLS version 1.2
[RFC5246] and later do support GCM. For Suite B TLS compliance, GCM
cipher suites are REQUIRED to be used whenever both the client and
the server support the necessary cipher suites. Also, for Suite B
TLS compliance, Cipher Block Chaining (CBC) cipher suites are
employed when GCM cipher suites cannot be employed.
For a client to implement the Suite B compliant profile, it MUST
implement TLS version 1.2 or later, and the following cipher suite
rules apply:
o A Suite B compliant TLS version 1.2 or later client MUST offer at
least two cipher suites for each supported security level. For
the 128-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 MUST be offered in this
order in the ClientHello message. For the 192-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 MUST be offered in this
order in the ClientHello message. One of these cipher suites MUST
be the first (most preferred) cipher suite in the ClientHello
message.
Salter, et al. Informational [Page 4]
RFC 5430 Suite B for TLS March 2009
o A Suite B compliant TLS version 1.2 or later client that offers
backward compatibility with TLS version 1.1 or earlier servers MAY
offer an additional cipher suite for each supported security
level. If these cipher suites are offered, they MUST appear after
the ones discussed above. For the 128-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MAY be offered in the
ClientHello message. For the 192-bit security level,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MAY be offered in the
ClientHello message.
o A Suite B compliant TLS version 1.2 or later client that offers
interoperability with non-Suite B compliant servers MAY offer
additional cipher suites. If any additional cipher suites are
offered, they MUST appear after the ones discussed above in the
ClientHello message.
For a client to implement the Suite B transitional profile, it MUST
implement TLS version 1.1 or earlier and the following cipher suite
rules apply:
o A Suite B transitional TLS version 1.1 or earlier client MUST
offer the cipher suite for the 128-bit security level, the cipher
suite for the 192-bit security level, or both. For the 128-bit
security level, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MUST be
offered in the ClientHello message. For the 192-bit security
level, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MUST be offered in the
ClientHello message. One of these cipher suites MUST be the first
(most preferred) cipher suite in the ClientHello message.
o A Suite B transitional TLS version 1.1 or earlier client that
offers interoperability with non-Suite B compliant servers MAY
offer additional cipher suites. If any additional cipher suites
are offered, they MUST appear after the ones discussed above in
the ClientHello message.
A Suite B compliant TLS server MUST be configured to support the 128-
bit security level, the 192-bit security level, or both security
levels. The cipher suite rules for each of these security levels is
described below. If a Suite B compliant TLS server is configured to
support both security levels, then the configuration MUST prefer one
security level over the other. In practice, this means that the
cipher suite rules associated with the cipher suites listed in
Section 4.1 for the preferred security level are processed before the
cipher suite rules for the less preferred security level.
Salter, et al. Informational [Page 5]
RFC 5430 Suite B for TLS March 2009
For a server to implement the Suite B conformant profile at the 128-
bit security level, the following cipher suite rules apply:
o A Suite B compliant TLS version 1.2 or later server MUST accept
the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite if it is
offered.
o If the preceding cipher suite is not offered, then a Suite B
compliant TLS version 1.2 or later server MUST accept the
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite if it is
offered.
o If neither of the preceding two cipher suites is offered, then a
Suite B compliant TLS version 1.2 or later server that offers
backward compatibility with TLS version 1.1 or earlier clients MAY
accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it
is offered.
o If the server is not offered any of the preceding three cipher
suites and interoperability with clients that are not compliant or
interoperable with Suite B is desired, then the server MAY accept
another offered cipher suite that is considered acceptable by the
server administrator.
For a server to implement the Suite B transitional profile at the
128-bit security level, the following cipher suite rules apply:
o A Suite B transitional TLS version 1.1 or earlier server MUST
accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it
is offered.
o If the server is not offered the preceding cipher suite and
interoperability with clients that are not Suite B transitional is
desired, then the server MAY accept another offered cipher suite
that is considered acceptable by the server administrator.
For a server to implement the Suite B conformant profile at the 192-
bit security level, the following cipher suite rules apply:
o A Suite B compliant TLS version 1.2 or later server MUST accept
the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite if it is
offered.
o If the preceding cipher suite is not offered, then a Suite B
compliant TLS version 1.2 or later server MUST accept the
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher suite if it is
offered.
Salter, et al. Informational [Page 6]
RFC 5430 Suite B for TLS March 2009
o If neither of the preceding two cipher suites is offered, then a
Suite B compliant TLS version 1.2 or later server that offers
backward compatibility with TLS version 1.1 or earlier clients MAY
accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it
is offered.
o If the server is not offered any of the preceding three cipher
suites and interoperability with clients that are not compliant or
interoperable with Suite B is desired, then the server MAY accept
another offered cipher suite that is considered acceptable by the
server administrator.
For a server to implement the Suite B transitional profile at the
192-bit security level, the following cipher suite rules apply:
o A Suite B transitional TLS version 1.1 or earlier server MUST
accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it
is offered.
o If the server is not offered the preceding cipher suite and
interoperability with clients that are not Suite B transitional is
desired, then the server MAY accept another offered cipher suite
that is considered acceptable by the server administrator.
Note that these rules explicitly permit the use of CBC cipher suites
in TLS version 1.2 connections in order to permit operation between
Suite B compliant and non-Suite B compliant implementations. For
instance, a Suite B compliant TLS version 1.2 client might offer TLS
version 1.2 with both GCM and CBC cipher suites when communicating
with a non-Suite B TLS version 1.2 server, which then selected the
CBC cipher suites. This connection would nevertheless meet the
requirements of this specification. However, any two Suite B
compliant implementations will negotiate a GCM cipher suite when
doing TLS version 1.2.
4.1. Security Levels
As described in Section 1, Suite B specifies two security levels:
128-bit and 192-bit. The following table lists the cipher suites for
each security level. Within each security level, the cipher suites
are listed in their preferred order for selection by a TLS version
1.2 implementation.
Salter, et al. Informational [Page 7]
RFC 5430 Suite B for TLS March 2009
+-----------------------------------------+----------------+
| Cipher Suite | Security Level |
+-----------------------------------------+----------------+
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128 |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | 128 |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | 128 |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192 |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | 192 |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | 192 |
+-----------------------------------------+----------------+
4.2. Acceptable Curves
RFC 4492 defines a variety of elliptic curves. For cipher suites
defined in this specification, only secp256r1(23) or secp384r1(24)
may be used. These are the same curves that appear in FIPS 186-2
[DSS] as P-256 and P-384, respectively. For cipher suites at the
128-bit security level, secp256r1 MUST be used. For cipher suites at
the 192-bit security level, secp384r1 MUST be used. RFC 4492
requires that the uncompressed(0) form be supported. The
ansiX962_compressed_prime(1) point formats MAY also be supported.
Clients desiring to negotiate only a Suite B compliant connection
MUST generate a "Supported Elliptic Curves Extension" containing only
the allowed curves. These curves MUST match the cipher suite
security levels being offered. Clients that are willing to do both
Suite B compliant and non-Suite B compliant connections MAY omit the
extension or send the extension but offer other curves as well as the
appropriate Suite B ones.
Servers desiring to negotiate a Suite B compliant connection SHOULD
check for the presence of the extension, but MUST NOT negotiate
inappropriate curves even if they are offered by the client. This
allows a client that is willing to do either Suite B compliant or
non-Suite B compliant modes to interoperate with a server that will
only do Suite B compliant modes. If the client does not advertise an
acceptable curve, the server MUST generate a fatal
"handshake_failure" alert and terminate the connection. Clients MUST
check the chosen curve to make sure it is acceptable.
4.3. Certificates
Server and client certificates used to establish a Suite B compliant
connection MUST be signed with ECDSA. Digital signatures MUST be
calculated using either the P-256 curve along with the SHA-256 hash
algorithm or calculated using the P-384 curve along with the SHA-384
hash algorithm. For certificates used at the 128-bit security level,
the subject public key MUST use the P-256 curve and be signed with
Salter, et al. Informational [Page 8]
RFC 5430 Suite B for TLS March 2009
either the P-384 curve or the P-256 curve. For certificates used at
the 192-bit security level, the subject public key MUST use the P-384
curve and be signed with the P-384 curve.
In TLS version 1.0 and TLS version 1.1, the key exchange algorithm
used in the TLS_ECDHE_ECDSA-collection of cipher suites requires the
server's certificate to be signed with a particular signature scheme.
TLS version 1.2 offers more flexibility. This specification does not
impose any additional restrictions on the server certificate
signature or the signature schemes used elsewhere in the
certification path. (Often such restrictions will be useful, and it
is expected that this will be taken into account in practices of
certification authorities. However, such restrictions are not
strictly required, even if it is beyond the capabilities of a client
to completely validate a given certification path, the client may be
able to validate the server's certificate by relying on a trusted
certification authority whose certificate appears as one of the
intermediate certificates in the certification path.)
Likewise, this specification does not impose restrictions on
signature schemes used in the certification path for the client's
certificate when mutual authentication is employed.
4.4. signature_algorithms Extension
The signature_algorithms extension is defined in Section 7.4.1.4.1 of
TLS version 1.2 [RFC5246]. A Suite B compliant TLS version 1.2 or
later client MUST include the signature_algorithms extension. For
the 128-bit security level, SHA-256 with ECDSA MUST be offered in the
signature_algorithms extension. For the 192-bit security level, SHA-
384 with ECDSA MUST be offered in the signature_algorithms extension.
Other offerings MAY be included to indicate the signature algorithms
that are acceptable in cipher suites that are offered for
interoperability with servers that are not compliant with Suite B and
to indicate the signature algorithms that are acceptable for
certification path validation.
4.5. CertificateRequest Message
A Suite B compliant TLS version 1.2 or later server MUST include SHA-
256 with ECDSA and/or SHA-384 with ECDSA in the
supported_signature_algorithms field of the CertificateRequest
message. For the 128-bit security level, SHA-256 with ECDSA MUST
appear in the supported_signature_algorithms field. For the 192-bit
security level, SHA-384 with ECDSA MUST appear in the
supported_signature_algorithms field.
Salter, et al. Informational [Page 9]
RFC 5430 Suite B for TLS March 2009
4.6. CertificateVerify Message
A Suite B compliant TLS version 1.2 or later client MUST use SHA-256
with ECDSA or SHA-384 with ECDSA for the signature in the
CertificateVerify message. For the 128-bit security level, SHA-256
with ECDSA MUST be used. For the 192-bit security level, SHA-384
with ECDSA MUST be used.
4.7. ServerKeyExchange Message Signature
In the TLS_ECDHE_ECDSA-collection of cipher suites, the server sends
its ephemeral ECDH public key and a specification of the
corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's certificate.
A TLS version 1.1 or earlier server MUST sign the ServerKeyExchange
message using SHA-1 with ECDSA.
A Suite B compliant TLS version 1.2 or later server MUST sign the
ServerKeyExchange message using either SHA-256 with ECDSA or SHA-384
with ECDSA. For the 128-bit security level, SHA-256 with ECDSA MUST
be used. For the 192-bit security level, SHA-384 with ECDSA MUST be
used.
5. Security Considerations
Most of the security considerations for this document are described
in "The Transport Layer Security (TLS) Protocol Version 1.2"
[RFC5246], "Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS)" [RFC4492], "AES Galois Counter Mode
(GCM) Cipher Suites for TLS" [RFC5288], and "TLS Elliptic Curve
Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)"
[RFC5289]. Readers should consult those documents.
In order to meet the goal of a consistent security level for the
entire cipher suite, in Suite B mode TLS implementations MUST ONLY
use the curves defined in Section 4.2. Otherwise, it is possible to
have a set of symmetric algorithms with much weaker or stronger
security properties than the asymmetric (ECC) algorithms.
6. Acknowledgements
Thanks to Pasi Eronen, Steve Hanna, and Paul Hoffman for their
review, comments, and insightful suggestions.
This work was supported by the US Department of Defense.
Salter, et al. Informational [Page 10]
RFC 5430 Suite B for TLS March 2009
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
August 2008.
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard", FIPS 186-2, January 2000.
[PWKE] National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography (Revised)", NIST
Special Publication 800-56A, March 2007.
[SHS] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, August 2002.
7.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008.
[NSA] National Security Agency, "Fact Sheet NSA Suite B
Cryptography",
Salter, et al. Informational [Page 11]
RFC 5430 Suite B for TLS March 2009
Authors' Addresses
Margaret Salter
National Security Agency
9800 Savage Rd.
Fort Meade 20755-6709
USA
EMail: msalter@restarea.ncsc.mil
Eric Rescorla
Network Resonance
2064 Edgewood Drive
Palo Alto 94303
USA
EMail: ekr@rtfm.com
Russ Housley
Vigil Security
918 Spring Knoll Drive
Herndon 21070
USA
EMail: housley@vigilsec.com
Salter, et al. Informational [Page 12]
Suite B Cryptographic Suites for IPsec
Network Working Group L. Law
Request for Comments: 4869 J. Solinas
Category: Informational NSA
May 2007
Suite B Cryptographic Suites for IPsec
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document proposes four optional cryptographic user interface
suites ("UI suites") for IPsec, similar to the two suites specified
in RFC 4308. The four new suites provide compatibility with the
United States National Security Agency's Suite B specifications.
Table of Contents
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. New UI Suites ...................................................2
3.1. Suite "Suite-B-GCM-128" ....................................2
3.2. Suite "Suite-B-GCM-256" ....................................3
3.3. Suite "Suite-B-GMAC-128" ...................................4
3.4. Suite "Suite-B-GMAC-256" ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
Law & Solinas Informational [Page 1]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
1. Introduction
[RFC4308] proposes two optional cryptographic user interface suites
("UI suites") for IPsec. The two suites, VPN-A and VPN-B, represent
commonly used present-day corporate VPN security choices and
anticipated future choices, respectively. This document proposes
four new UI suites based on implementations of the United States
National Security Agency's Suite B algorithms (see [SuiteB]).
As with the VPN suites, the Suite B suites are simply collections of
values for some options in IPsec. Use of UI suites does not change
the IPsec protocols in any way.
2. Requirements Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as described in [RFC2119].
3. New UI Suites
Each of the following UI suites provides choices for ESP (see
[RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]).
The four suites are differentiated by the choice of cryptographic
algorithm strengths and a choice of whether the Encapsulating
Security Payload (ESP) is to provide both confidentiality and
integrity or integrity only. The suite names are based on the
Advanced Encryption Standard [AES] mode and AES key length specified
for ESP.
IPsec implementations that use these UI suites SHOULD use the suite
names listed here. IPsec implementations SHOULD NOT use names
different than those listed here for the suites that are described,
and MUST NOT use the names listed here for suites that do not match
these values. These requirements are necessary for interoperability.
3.1. Suite "Suite-B-GCM-128"
This suite provides ESP integrity protection and confidentiality
using 128-bit AES-GCM (see [RFC4106]). This suite or the following
suite should be used when ESP integrity protection and encryption are
both needed.
ESP:
Encryption AES with 128-bit keys and 16-octet Integrity
Check Value (ICV) in GCM mode [RFC4106]
Integrity NULL
Law & Solinas Informational [Page 2]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-256 [RFC4754].
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
3.2. Suite "Suite-B-GCM-256"
This suite provides ESP integrity protection and confidentiality
using 256-bit AES-GCM (see [RFC4106]). This suite or the preceding
suite should be used when ESP integrity protection and encryption are
both needed.
ESP:
Encryption AES with 256-bit keys and 16-octet ICV in GCM mode
[RFC4106]
Integrity NULL
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-384 [RFC4754].
Law & Solinas Informational [Page 3]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
3.3. Suite "Suite-B-GMAC-128"
This suite provides ESP integrity protection using 128-bit AES-GMAC
(see [RFC4543]) but does not provide confidentiality. This suite or
the following suite should be used only when there is no need for ESP
encryption.
ESP:
Encryption NULL
Integrity AES with 128-bit keys in GMAC mode [RFC4543]
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-256 [RFC4754].
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
Law & Solinas Informational [Page 4]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
3.4. Suite "Suite-B-GMAC-256"
This suite provides ESP integrity protection using 256-bit AES-GMAC
(see [RFC4543]) but does not provide confidentiality. This suite or
the preceding suite should be used only when there is no need for ESP
encryption.
ESP:
Encryption NULL
Integrity AES with 256-bit keys in GMAC mode [RFC4543]
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-384 [RFC4754].
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
4. Security Considerations
This document inherits all of the security considerations of the
IPsec, IKEv1, and IKEv2 documents. See [CNSSP-15] for guidance on
the use of AES in these suites for the protection of U.S. Government
information.
Some of the security options specified in these suites may be found
in the future to have properties significantly weaker than those that
were believed at the time this document was produced.
Law & Solinas Informational [Page 5]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
5. IANA Considerations
IANA has created and will maintain a registry called "Cryptographic
Suites for IKEv1, IKEv2, and IPsec" (see [IANA-Suites]). The
registry consists of a text string and an RFC number that lists the
associated transforms. The four new suites in this document have
been added to this registry after approval by an expert designated by
the IESG.
The new values for the registry are:
Identifier Defined in
Suite-B-GCM-128 RFC 4869
Suite-B-GCM-256 RFC 4869
Suite-B-GMAC-128 RFC 4869
Suite-B-GMAC-256 RFC 4869
6. References
6.1. Normative References
[FIPS-180-2] FIPS 180-2 with change notice, "Secure Hash Standard",
National Institute of Standards and Technology,
February 2004.
[IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic
Suites for IKEv1, IKEv2, and IPsec",
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter
Mode (GCM) in IPsec Encapsulating Security Payload
(ESP)", RFC 4106, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Law & Solinas Informational [Page 6]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC
4308, December 2005.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC
4543, May 2006.
[RFC4753] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
RFC 4753, November 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
Using ECDSA", RFC 4754, November 2006.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
2007.
6.2. Informative References
[AES] U.S. Department of Commerce/National Institute of
Standards and Technology, "Advanced Encryption Standard
(AES)", FIPS PUB 197, November 2001,
.
[CNSSP-15] Committee on National Security Systems, "National
Policy on the Use of the Advanced Encryption Standard
(AES) to Protect National Security Systems and National
Security Information", June 2003,
.
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[SuiteB] U.S. National Security Agency, "Fact Sheet NSA Suite B
Cryptography", July 2005,.
Law & Solinas Informational [Page 7]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
Authors' Addresses
Laurie E. Law
National Information Assurance Research Laboratory
National Security Agency
EMail: lelaw@orion.ncsc.mil
Jerome A. Solinas
National Information Assurance Research Laboratory
National Security Agency
EMail: jasolin@orion.ncsc.mil
Law & Solinas Informational [Page 8]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Law & Solinas Informational [Page 9]
Request for Comments: 4869 J. Solinas
Category: Informational NSA
May 2007
Suite B Cryptographic Suites for IPsec
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document proposes four optional cryptographic user interface
suites ("UI suites") for IPsec, similar to the two suites specified
in RFC 4308. The four new suites provide compatibility with the
United States National Security Agency's Suite B specifications.
Table of Contents
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. New UI Suites ...................................................2
3.1. Suite "Suite-B-GCM-128" ....................................2
3.2. Suite "Suite-B-GCM-256" ....................................3
3.3. Suite "Suite-B-GMAC-128" ...................................4
3.4. Suite "Suite-B-GMAC-256" ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
Law & Solinas Informational [Page 1]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
1. Introduction
[RFC4308] proposes two optional cryptographic user interface suites
("UI suites") for IPsec. The two suites, VPN-A and VPN-B, represent
commonly used present-day corporate VPN security choices and
anticipated future choices, respectively. This document proposes
four new UI suites based on implementations of the United States
National Security Agency's Suite B algorithms (see [SuiteB]).
As with the VPN suites, the Suite B suites are simply collections of
values for some options in IPsec. Use of UI suites does not change
the IPsec protocols in any way.
2. Requirements Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as described in [RFC2119].
3. New UI Suites
Each of the following UI suites provides choices for ESP (see
[RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]).
The four suites are differentiated by the choice of cryptographic
algorithm strengths and a choice of whether the Encapsulating
Security Payload (ESP) is to provide both confidentiality and
integrity or integrity only. The suite names are based on the
Advanced Encryption Standard [AES] mode and AES key length specified
for ESP.
IPsec implementations that use these UI suites SHOULD use the suite
names listed here. IPsec implementations SHOULD NOT use names
different than those listed here for the suites that are described,
and MUST NOT use the names listed here for suites that do not match
these values. These requirements are necessary for interoperability.
3.1. Suite "Suite-B-GCM-128"
This suite provides ESP integrity protection and confidentiality
using 128-bit AES-GCM (see [RFC4106]). This suite or the following
suite should be used when ESP integrity protection and encryption are
both needed.
ESP:
Encryption AES with 128-bit keys and 16-octet Integrity
Check Value (ICV) in GCM mode [RFC4106]
Integrity NULL
Law & Solinas Informational [Page 2]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-256 [RFC4754].
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
3.2. Suite "Suite-B-GCM-256"
This suite provides ESP integrity protection and confidentiality
using 256-bit AES-GCM (see [RFC4106]). This suite or the preceding
suite should be used when ESP integrity protection and encryption are
both needed.
ESP:
Encryption AES with 256-bit keys and 16-octet ICV in GCM mode
[RFC4106]
Integrity NULL
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-384 [RFC4754].
Law & Solinas Informational [Page 3]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
3.3. Suite "Suite-B-GMAC-128"
This suite provides ESP integrity protection using 128-bit AES-GMAC
(see [RFC4543]) but does not provide confidentiality. This suite or
the following suite should be used only when there is no need for ESP
encryption.
ESP:
Encryption NULL
Integrity AES with 128-bit keys in GMAC mode [RFC4543]
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-256 [RFC4754].
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
Law & Solinas Informational [Page 4]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
3.4. Suite "Suite-B-GMAC-256"
This suite provides ESP integrity protection using 256-bit AES-GMAC
(see [RFC4543]) but does not provide confidentiality. This suite or
the preceding suite should be used only when there is no need for ESP
encryption.
ESP:
Encryption NULL
Integrity AES with 256-bit keys in GMAC mode [RFC4543]
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-384 [RFC4754].
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
4. Security Considerations
This document inherits all of the security considerations of the
IPsec, IKEv1, and IKEv2 documents. See [CNSSP-15] for guidance on
the use of AES in these suites for the protection of U.S. Government
information.
Some of the security options specified in these suites may be found
in the future to have properties significantly weaker than those that
were believed at the time this document was produced.
Law & Solinas Informational [Page 5]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
5. IANA Considerations
IANA has created and will maintain a registry called "Cryptographic
Suites for IKEv1, IKEv2, and IPsec" (see [IANA-Suites]). The
registry consists of a text string and an RFC number that lists the
associated transforms. The four new suites in this document have
been added to this registry after approval by an expert designated by
the IESG.
The new values for the registry are:
Identifier Defined in
Suite-B-GCM-128 RFC 4869
Suite-B-GCM-256 RFC 4869
Suite-B-GMAC-128 RFC 4869
Suite-B-GMAC-256 RFC 4869
6. References
6.1. Normative References
[FIPS-180-2] FIPS 180-2 with change notice, "Secure Hash Standard",
National Institute of Standards and Technology,
February 2004.
[IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic
Suites for IKEv1, IKEv2, and IPsec",
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter
Mode (GCM) in IPsec Encapsulating Security Payload
(ESP)", RFC 4106, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Law & Solinas Informational [Page 6]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC
4308, December 2005.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC
4543, May 2006.
[RFC4753] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
RFC 4753, November 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
Using ECDSA", RFC 4754, November 2006.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
2007.
6.2. Informative References
[AES] U.S. Department of Commerce/National Institute of
Standards and Technology, "Advanced Encryption Standard
(AES)", FIPS PUB 197, November 2001,
[CNSSP-15] Committee on National Security Systems, "National
Policy on the Use of the Advanced Encryption Standard
(AES) to Protect National Security Systems and National
Security Information", June 2003,
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[SuiteB] U.S. National Security Agency, "Fact Sheet NSA Suite B
Cryptography", July 2005,
Law & Solinas Informational [Page 7]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
Authors' Addresses
Laurie E. Law
National Information Assurance Research Laboratory
National Security Agency
EMail: lelaw@orion.ncsc.mil
Jerome A. Solinas
National Information Assurance Research Laboratory
National Security Agency
EMail: jasolin@orion.ncsc.mil
Law & Solinas Informational [Page 8]
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Law & Solinas Informational [Page 9]
Subscribe to:
Posts (Atom)