Network Working Group K. Igoe
Request for Comments: 5647 J. Solinas
Category: Informational National Security Agency
August 2009
AES Galois Counter Mode forthe 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 20093. 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 20097. Processing Binary Packets in AES-GCM Secure Shell7.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 FieldSection 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]