RFC 5647

AES Galois Counter Mode for the Secure Shell Transport Layer Protocol

📅 published August 2009, from ietf

RFC 5647: AES Galois Counter Mode for the Secure Shell Transport Layer Protocol 🎀

Okay bestie, this one is from K. Igoe and J. Solinas at the National Security Agency, published August 2009 🌸. It's an Informational doc (so it's sharing knowledge, not setting a standard 💅), and the title block has no Obsoletes or Updates line, so it doesn't replace or change any other RFC 🦋. It's all about getting AES-GCM working inside SSH, which is the secure remote-login protocol we all love 💜.

Network Working Group                                            K. Igoe
Request for Comments: 5647                                    J. Solinas
Category: Informational                         National Security Agency
                                                             August 2009

Abstract ✨

Secure shell (SSH) is a secure remote-login protocol 🔐. SSH supports algorithms for authentication, key agreement, confidentiality, and data integrity, and this doc shows how AES Galois Counter Mode can give SSH's Transport Layer Protocol both confidentiality and data integrity in one go. Iconic 👑.

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 ©️

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.

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 gives you both confidentiality and data integrity 💖. GCM uses counter mode to encrypt the data, and that's an operation that can be efficiently pipelined ⚡. GCM's authentication also uses operations that are super well suited to efficient hardware implementation, so it's especially appealing for high-speed implementations or for implementations in an efficient and compact circuit 🔥. This doc shows 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] 🫶.

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 gives you 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, so go read it if you're curious 🤓. In this doc, we shall focus on AES GCM, which is 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:

  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 not allowed to return any part of the plaintext until the authentication tag has been validated 🚫. This makes the security analysis of any system using AES-GCM a lot simpler, but it 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 set up two secure tunnels between a client and a server 🚇. One tunnel carries client-to-server communications and the other carries server-to-client communications. Each tunnel is encrypted, and a message authentication code is used to make sure the data hasn't been tampered with 🔒.

5.1. Key Exchange 🔑

These tunnels are initialized using the secure shell key exchange protocol described in Section 7 of [RFC4253] ✨. This protocol negotiates a mutually acceptable set of cryptographic algorithms, and it 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. Going the other way, 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 its own distinct set of symmetric keys. The keys are generated as shown in Figure 1. The sizes of these keys vary depending on 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'll see below, SSH AES-GCM needs a 12-octet Initial IV and an encryption key of either 16 or 32 octets 🎯. Because an AEAD algorithm like 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 the client may request a rekey of the secure shell session at any time 🔄. When that happens, the shared secret value K, the exchange hash H, and all of the symmetric keys above get updated. Only the session_id stays the same 💜.

5.2. Secure Shell Binary Packets 📦

Once the key exchange protocol finishes, all further secure shell traffic gets parsed into a data structure called a secure shell binary packet, 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 goes into the MAC field at the end of the secure shell binary packet 🏁.

6.3. Size of the Authentication Tag ✨

okay so both AEAD_AES_128_GCM and AEAD_AES_256_GCM spit out a 16-octet Authentication Tag 🎀 ([RFC5116] calls it a "Message Authentication Code"). some apps like to use a truncated version of that tag, but that is not allowed in AES-GCM secure shell 🙅‍♀️. every implementation of AES-GCM secure shell MUST use the full 16-octet Authentication Tag 💖

7. Processing Binary Packets in AES-GCM Secure Shell 🦋

7.1. IV and Counter Management 💅

okay this part is so satisfying 🥹. with AES-GCM, the 12-octet IV gets split 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 gets 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 makes a keystream in blocks of 16-octets, and that keystream is what encrypts the plaintext 🔐. the keystream comes from encrypting this 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 starts at one (1) and goes up by one every time a 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 📦

okay so in AES-GCM secure shell, these are the inputs to the authenticated encryption 👀:

  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.

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) ✨. and 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 🤔

so [RFC4253] (Section 6.3 of it) says the packet length, padding length, payload, and padding fields of each binary packet have to be encrypted 😭. and that creates a whole problem for SSH AES-GCM, bc:

the tag cannot be verified until we parse the binary packet.
the packet cannot be parsed until the packet_length has been decrypted.
the packet_length cannot be decrypted until the tag has been verified.

it's a literal loop 💀. so when you use AES-GCM with secure shell, the packet_length field is treated as additional authenticated data, not as plaintext. yes this violates the requirements of [RFC4253] 🙈. the repercussions of this decision get covered in the Security Considerations section right after this one, so keep reading 👑

8. Security Considerations 🚨

this part is serious bestie, don't skip it 😤

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, having the invocation_counter field in the IV makes sure the sequence_number is indeed involved in forming the integrity tag 🔒. the involvement is a little different though, and it's different from what Section 6.4 of [RFC4253] asks for 🧐

8.2. Non-Encryption of Packet Length 🙈

so as talked about in Section 7.3, there's an incompatibility between three things: 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 need to decrypt the packet length field to find the authentication tag 😩. this document deals with that dilemma by requiring that, in AES-GCM, the packet length field will not be encrypted, and will instead be processed as additional authenticated data 🫠

in theory, you could argue that encrypting the entire binary packet means the secure shell dataflow becomes a featureless octet stream 🌫️. but in practice, the secure shell dataflow comes in bursts, and the length of each burst is strongly correlated to the length of the underlying binary packets 💥. so encrypting the packet length doesn't do much by itself to hide the length of the underlying binary packets 🤷‍♀️. secure shell has two other mechanisms, random padding and SSH_MSG_IGNORE messages, that are way more effective than encrypting the packet length at masking any structure in the underlying plaintext stream that the length of the binary packets might reveal 🎀

9. IANA Considerations 📝

okay so 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 |
                 +--------------------+-------------+

and IANA also 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 |
                 +--------------------+-------------+

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

🎀💖 that's the whole thing, bestie 🦋✨

📦 where this page comes from

ietf: rfc5647 2009-08
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms