idnits 2.17.1 draft-ietf-curdle-gss-keyex-sha2-05.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 : ---------------------------------------------------------------------------- -- 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 415 has weird spacing: '... string out...' == Line 421 has weird spacing: '... string ser...' == Line 433 has weird spacing: '... string out...' == Line 446 has weird spacing: '... string out...' == Line 460 has weird spacing: '... string mic...' == (2 more instances...) (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 (Feb 22, 2018) is 2255 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI-X9-62-2005' == Outdated reference: A later version (-12) exists of draft-ietf-curdle-ssh-curves-07 ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 7546 ** Downref: Normative reference to an Informational RFC: RFC 7748 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2v2' Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Sorce 3 Internet-Draft H. Kario 4 Updates: 4462 (if approved) Red Hat, Inc. 5 Intended status: Standards Track Feb 22, 2018 6 Expires: August 26, 2018 8 GSS-API Key Exchange with SHA2 9 draft-ietf-curdle-gss-keyex-sha2-05 11 Abstract 13 This document specifies additions and amendments to RFC4462. It 14 defines a new key exchange method that uses SHA-2 for integrity and 15 deprecates weak DH groups. The purpose of this specification is to 16 modernize the cryptographic primitives used by GSS Key Exchanges. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 26, 2018. 35 Copyright Notice 37 Copyright (c) 2018 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 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 55 4. New Diffie-Hellman Key Exchange methods . . . . . . . . . . . 3 56 4.1. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 3 57 4.2. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 3 58 4.3. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 4 59 4.4. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 4 60 4.5. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 4 61 5. New Elliptic Curve Diffie-Hellman Key Exchange methods . . . 4 62 5.1. Generic GSS-API Key Exchange with ECDH . . . . . . . . . 4 63 5.2. ECDH Key Exchange Methods . . . . . . . . . . . . . . . . 11 64 5.2.1. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . 12 65 5.2.2. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . 12 66 5.2.3. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . 12 67 5.2.4. gss-curve25519-sha256-* . . . . . . . . . . . . . . . 12 68 5.2.5. gss-curve448-sha512-* . . . . . . . . . . . . . . . . 13 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7.1. New Finite Field DH mechanisms . . . . . . . . . . . . . 13 72 7.2. New Elliptic Curve DH mechanisms . . . . . . . . . . . . 13 73 7.3. GSSAPI Delegation . . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for 82 authentication and key exchange in SSH. It defines three exchange 83 methods all based on DH groups and SHA-1. This document updates 84 RFC4462 with new methods intended to support environments that desire 85 to use the SHA-2 cryptographic hash functions. 87 2. Rationale 89 Due to security concerns with SHA-1 [RFC6194] and with MODP groups 90 with less than 2048 bits [NIST-SP-800-131Ar1] we propose the use of 91 the SHA-2 based hashes with DH group14, group15, group16, group17 and 92 group18 [RFC3526]. Additionally we add support for key exchange 93 based on Elliptic Curve Diffie Hellman with NIST P-256, P-384 and 94 P-521 as well as X25519 and X448 curves. Following the rationale of 95 [RFC8268] only SHA-256 and SHA-512 hashes are used for DH groups. 96 For NIST curves the same curve-to-hashing algorithm pairing used in 97 [RFC5656] is adopted for consistency. 99 3. Document Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 4. New Diffie-Hellman Key Exchange methods 107 This document adopts the same naming convention defined in [RFC4462] 108 to define families of methods that cover any GSS-API mechanism used 109 with a specific Diffie-Hellman group and SHA-2 Hash combination. 111 The following new key exchange algorithms are defined: 113 +--------------------------+--------------------------------+ 114 | Key Exchange Method Name | Implementation Recommendations | 115 +--------------------------+--------------------------------+ 116 | gss-group14-sha256-* | SHOULD/RECOMMENDED | 117 | gss-group15-sha512-* | MAY/OPTIONAL | 118 | gss-group16-sha512-* | SHOULD/RECOMMENDED | 119 | gss-group17-sha512-* | MAY/OPTIONAL | 120 | gss-group18-sha512-* | MAY/OPTIONAL | 121 +--------------------------+--------------------------------+ 123 Each key exchange method is implicitly registered by this document. 124 The IESG is considered to be the owner of all these key exchange 125 methods; this does NOT imply that the IESG is considered to be the 126 owner of the underlying GSS-API mechanism. 128 4.1. gss-group14-sha256-* 130 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 131 key exchange as described in Section 2.1 of [RFC4462] with SHA-256 132 as HASH, and the group defined in Section 8.2 of [RFC4253] The method 133 name for each method is the concatenation of the string "gss- 134 group14-sha256-" with the Base64 encoding of the MD5 hash [RFC1321] 135 of the ASN.1 DER encoding [ISO-IEC-8825-1] of the underlying GSS-API 136 mechanism's OID. Base64 encoding is described in Section 6.8 of 137 [RFC2045]. 139 4.2. gss-group15-sha512-* 141 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 142 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 143 as HASH, and the group defined in Section 4 of [RFC3526] The method 144 name for each method is the concatenation of the string "gss- 145 group15-sha512-" with the Base64 encoding of the MD5 hash of the 146 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 148 4.3. gss-group16-sha512-* 150 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 151 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 152 as HASH, and the group defined in Section 5 of [RFC3526] The method 153 name for each method is the concatenation of the string "gss- 154 group16-sha512-" with the Base64 encoding of the MD5 hash of the 155 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 157 4.4. gss-group17-sha512-* 159 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 160 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 161 as HASH, and the group defined in Section 6 of [RFC3526] The method 162 name for each method is the concatenation of the string "gss- 163 group17-sha512-" with the Base64 encoding of the MD5 hash of the 164 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 166 4.5. gss-group18-sha512-* 168 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 169 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 170 as HASH, and the group defined in Section 7 of [RFC3526] The method 171 name for each method is the concatenation of the string "gss- 172 group18-sha512-" with the Base64 encoding of the MD5 hash of the 173 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 175 5. New Elliptic Curve Diffie-Hellman Key Exchange methods 177 In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve 178 Cryptography are introduced. We reuse much of section 4 to implement 179 GSS-API-authenticated ECDH Key Exchanges. 181 Additionally we utilize also the curves defined in 182 [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined 183 curves required by [RFC5656]. 185 5.1. Generic GSS-API Key Exchange with ECDH 187 This section reuses much of the scheme defined in Section 2.1 of 188 [RFC4462] and combines it with the scheme defined in Section 4 of 189 [RFC5656]; in particular, all checks and verification steps 190 prescribed in Section 4 of [RFC5656] apply here as well. 192 The symbols used in this description conform to the symbols used in 193 Section 2.1 of [RFC4462]. Additionally, the following symbols are 194 defined: 196 Q_C is the client ephemeral public key octet string 198 Q_S is the server ephemeral public key octet string 200 This section defers to [RFC7546] as the source of information on GSS- 201 API context establishment operations, Section 3 being the most 202 relevant. All Security Considerations described in [RFC7546] apply 203 here too. 205 The Client: 207 1. C generates an ephemeral key pair with public key Q_C. It does 208 that by: 210 For NIST curves: 212 Selecting a value d_C uniformly at random from the interval [1, 213 n-1] where n is the order of generator of the curve associated 214 with the selected key exchange method. 216 Performing point multiplication between the curve base point 217 and selected integer d_C to get the public point q_C. 219 Converts the point q_C to the Q_C octet string by concatenation 220 of value 0x04 and big-endian representation of the x coordinate 221 and then y coordinate. The coordinate coversion MUST preserve 222 leading zero octets. Thus for nistp521 curve the encoded x 223 coordinate will always have a length of 66 octets while the Q_C 224 representation will be 133 octets long. This is the 225 uncompressed representation specified in Section 4.3.6 of 226 [ANSI-X9-62-2005]. 228 For curve25519 and curve448: 230 Selecting d_C as 32 uniformly distributed random octets for 231 curve25519 and 56 octets for curve448. 233 Preparing the generator g as the number 9 little-endian encoded 234 in 32 octets for curve25519 and number 5 in 56 octets for 235 curve448. This is the same as an octet of value 0x09 followed 236 by 31 zero octets for curve255519 and as an octect of value 237 0x05 followed by 55 zero octets. 239 Calculating Q_C as the result of the call to X25519 or X448 240 function, respectively for curve25519 and curve448 key 241 exchange, with parameters d_C and g. 243 2. C calls GSS_Init_sec_context(), using the most recent reply token 244 received from S during this exchange, if any. For this call, the 245 client MUST set mutual_req_flag to "true" to request that mutual 246 authentication be performed. It also MUST set integ_req_flag to 247 "true" to request that per-message integrity protection be supported 248 for this context. In addition, deleg_req_flag MAY be set to "true" 249 to request access delegation, if requested by the user. Since the 250 key exchange process authenticates only the host, the setting of 251 anon_req_flag is immaterial to this process. If the client does not 252 support the "gssapi-keyex" user authentication method described in 253 Section 4 of [RFC4462], or does not intend to use that method in 254 conjunction with the GSS-API context established during key exchange, 255 then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY 256 be set to true if the client wishes to hide its identity. Since the 257 key exchange process will involve the exchange of only a single token 258 once the context has been established, it is not necessary that the 259 GSS-API context support detection of replayed or out-of-sequence 260 tokens. Thus, replay_det_req_flag and sequence_req_flag need not be 261 set for this process. These flags SHOULD be set to "false". 263 If the resulting major_status code is GSS_S_COMPLETE and the 264 mutual_state flag is not true, then mutual authentication has not 265 been established, and the key exchange MUST fail. 267 If the resulting major_status code is GSS_S_COMPLETE and the 268 integ_avail flag is not true, then per-message integrity 269 protection is not available, and the key exchange MUST fail. 271 If the resulting major_status code is GSS_S_COMPLETE and both the 272 mutual_state and integ_avail flags are true, the resulting output 273 token is sent to S. 275 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the 276 output_token is sent to S, which will reply with a new token to be 277 provided to GSS_Init_sec_context(). 279 The client MUST also include Q_C with the first message it sends 280 to the server during this process; if the server receives more 281 than one Q_C or none at all, the key exchange MUST fail. 283 It is an error if the call does not produce a token of non-zero 284 length to be sent to the server. In this case, the key exchange 285 MUST fail. 287 3. When a Q_C key is received, S verifies that the key is valid. If 288 the key is not valid the key exchange MUST fail. 290 The server first checks if the length of the Q_C matches the 291 selected key exchange: 65 octets for nistp256, 97 octets for 292 nistp384, 133 octets for nistp521, 32 octets for curve25519 or 56 293 octets for curve448. If the value does not have matching length 294 the key exchange MUST fail. 296 In case of key exchanges that use NIST curves, the server MUST 297 check if the first octet of the Q_C is equal to 0x04. If the 298 octet has different value the key exchange MUST fail. 300 For NIST curves, the server converts the octet representation of 301 the key to q_C point representation by interpreting the first half 302 of remaining octets as the unsigned big-endian representation of 303 the x coordinate of the point and the second half as the unsigned 304 big-endian representation of the y coordinate. 306 For NIST curves, the server verifies that the q_C is not a point 307 at infinity, that both coordinates are in the interval [0, p - 1], 308 where p is the prime associated with the curve of the selected key 309 exchange and that the point lies on the curve (satisfies the curve 310 equation). 312 For curve25519, the server verifies that the the high-order bit of 313 the last octet is not set - this prevents distinguishing attacks 314 between implementations that use Montgomery ladder implementation 315 of the curve and ones that use generic elliptic-curve libraries. 316 If the bit is set, the key exchange SHOULD fail. For curve448 any 317 bit can be set. 319 For curve25519 and curve448, the point is not decoded but used as 320 is. Q_C and q_C are considered equivalent. 322 4. S calls GSS_Accept_sec_context(), using the token received from 323 C. 325 If the resulting major_status code is GSS_S_COMPLETE and the 326 mutual_state flag is not true, then mutual authentication has not 327 been established, and the key exchange MUST fail. 329 If the resulting major_status code is GSS_S_COMPLETE and the 330 integ_avail flag is not true, then per-message integrity 331 protection is not available, and the key exchange MUST fail. 333 If the resulting major_status code is GSS_S_COMPLETE and both the 334 mutual_state and integ_avail flags are true, then the security 335 context has been established, and processing continues with step 336 5. 338 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, then 339 the output token is sent to C, and processing continues with step 340 2. 342 If the resulting major_status code is GSS_S_COMPLETE, but a non- 343 zero-length reply token is returned, then that token is sent to 344 the client. 346 5. S generates an ephemeral key pair with public key Q_S calculated 347 the same way it is done in step 1 and peforms the following 348 computations: 350 K a shared secret obtained using ECDH key exchange: 352 Both client and server perform the same calculation where d_U 353 is the secret value, d_C for client and d_S for server and q_V 354 is the received public value, q_S for client and q_C for 355 server. 357 For NIST curves, the peers perform point multiplication using 358 d_U and q_V to get point P. 360 For NIST curves, peers verify that P is not a point at 361 infinity. If P is a point at infinity, the key exchange MUST 362 fail. 364 For NIST curves, the shared secret is the zero-padded big- 365 endian representation of the x coordinate of P - 32 octets long 366 for nistp256, 48 octets for nistp384 and 64 octets long for 367 nistp521. 369 For curve25519 and curve448, the peers apply the X25519 or X448 370 function, respectively for curve25519 and curve448, on the d_U 371 and q_V. The result of the function is the shared secret. 373 For curve25519 and curve448, if all the octets of the shared 374 secret are zero octets, the key exchange MUST fail. 376 H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). 378 MIC is the GSS-API message integrity code for H computed by 379 calling GSS_GetMIC(). 381 S then sends Q_S and the message integrity code (MIC) to C. 383 6. This step is performed only if the server's final call to 384 GSS_Accept_sec_context() produced a non-zero-length final reply token 385 to be sent to the client and if no previous call by the client to 386 GSS_Init_sec_context() has resulted in a major_status of 387 GSS_S_COMPLETE. Under these conditions, the client makes an 388 additional call to GSS_Init_sec_context() to process the final reply 389 token. This call is made exactly as described above. However, if 390 the resulting major_status is anything other than GSS_S_COMPLETE, or 391 a non-zero-length token is returned, it is an error and the key 392 exchange MUST fail. 394 7. C verifies that the key Q_S is valid the same way it is done in 395 step 3. If the key is not valid the key exchange MUST fail. 397 8. C computes the shared secret K and H and verifies that it is 398 valid the same way it is done in step 5. It then calls 399 GSS_VerifyMIC() to check that the MIC sent by S verifies H's 400 integrity. If the MIC is not successfully verified, the key exchange 401 MUST fail. 403 If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a 404 major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or 405 any other GSS-API call returns a major_status other than 406 GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations 407 expressed in Section 2.1 of [RFC4462] are followed with regards to 408 error reporting. 410 This exchange is implemented with the following messages: 412 The client sends: 414 byte SSH_MSG_KEXGSS_INIT 415 string output_token (from GSS_Init_sec_context()) 416 string Q_C, client's ephemeral public key octet string 418 The server may responds with: 420 byte SSH_MSG_KEXGSS_HOSTKEY 421 string server public host key and certificates (K_S) 423 Since this key exchange method does not require the host key to be 424 used for any encryption operations, this message is OPTIONAL. If the 425 "null" host key algorithm described in Section 5 of [RFC4462] is 426 used, this message MUST NOT be sent. 428 Each time the server's call to GSS_Accept_sec_context() returns a 429 major_status code of GSS_S_CONTINUE_NEEDED 430 The server replies: 432 byte SSH_MSG_KEXGSS_CONTINUE 433 string output_token (from GSS_Accept_sec_context()) 435 If the client receives this message after a call to 436 GSS_Init_sec_context() has returned a major_status code of 437 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 438 MUST fail. 440 Each time the client receives the message described above, it makes 441 another call to GSS_Init_sec_context(). 443 The client sends: 445 byte SSH_MSG_KEXGSS_CONTINUE 446 string output_token (from GSS_Init_sec_context()) 448 The server and client continue to trade these two messages as long as 449 the server's calls to GSS_Accept_sec_context() result in major_status 450 codes of GSS_S_CONTINUE_NEEDED. When a call results in a 451 major_status code of GSS_S_COMPLETE, it sends one of two final 452 messages. 454 If the server's final call to GSS_Accept_sec_context() (resulting in 455 a major_status code of GSS_S_COMPLETE) returns a non-zero-length 456 token to be sent to the client, it sends the following: 458 byte SSH_MSG_KEXGSS_COMPLETE 459 string Q_S, server's ephemeral public key octet string 460 string mic_token (MIC of H) 461 boolean TRUE 462 string output_token (from GSS_Accept_sec_context()) 464 If the client receives this message after a call to 465 GSS_Init_sec_context() has returned a major_status code of 466 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 467 MUST fail. 469 If the server's final call to GSS_Accept_sec_context() (resulting in 470 a major_status code of GSS_S_COMPLETE) returns a zero-length token or 471 no token at all, it sends the following: 473 byte SSH_MSG_KEXGSS_COMPLETE 474 string Q_S, server's ephemeral public key octet string 475 string mic_token (MIC of H) 476 boolean FALSE 478 If the client receives this message when no call to 479 GSS_Init_sec_context() has yet resulted in a major_status code of 480 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 481 MUST fail. 483 In case of errors the messages described in Section 2.1 of [RFC4462] 484 are used as well as the recommendation about the messages' order. 486 The hash H is computed as the HASH hash of the concatenation of the 487 following: 489 string V_C, the client's version string (CR, NL excluded) 490 string V_S, server's version string (CR, NL excluded) 491 string I_C, payload of the client's SSH_MSG_KEXINIT 492 string I_S, payload of the server's SSH_MSG_KEXINIT 493 string K_S, server's public host key 494 string Q_C, client's ephemeral public key octet string 495 string Q_S, server's ephemeral public key octet string 496 mpint K, shared secret 498 This value is called the exchange hash, and it is used to 499 authenticate the key exchange. The exchange hash SHOULD be kept 500 secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 501 server or received by the client, then the empty string is used in 502 place of K_S when computing the exchange hash. 504 The GSS_GetMIC call MUST be applied over H, not the original data. 506 5.2. ECDH Key Exchange Methods 508 The following new key exchange methods are defined: 510 +--------------------------+--------------------------------+ 511 | Key Exchange Method Name | Implementation Recommendations | 512 +--------------------------+--------------------------------+ 513 | gss-nistp256-sha256-* | SHOULD/RECOMMENDED | 514 | gss-nistp384-sha384-* | MAY/OPTIONAL | 515 | gss-nistp521-sha512-* | MAY/OPTIONAL | 516 | gss-curve25519-sha256-* | SHOULD/RECOMMENDED | 517 | gss-curve448-sha512-* | MAY/OPTIONAL | 518 +--------------------------+--------------------------------+ 520 Each key exchange method is implicitly registered by this document. 521 The IESG is considered to be the owner of all these key exchange 522 methods; this does NOT imply that the IESG is considered to be the 523 owner of the underlying GSS-API mechanism. 525 5.2.1. gss-nistp256-sha256-* 527 Each of these methods specifies GSS-API-authenticated Elliptic Curve 528 Diffie-Hellman key exchange as described in Section 5.1 of this 529 document with SHA-256 as HASH, and the curve and base point defined 530 in section 2.4.2 of [SEC2v2] as secp256r1. The method name for each 531 method is the concatenation of the string "gss-nistp256-sha256-" with 532 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 533 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 534 Base64 encoding is described in Section 6.8 of [RFC2045]. 536 5.2.2. gss-nistp384-sha384-* 538 Each of these methods specifies GSS-API-authenticated Elliptic Curve 539 Diffie-Hellman key exchange as described in Section 5.1 of this 540 document with SHA-384 as HASH, and the curve and base point defined 541 in section 2.5.1 of [SEC2v2] as secp384r1. The method name for each 542 method is the concatenation of the string "gss-nistp384-sha384-" with 543 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 544 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 545 Base64 encoding is described in Section 6.8 of [RFC2045]. 547 5.2.3. gss-nistp521-sha512-* 549 Each of these methods specifies GSS-API-authenticated Elliptic Curve 550 Diffie-Hellman key exchange as described in Section 5.1 of this 551 document with SHA-512 as HASH, and the curve and base point defined 552 in section 2.6.1 of [SEC2v2] as secp521r1. The method name for each 553 method is the concatenation of the string "gss-nistp521-sha512-" with 554 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 555 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 556 Base64 encoding is described in Section 6.8 of [RFC2045]. 558 5.2.4. gss-curve25519-sha256-* 560 Each of these methods specifies GSS-API-authenticated Elliptic Curve 561 Diffie-Hellman key exchange as described in Section 5.1 of this 562 document with SHA-256 as HASH, and the X25519 function defined in 563 section 5 of [RFC7748]. The method name for each method is the 564 concatenation of the string "gss-curve25519-sha256-" with the Base64 565 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 566 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 567 encoding is described in Section 6.8 of [RFC2045]. 569 5.2.5. gss-curve448-sha512-* 571 Each of these methods specifies GSS-API-authenticated Elliptic Curve 572 Diffie-Hellman key exchange as described in Section 5.1 of this 573 document with SHA-512 as HASH, and the X448 function defined in 574 section 5 of [RFC7748]. The method name for each method is the 575 concatenation of the string "gss-curve448-sha512-" with the Base64 576 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 577 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 578 encoding is described in Section 6.8 of [RFC2045]. 580 6. IANA Considerations 582 This document augments the SSH Key Exchange Method Names in 583 [RFC4462]. 585 IANA is requested to update the SSH Protocol Parameters 586 [IANA-KEX-NAMES] registry with the following entries: 588 +--------------------------+------------+------------------------+ 589 | Key Exchange Method Name | Reference | Implementation Support | 590 +--------------------------+------------+------------------------+ 591 | gss-group14-sha256-* | This draft | SHOULD | 592 | gss-group15-sha512-* | This draft | MAY | 593 | gss-group16-sha512-* | This draft | SHOULD | 594 | gss-group17-sha512-* | This draft | MAY | 595 | gss-group18-sha512-* | This draft | MAY | 596 | gss-nistp256-sha256-* | This draft | SHOULD | 597 | gss-nistp384-sha384-* | This draft | MAY | 598 | gss-nistp521-sha512-* | This draft | MAY | 599 | gss-curve25519-sha256-* | This draft | SHOULD | 600 | gss-curve448-sha512-* | This draft | MAY | 601 +--------------------------+------------+------------------------+ 603 7. Security Considerations 605 7.1. New Finite Field DH mechanisms 607 Except for the use of a different secure hash function and larger DH 608 groups, no significant changes has been made to the protocol 609 described by [RFC4462]; therefore all the original Security 610 Considerations apply. 612 7.2. New Elliptic Curve DH mechanisms 614 Although a new cryptographic primitive is used with these methods the 615 actual key exchange closely follows the key exchange defined in 617 [RFC5656]; therefore all the original Security Considerations as well 618 as those expressed in [RFC5656] apply. 620 7.3. GSSAPI Delegation 622 Some GSSAPI mechanisms can optionally delegate credentials to the 623 target host by setting the deleg_ret_flag. In this case extra care 624 must be taken to ensure that the acceptor being authenticated matches 625 the target the user intended. Some mechanisms implementations (like 626 commonly used krb5 libraries) may use insecure DNS resolution to 627 canonicalize the target name; in these cases spoofing a DNS response 628 that points to an attacker-controlled machine may results in the user 629 silently delegating credentials to the attacker, who can then 630 impersonate the user at will. 632 8. References 634 8.1. Normative References 636 [ANSI-X9-62-2005] 637 American National Standards Institute, "Public Key 638 Cryptography for the Financial Services Industry, The 639 Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI 640 Standard X9.62, 2005. 642 [I-D.ietf-curdle-ssh-curves] 643 Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 644 Shell (SSH) Key Exchange Method using Curve25519 and 645 Curve448", draft-ietf-curdle-ssh-curves-07 (work in 646 progress), January 2018. 648 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 649 DOI 10.17487/RFC1321, April 1992, 650 . 652 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 653 Extensions (MIME) Part One: Format of Internet Message 654 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 655 . 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, 660 . 662 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 663 Diffie-Hellman groups for Internet Key Exchange (IKE)", 664 RFC 3526, DOI 10.17487/RFC3526, May 2003, 665 . 667 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 668 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 669 January 2006, . 671 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 672 "Generic Security Service Application Program Interface 673 (GSS-API) Authentication and Key Exchange for the Secure 674 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 675 2006, . 677 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 678 Integration in the Secure Shell Transport Layer", 679 RFC 5656, DOI 10.17487/RFC5656, December 2009, 680 . 682 [RFC7546] Kaduk, B., "Structure of the Generic Security Service 683 (GSS) Negotiation Loop", RFC 7546, DOI 10.17487/RFC7546, 684 May 2015, . 686 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 687 for Security", RFC 7748, DOI 10.17487/RFC7748, January 688 2016, . 690 [SEC2v2] Certicom Research, "SEC 2: Recommended Elliptic Curve 691 Domain Parameters", Standards for Efficient 692 Cryptography SEC 2, 2010. 694 8.2. Informative References 696 [IANA-KEX-NAMES] 697 Internet Assigned Numbers Authority, "Secure Shell (SSH) 698 Protocol Parameters: Key Exchange Method Names", June 699 2005, . 702 [ISO-IEC-8825-1] 703 International Organization for Standardization / 704 International Electrotechnical Commission, "ASN.1 encoding 705 rules: Specification of Basic Encoding Rules (BER), 706 Canonical Encoding Rules (CER) and Distinguished Encoding 707 Rules (DER)", ISO/IEC 8825-1, November 2015, 708 . 711 [NIST-SP-800-131Ar1] 712 National Institute of Standards and Technology, 713 "Transitions: Recommendation for Transitioning of the Use 714 of Cryptographic Algorithms and Key Lengths", NIST Special 715 Publication 800-131A Revision 1, November 2015, 716 . 719 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 720 Considerations for the SHA-0 and SHA-1 Message-Digest 721 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 722 . 724 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 725 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 726 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 727 . 729 Authors' Addresses 731 Simo Sorce 732 Red Hat, Inc. 733 140 Broadway 734 24th Floor 735 New York, NY 10025 736 USA 738 Email: simo@redhat.com 740 Hubert Kario 741 Red Hat, Inc. 742 Purkynova 99/71 743 Brno 612 45 744 Czech Republic 746 Email: hkario@redhat.com