idnits 2.17.1 draft-kario-gss-qr-kex-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document updates RFC4462, but the abstract doesn't seem to directly say this. It does mention RFC4462 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 231 has weird spacing: '... string out...' == Line 236 has weird spacing: '... string out...' == Line 244 has weird spacing: '... string out...' == Line 249 has weird spacing: '... string enc...' == Line 251 has weird spacing: '... string out...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4462, updated by this document, for RFC5378 checks: 2001-01-18) -- 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 (Sep 30, 2020) is 1296 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'NIST-SP-800-131Ar1' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC6194' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 440, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 7546 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Kario 3 Internet-Draft Red Hat, Inc. 4 Updates: 4462 (if approved) Sep 30, 2020 5 Intended status: Standards Track 6 Expires: April 3, 2021 8 Quantum-Resistant GSS-API Key Exchange for SSH 9 draft-kario-gss-qr-kex-00 11 Abstract 13 This document specifies additions and amendments to RFC4462. It 14 defines a new key exchange method that uses GSS-API in a way to 15 provide key exchange method that is resistant to attacks by quantum 16 computers. The purpose of this specification is to provide an easy- 17 to-implement upgrade to environments that require resistance against 18 quantum computers before widely accepted post-quantum cryptography 19 algorithms are established. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 3, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 58 4. New Quantum Resistant Key Exchange Methods . . . . . . . . . 3 59 4.1. Generic Quantum Resistant GSS-API key Exchange . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6.1. Symmetric cipher security . . . . . . . . . . . . . . . . 7 63 6.2. User authentication . . . . . . . . . . . . . . . . . . . 8 64 6.3. Used GSSAPI Mechanisms . . . . . . . . . . . . . . . . . 8 65 6.4. GSSAPI Delegation . . . . . . . . . . . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for 74 authentication and key exchange in SSH. Unfortunately for resistance 75 against quantum computers all of the methods in RFC 4462 as well as 76 all of the new methods introduced in SSH GSS-API SHA-2 Methods 77 [RFC8732] derive their security from Finite-Field Diffie-Hellman or 78 Elliptic Curve Diffie-Hellman key exchanges. Both FFDH and ECDH are 79 believed to be vulnerable to Shor's algorithm running on quantum 80 computers. This document updates RFC4462 with new methods intended 81 for use in environments where use of quantum resistant algorithms is 82 more important that the forward secrecy provided by FFDH and ECDH. 84 2. Rationale 86 Due to security concerns with FFDH and ECDH against attacks using 87 quantum computers, we propose a new key exchange method that does not 88 use FFDH or ECDH to agree on a shared secret to derive later 89 encryption keys but rather uses GSS-API as a secure communication 90 channel to exchange secrets that are then used to derive encryption 91 keys. 93 To provide resistance against quantum computer attacks the connection 94 needs to also carefully select encryption ciphers, and host 95 authentication methods. 97 3. Document Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 RFC2119 [RFC2119] RFC8174 [RFC8174] when, and only when, they 103 appear in all capitals, as shown here. 105 4. New Quantum Resistant Key Exchange Methods 107 This document adopts the same naming convention as defined in 108 [RFC4462] to define families of methods that cover any GSS-API 109 mechanism used with a specific SHA-2 Hash. It also reuses much of 110 the the scheme defined in Section 2.1 of [RFC4462]. 112 The following new key exchange algorithms are defined: 114 +--------------------------+--------------------------------+ 115 | Key Exchange Method Name | Implementation Recommendations | 116 +--------------------------+--------------------------------+ 117 | gss-qr-sha256-* | SHOULD/RECOMMENDED | 118 | gss-qr-sha512-* | MAY/OPTIONAL | 119 +--------------------------+--------------------------------+ 121 Each key exchange method is implicitly registered by this document. 122 The IESG is considered to be the owner of all these key exchange 123 methods; this does NOT imply that the IESG is considered to be the 124 owner of the underlying GSS-API mechanism. 126 Each method in any family of methods specifies GSS-API-authenticated 127 exchanges as described in Section 2.1 of [RFC4462]. The method name 128 for each method is the concatenation of the family name prefix with 129 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 130 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 131 Base64 encoding is described in Section 6.8 of [RFC2045]. 133 Family method references 135 +--------------------+---------------+ 136 | Family Name prefix | Hash Function | 137 +--------------------+---------------+ 138 | gss-qr-sha256- | SHA-256 | 139 | gss-qr-sha512- | SHA-512 | 140 +--------------------+---------------+ 142 4.1. Generic Quantum Resistant GSS-API key Exchange 144 This section reuses much of the scheme defined in Section 2.1 of 145 [RFC4462] though it does not transport FFDH key shares in the 146 exchanged messages. 148 This section defers to [RFC7546] as the source of information on GSS- 149 API context establishment operations, Section 3 being the most 150 relevant. All security considerations described in [RFC7546] apply 151 here too. 153 The parties generate nonces in the key exchange. The generated 154 nonces MUST be at least 256 bits long and come from a quantum safe 155 CSPRNG. The nonces MUST NOT be reused in other key exchanges. 157 The client initiates negotiation by calling GSS_Init_sec_context() 158 and the server responds to it by calling GSS_Accept_sec_context(). 159 For the negotiation, client MUST set the mutual_req_flag, 160 conf_req_flag, and integ_req_flag flag to "true". In addition, 161 deleg_req_flag MAY be set to "true" to request access delegation, if 162 requested by the user. Since the key exchange process authenticates 163 only the host, the setting of anon_req_flag is immaterial to this 164 process. If the client does not support the "gssapi-keyex" user 165 authentication method described in Section 4 of [RFC4462], or does 166 not intend to use that method in conjunction with the GSS-API context 167 established during key exchange, then anon_req_flag SHOULD be set to 168 "true". Otherwise, this flag MAY be set to true if the client wishes 169 to hide its identity. This key exchange process will exchange only a 170 single message token once the context has been established; 171 therefore, the replay_det_req_flag and sequence_req_flag SHOULD be 172 set to "false". 174 During GSS context establishment, multiple tokens may be exchanged by 175 the client and the server. When the GSS context is established 176 (major_status is GSS_S_COMPLETE), the parties check that mutual_state 177 and integ_avail are both "true". If not, the key exchange MUST fail. 179 To verify the integrity of the handshake both peers use the Hash 180 Function defined by the selected Key Exchange method to calculate the 181 running hash of exchanged messages, H_S and H_C. 183 H_S = hash(V_C || V_S || I_C || KC_S || ... || KC_C). 185 H_C = hash(V_C || V_S || I_C || KC_S || ... || KC_C || KC). 187 The GSS_wrap() call is used by the server and client to encrypt the 188 calculated hash and the selected nonce. The peers use the 189 GSS_unwrap() to decrypt the value used to check if the other peer has 190 received the same messages and to get the nonce it selected. 192 Peers MUST verify if the length of the selected nonce is not shorter 193 than 32 octets. If the received nonce is shorter, the key exchange 194 MUST fail. 196 The following is an overview of the key exchange process: 198 Client Server 199 ------ ------ 200 Calls GSS_Init_sec_context(). 201 SSH_MSG_KEXGSS_INIT ---------------> 203 (Loop) 204 | Calls GSS_Accept_sec_context(). 205 | <------------ SSH_MSG_KEXGSS_CONTINUE 206 | Calls GSS_Init_sec_context(). 207 | SSH_MSG_KEXGSS_CONTINUE ------------> 209 Calls GSS_Accept_sec_context(). 210 Generates ephemeral nonce. 211 Computes hash H_S. 212 Calls GSS_wrap( H_S || nonce_S ). 213 <------------ SSH_MSG_KEXGSS_COMPLETE 215 Computes hash H_S. 216 Calls GSS_unwrap(). 217 Verifies that computed H_S matches received value. 218 Computes hash H_C. 219 Generates ephemeral nonce. 220 Calls GSS_wrap( H_C || nonce_C ). 221 SSH_MSG_KEXGSS_COMPLETE ------------> 222 Computes hash H_C. 223 Calls GSS_unwrap(). 224 Verifies that computed H_C matches received value. 226 This is implemented with the following messages: 228 The client sends: 230 byte SSH_MSG_KEXGSS_INIT 231 string output_token (from GSS_Init_sec_context()) 233 The server sends: 235 byte SSH_MSG_KEXGSS_CONTINUE 236 string output_token (from GSS_Accept_sec_context()) 238 Each time the client receives the message described above, it makes 239 another call to GSS_Init_sec_context(). 241 The client sends: 243 byte SSH_MSG_KEXGSS_CONTINUE 244 string output_token (from GSS_Init_sec_context()) 246 The final server message is either: 248 byte SSH_MSG_KEXGSS_COMPLETE 249 string enc_nonce (GSS_wrap() of H_S and nonce_S) 250 boolean TRUE 251 string output_token (from GSS_Accept_sec_context()) 253 Or the following if no output_token is available: 255 byte SSH_MSG_KEXGSS_COMPLETE 256 string enc_nonce (GSS_wrap() of H_S and nonce_S) 257 boolean FALSE 259 As the final message the client sends either: 261 byte SSH_MSG_KEXGSS_COMPLETE 262 string enc_nonce (GSS_wrap() of H_C and nonce_C) 263 boolean TRUE 264 string output_token (from GSS_Accept_sec_context()) 266 Or the following if no output_token is available: 268 byte SSH_MSG_KEXGSS_COMPLETE 269 string enc_nonce (GSS_wrap() of H_C and nonce_C) 270 boolean FALSE 272 The hashes H_S and H_C are computed as the HASH hash of the 273 concatenation of the following: 275 string V_C, the client's version string (CR, NL excluded) 276 string V_S, server's version string (CR, NL excluded) 277 string I_C, payload of the client's SSH_MSG_KEXINIT 278 string I_S, payload of the server's SSH_MSG_KEXINIT 279 string KC_S, payload of the server's SSH_MSG_KEXGSS_CONTINUE 280 string KC_C, payload of the client's SSH_MSG_KEXGSS_CONTINUE 281 string KC_S, payload of the server's second SSH_MSG_KEXGSS_CONTINUE 282 string KC_C, payload of the client's second SSH_MSG_KEXGSS_CONTINUE 283 ... 284 string KC, payload of the server's SSH_MSG_KEXGSS_COMPLETE 286 Those values are called exchange hashes, and they are used to 287 authenticate the key exchange. The exchange hashes SHOULD be kept 288 secret. If no SSH_MSG_KEXGSS_CONTINUE messages have been sent by the 289 server or received by the client, then an empty string is used in 290 place of KC_S and KC_C when computing the exchange hash. When 291 multiple SSH_MSG_KEXGSS_CONTINUE messages have been sent by either 292 side, then they should all be included in the exchange hash, in order 293 they have been processed by both sides of the connection. For the 294 H_S hash, the KC is an empty string. 296 Once a party has both the server nonce (nonce_S) and the client nonce 297 (nonce_C) it concatenates them, in this order, to compute the used 298 shared secret K: 300 K = nonce_S || nonce_C 302 If the client receives a SSH_MSG_KEXGSS_CONTINUE message after a call 303 to GSS_Init_sec_context() has returned a major_status code of 304 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 305 MUST fail. 307 If the client receives a SSH_MSG_KEXGSS_COMPLETE message and a call 308 to GSS_Init_sec_context() does not result in a major_status code of 309 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 310 MUST fail. 312 5. IANA Considerations 314 This document augments the SSH Key Exchange Method Names in 315 [RFC4462]. 317 IANA is requested to update the SSH Protocol Parameters 318 [IANA-KEX-NAMES] registry with the following entries: 320 +--------------------------+------------+ 321 | Key Exchange Method Name | Reference | 322 +--------------------------+------------+ 323 | gss-qr-sha256-* | This draft | 324 | gss-qr-sha512-* | This draft | 325 +--------------------------+------------+ 327 6. Security Considerations 329 6.1. Symmetric cipher security 331 Current understanding of quantum computer capabilities suggest that 332 symmetric ciphers with keys smaller than 256 bits will require less 333 than the current recommended minimal work factor of 2^128 operations. 335 As such, connections that use this key exchange methods MUST use 336 ciphers with at least 256 bit keys to retain quantum resistance. 338 6.2. User authentication 340 For the connection to remain resistant against quantum computers, the 341 user authentication needs to also use quantum resistant algorithms. 342 In particular, it's RECOMMENDED that connections use gssapi-keyex for 343 client authentication. The publickey mechanism MUST NOT be used 344 unless the asymmetric keys used for it use post-quantum algorithms. 345 DSA, ECDSA, and RSA keys MUST NOT be used. 347 6.3. Used GSSAPI Mechanisms 349 The security of the key exchange depends on the security of the used 350 GSSAPI mechanism. The described key exchange will be quantum 351 resistant only in case the used GSSAPI mechanism is quantum 352 resistant. 354 For example, the Kerberos 5 mechanism is quantum resistant only when 355 it's used together with algorithms and key sizes that are quantum 356 resistant. Quantum safe algorithm SHOULD be used throught the 357 kerberos infrastructure, both for authentication and encryption. 358 Currently aes256-cts-hmac-sha384-192 mechanism defined in [RFC8009] 359 for encryption is an example of such an algorithm. 361 6.4. GSSAPI Delegation 363 Some GSSAPI mechanisms can act on a request to delegate credentials 364 to the target host when the deleg_req_flag is set. In this case, 365 extra care must be taken to ensure that the acceptor being 366 authenticated matches the target the user intended. Some mechanisms 367 implementations (like commonly used krb5 libraries) may use insecure 368 DNS resolution to canonicalize the target name; in these cases 369 spoofing a DNS response that points to an attacker-controlled machine 370 may results in the user silently delegating credentials to the 371 attacker, who can then impersonate the user at will. 373 7. References 375 7.1. Normative References 377 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 378 DOI 10.17487/RFC1321, April 1992, 379 . 381 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 382 Extensions (MIME) Part One: Format of Internet Message 383 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 384 . 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 392 "Generic Security Service Application Program Interface 393 (GSS-API) Authentication and Key Exchange for the Secure 394 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 395 2006, . 397 [RFC7546] Kaduk, B., "Structure of the Generic Security Service 398 (GSS) Negotiation Loop", RFC 7546, DOI 10.17487/RFC7546, 399 May 2015, . 401 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 402 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 403 May 2017, . 405 [RFC8732] Sorce, S. and H. Kario, "Generic Security Service 406 Application Program Interface (GSS-API) Key Exchange with 407 SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, 408 . 410 7.2. Informative References 412 [IANA-KEX-NAMES] 413 Internet Assigned Numbers Authority, "Secure Shell (SSH) 414 Protocol Parameters: Key Exchange Method Names", June 415 2005, . 418 [ISO-IEC-8825-1] 419 International Organization for Standardization / 420 International Electrotechnical Commission, "ASN.1 encoding 421 rules: Specification of Basic Encoding Rules (BER), 422 Canonical Encoding Rules (CER) and Distinguished Encoding 423 Rules (DER)", ISO/IEC 8825-1, November 2015, 424 . 427 [NIST-SP-800-131Ar1] 428 National Institute of Standards and Technology, 429 "Transitions: Recommendation for Transitioning of the Use 430 of Cryptographic Algorithms and Key Lengths", NIST Special 431 Publication 800-131A Revision 1, November 2015, 432 . 435 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 436 Considerations for the SHA-0 and SHA-1 Message-Digest 437 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 438 . 440 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 441 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 442 DOI 10.17487/RFC6234, May 2011, 443 . 445 [RFC8009] Jenkins, M., Peck, M., and K. Burgin, "AES Encryption with 446 HMAC-SHA2 for Kerberos 5", RFC 8009, DOI 10.17487/RFC8009, 447 October 2016, . 449 Author's Address 451 Hubert Kario 452 Red Hat, Inc. 453 Purkynova 115 454 Brno 612 00 455 Czech Republic 457 Email: hkario@redhat.com