idnits 2.17.1 draft-igoe-secsh-aes-gcm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2009) is 5394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4263' is mentioned on line 332, but not defined == Missing Reference: 'RF4250' is mentioned on line 410, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K.M. Igoe 3 Internet Draft National Security Agency 4 Intended Status: Informational June 12, 2009 5 Expires: December 14, 2009 J.A. Solinas 6 National Security Agency 7 June 12, 2009 9 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol 10 draft-igoe-secsh-aes-gcm-03 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 14, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Secure Shell (SSH, RFC 4251) is a secure remote-login protocol. SSH 49 provides for algorithms that provide authentication, key agreement, 50 confidentiality and data integrity services. The purpose of this 51 document is to show how the AES Galois/Counter Mode can be used to 52 provide both confidentiality and data integrity to the SSH Transport 53 Layer 55 Table of Contents 57 1. Introduction.....................................................2 58 2. Requirements Terminology.........................................2 59 3. Applicability Statement..........................................3 60 4. Properties of Galois Counter Mode................................3 61 4.1. AES GCM Authenticated Encryption............................3 62 4.2. AES GCM Authenticated Decryption............................4 63 5. Review of Secure Shell...........................................4 64 5.1. Key Exchange................................................4 65 5.2. Secure Shell Binary Packets.................................5 66 6. AES GCM Algorithms for Secure Shell..............................6 67 6.1. AEAD_AES_128_GCM............................................6 68 6.2. AEAD_AES_256_GCM............................................6 69 6.3. Size of the Authentication Tag..............................6 70 7. Processing Binary Packets in AES-GCM Secure Shell................6 71 7.1. IV and Counter Management...................................7 72 7.2. Formation of the Binary Packet..............................7 73 7.3. Treatment of the Packet Length Field........................8 74 8. Security Considerations..........................................8 75 8.1. Use of the Packet Sequence Number in the AT.................8 76 8.2. Non-encryption of Packet Length.............................8 77 9. IANA Considerations.............................................10 78 10. References.....................................................10 79 10.1. Normative References......................................10 81 1. Introduction 83 Galois/Counter Mode (GCM) is a block cipher mode of operation that 84 provides both confidentiality and data integrity services. GCM use 85 counter mode to encrypt the data, an operation that can be 86 efficiently pipelined. Further, GCM authentication uses operations 87 that are particularly well suited to efficient implementation in 88 hardware, making it especially appealing for high-speed 89 implementations, or for implementations in an efficient and compact 90 circuit. The purpose of this document is to show how GCM with either 91 AES-128 or AES-256 can be integrated into the Secure Shell Transport 92 Layer Protocol, RFC 4253. 94 2. Requirements Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Applicability Statement 101 Using AES-GCM to provide both confidentiality and data integrity is 102 generally more efficient than using two separate algorithms to 103 provide these security services. 105 4. Properties of Galois Counter Mode 107 Galois Counter Mode (GCM) is a mode of operation for block ciphers 108 which provides both confidentiality and data integrity. NIST Special 109 Publication SP 800 38D [GCM] gives an excellent explanation of Galois 110 Counter Mode. In this document we shall focus on AES GCM, the use of 111 the Advanced Encryption Algorithm (AES) in Galois Counter Mode. 112 AES-GCM is an example of an "algorithm for authenticated encryption 113 with associated data" (AEAD algorithm) as described in [RFC5116]. 115 4.1. AES GCM Authenticated Encryption 117 An invocation of AES GCM to perform an authenticated encryption has 118 the following inputs and outputs: 120 GCM Authenticated Encryption 122 Inputs: 123 octet_string PT ; // Plain text, to be both 124 // authenticated and encrypted 125 octet_string AAD; // Additional Authenticated Data, 126 // authenticated but not encrypted 127 octet_string IV; // Initialization vector 128 octet_string BK; // Block cipher key 130 Outputs: 131 octet_string CT; // Cipher Text 132 octet_string AT; // Authentication Tag 134 Note: in [RFC5116] the IV is called the nonce. 136 For a given block cipher key BK it is critical that no IV be used 137 more than once. Section 7.1 addresses how this goal is to be 138 achieved in secure shell. 140 4.2. AES GCM Authenticated Decryption 142 An invocation of AES GCM to perform an authenticated decryption has 143 the following inputs and outputs: 145 GCM Authenticated Decryption 147 Inputs: 148 octet_string CT ; // Cipher text, to be both 149 // authenticated and decrypted. 150 octet_string AAD; // Additional Authenticated Data, 151 // authenticated only. 152 octet_string AT; // Authentication Tag 153 octet_string IV; // Initialization vector 154 octet_string BK; // Block cipher key. 156 Output: 157 Failure_Indicator; // Returned if the authentication tag 158 // is invalid. 159 octet_string PT; // Plain test, returned if and only if 160 // the authentication tag is valid. 162 AES-GCM is prohibited from returning any portion of the plaintext 163 until the authentication tag has been validated. Though this feature 164 greatly simplifies the security analysis of any system using AES-GCM, 165 as we shall see in section 7.2, this creates an incompatibility with 166 the requirements of secure shell. 168 5. Review of Secure Shell 170 The goal of secure shell is to establish two secure tunnels between a 171 client and a server, one tunnel carrying client-to-server 172 communications and the other server-to-client communications. Each 173 tunnel is encrypted and a message authentications code is used to 174 insure data integrity. 176 5.1. Key Exchange 178 These tunnels are initialized using the secure shell key exchange 179 protocol as described in section 7 of [RFC4253]. This protocol 180 negotiates a mutually acceptable set of cryptographic algorithms, and 181 produces a secret value K and an exchange hash H shared by the client 182 and server. The initial value of H is saved for use as the 183 session_id. 185 If AES-GCM is selected as the encryption algorithm for a given 186 tunnel, AES-GCM MUST also be selected as the mac algorithm. 187 Conversely, if AES-GCM is selected as the mac algorithm, it MUST also 188 be selected as the encryption algorithm. 190 As described in section 7.2 of [RFC4253], a hash based key derivation 191 function (KDF) is applied to the shared secret value K to generate 192 the required symmetric keys. Each tunnel gets a distinct set of 193 symmetric keys. The keys are generated as shown in figure 1. The 194 sizes of these keys varies depending upon which cryptographic 195 algorithms are being used. 197 Initial IV 198 Client-to-Sever HASH( K || H ||"A"|| session_id) 199 Server-to-Client HASH( K || H ||"B"|| session_id) 200 Encryption Key 201 Client-to-Sever HASH( K || H ||"C"|| session_id) 202 Server-to-Client HASH( K || H ||"D"|| session_id) 203 Integrity Key 204 Client-to-Sever HASH( K || H ||"E"|| session_id) 205 Server-to-Client HASH( K || H ||"F"|| session_id) 207 Figure 1: Key Derivation in Secure Shell 209 As we shall see below, SSH AES-GCM requires a 12-octet Initial IV and 210 an encryption key of either 16 or 32 octets. Because an AEAD 211 algorithm such as AES-GCM uses the encryption key to provide both 212 confidentiality and data integrity, the integrity key is not used 213 with AES-GCM. 215 Either the server or client may at any time request that the secure 216 shell session be rekeyed. The shared secret value K, the exchange 217 hash H, and all the above symmetric keys will be updated. Only the 218 session_id will remain unchanged. 220 5.2. Secure Shell Binary Packets 222 Upon completion of the key exchange protocol, all further secure 223 shell traffic is parsed into a data structure known as a secure shell 224 binary packet as shown below in Figure 2 (see also section 6 of 225 [RFC4253]). 227 uint32 packet_length; // 0 <= packet_length < 2^32 228 byte padding_length; // 4 <= padding_length < 256 229 byte[n1] payload; // n1 = packet_length-padding_length-1 230 byte[n2] random_padding; // n2 = padding_length 231 byte[m] mac; // m = mac_length 233 Figure 2: Structure of a Secure Shell Binary Packet 235 The authentication tag produced by AES-GCM authenticated encryption 236 will be placed in the mac field at the end of the secure shell binary 237 packet. 239 6. AES GCM Algorithms for Secure Shell 241 6.1. AEAD_AES_128_GCM 243 AEAD_AES_128_GCM is specified in section 5.1 of [RFC5116]. Due to 244 the of format of secure shell binary packets, the buffer sizes needed 245 to implement AEAD_AES_128_GCM are smaller than those required in 246 [RFC5116]. Using the notation defined in [RFC5116], the input and 247 output lengths for AEAD_AES_128_GCM in secure shell are as follows: 249 PARAMETER Meaning Value 251 K_LEN AES key length 16 octets 252 P_MAX maximum plaintext length 2^32 - 32 octets 253 A_MAX maximum additional 4 octets 254 authenticated data length 255 N_MIN minimum nonce (IV) length 12 octets 256 N_MAX maximum nonce (IV) length 12 octets 257 C_MAX maximum cipher length 2^32 octets 259 6.2. AEAD_AES_256_GCM 261 AEAD_AES_256_GCM is specified in section 5.1 of [RFC5116]. Due to 262 the of format of secure shell binary packets, the buffer sizes needed 263 to implement AEAD_AES_256_GCM are smaller than those required in 264 [RFC5116]. Using the notation defined in [RFC5116], the input and 265 output lengths for AEAD_AES_256_GCM in secure shell are as follows: 267 PARAMETER Meaning Value 269 K_LEN AES key length 32 octets 270 P_MAX maximum plaintext length 2^32 - 32 octets 271 A_MAX maximum additional 4 octets 272 authenticated data length 273 N_MIN minimum nonce (IV) length 12 octets 274 N_MAX maximum nonce (IV) length 12 octets 275 C_MAX maximum cipher length 2^32 octets 277 6.3. Size of the Authentication Tag 279 Both AEAD_AES_128_GCM and AEAD_AES_256_GCM produce a 16-octet 280 Authentication Tag ([RFC5116] calls this a "message authentication 281 code".) Some applications allow use of a truncated version of this 282 tag. This is not allowed in AES-GCM secure shell. All 283 implementations of AES-GCM secure shell MUST use the full 16-octet 284 Authentication Tag. 286 7. Processing Binary Packets in AES-GCM Secure Shell 287 7.1. IV and Counter Management 289 With AES-GCM, the 12-octet IV is broken into two fields: a 4-octet 290 fixed field and an 8-octet invocation counter field. The invocation 291 field is treated as a 64-bit integer and is incremented after each 292 invocation of AES-GCM to process a binary packet. 294 uint32 fixed; // 4 octets 295 uint64 invocation_counter; // 8 octets 297 Figure 3: Structure of an SSH AES-GCM nonce 299 AES-GCM produces a keystream in blocks of 16-octets which is used to 300 encrypt the plaintext. This keystream is produced by encrypting the 301 following 16-octet data structure: 303 uint32 fixed; // 4 octets 304 uint64 invocation_counter; // 8 octets 305 uint32 block_counter; // 4 octets 307 Figure 4: Structure of an AES input for SSH AES-GCM 309 The block_counter is initially set to one (1) and incremented as each 310 block of key is produced. 312 The reader is reminded that SSH requires that the data to be 313 encrypted MUST be padded out to a multiple of the block size 314 (16-octets for AES-GCM). 316 7.2. Formation of the Binary Packet 318 In AES-GCM secure shell, the inputs to the authenticated encryption 319 are: 321 PT (Plain Text) 322 byte padding_length; // 4 <= padding_length < 256 323 byte[n1] payload; // n1 = packet_length-padding_length-1 324 byte[n2] random_padding; // n2 = padding_length 325 AAD (Additional Authenticated Data) 326 uint32 packet_length; // 0 <= packet_length < 2^32 327 IV (Initialization Vector) 328 As described in section 7.1. 329 BK (Block Cipher Key) 330 The appropriate Encryption Key formed during the Key Exchange. 332 As required in [RFC4263], the random_padding MUST be at least 4 333 octets in length but no more than 255 octets. The total length of 334 the PT MUST be a multiple of 16-octets (the block size of AES). 336 The binary packet is the concatenation of the 4-octet packet_length, 337 the cipher text CT, and the 16-octet authentication tag AT. 339 7.3. Treatment of the Packet Length Field 341 Section 6.3 of [RFC4253] requires that the packet length, padding 342 length, payload and padding fields of each binary packet be 343 encrypted. This presents a problem for SSH AES-GCM because: 345 1) The tag can not be verified until we parse the binary packet 346 2) The packet can not be parsed until the packet_length has been 347 decrypted. 348 3) The packet_length can not be decrypted until the tag has been 349 verified. 351 When using AES-GCM with secure shell, the packet_length field is to 352 be treated as additional authenticated data, not as plaintext. This 353 violates the requirements of [RFC4253]. The repercussions of this 354 decision are discussed in the security considerations section of this 355 document. 357 8. Security Considerations 359 The security considerations in [RFC4251] apply. 361 8.1. Use of the Packet Sequence Number in the AT 363 [RFC4253] requires that the formation of the AT involve the packet 364 sequence_number, a 32-bit value that counts the number of binary 365 packets that have been sent on a given SSH tunnel. Since the 366 sequence_number is, up to an additive constant, just the low 32-bits 367 of the invocation_counter, the presence of the invocation_counter 368 field in the IV insures that the sequence_number is indeed involved 369 in the formation of the integrity tag, though this involvement 370 differs slightly from the requirements in section 6.4 of [RFC4253]. 372 8.2. Non-encryption of Packet Length 374 As discussed in section 5.2.1, there is an incompatibility between 375 GCM's requirement that no plaintext be returned until the 376 authentication tag has been verified, secure shell's requirement that 377 the packet length be encrypted, and the necessity of decrypting the 378 packet length field to locate the authentication tag. This document 379 addresses this dilemma by requiring that, in AES-GCM, the packet 380 length field will not be encrypted but will instead be processed as 381 Additional Authenticated Data. 383 In theory, one could argue that encryption of the entire binary 384 packet means that the secure shell dataflow becomes a featureless 385 octet stream. But in practice, the secure shell dataflow will come 386 in bursts, with the length of each burst strongly correlated to the 387 length of the underlying binary packets. Encryption of the packet 388 length does little in and of itself to disguise the length of the 389 underlying binary packets. Secure shell provides two other 390 mechanisms, random padding and SSH_MSG_IGNORE messages, that are far 391 more effective than encrypting the packet length in masking any 392 structure in the underlying plaintext stream that might be revealed 393 by the length of the binary packets. 395 9. IANA Considerations 397 IANA will add the following two entries to the Secure Shell 398 Encryption Algorithm name Registry described in [RFC4250]: 400 +--------------------+-------------+ 401 | | | 402 | Name | Reference | 403 +--------------------+-------------+ 404 | AEAD_AES_128_GCM | Section 6.1 | 405 | | | 406 | AEAD_AES_256_GCM | Section 6.2 | 407 +--------------------+-------------+ 409 IANA will add the following two entries to the Secure Shell MAC 410 Algorithm name Registry described in [RF4250]: 412 +--------------------+-------------+ 413 | | | 414 | Name | Reference | 415 +--------------------+-------------+ 416 | AEAD_AES_128_GCM | Section 6.1 | 417 | | | 418 | AEAD_AES_256_GCM | Section 6.2 | 419 +--------------------+-------------+ 421 10. References 423 10.1. Normative References 425 [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of 426 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 427 Special Publication 800-30D, November 2007. 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 433 Protocol Assigned Numbers", RFC 4250, January 2006. 435 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 436 Protocol Architecture", RFC 4251, January 2006. 438 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 439 Transport Layer Protocol", RFC 4253, January 2006 441 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 442 Encryptions", RFC 5116, January 2008. 444 Author's Addresses 446 Kevin M. Igoe 447 NSA/CSS Commercial Solutions Center 448 National Security Agency 449 EMail: kmigoe@nsa.gov 451 Jerome A. Solinas 452 National Information Assurance Research Laboratory 453 National Security Agency 454 EMail: jasolin@orion.ncsc.mil 456 Acknowledgement 458 Funding for the RFC Editor function is provided by the IETF 459 Administrative Support Activity (IASA).