idnits 2.17.1 draft-ietf-curdle-gss-keyex-sha2-04.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 413 has weird spacing: '... string out...' == Line 419 has weird spacing: '... string ser...' == Line 431 has weird spacing: '... string out...' == Line 444 has weird spacing: '... string out...' == Line 458 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 (January 22, 2018) is 2286 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 January 22, 2018 6 Expires: July 26, 2018 8 GSS-API Key Exchange with SHA2 9 draft-ietf-curdle-gss-keyex-sha2-04 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 July 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. The new methods described 84 in this document are intended to support environments that desire to 85 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 as 132 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 as 143 HASH, and the group defined in Section 4 of [RFC3526] The method name 144 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 as 152 HASH, and the group defined in Section 5 of [RFC3526] The method name 153 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 as 161 HASH, and the group defined in Section 6 of [RFC3526] The method name 162 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 as 170 HASH, and the group defined in Section 7 of [RFC3526] The method name 171 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. 367 For curve25519 and curve448, the peers apply the X25519 or X448 368 function, respectively for curve25519 and curve448, on the d_U 369 and q_V. The result of the function is the shared secret. 371 For curve25519 and curve448, if all the octets of the shared 372 secret are zero octets, the key exchange MUST fail. 374 H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). 376 MIC is the GSS-API message integrity code for H computed by 377 calling GSS_GetMIC(). 379 S then sends Q_S and the message integrity code (MIC) to C. 381 6. This step is performed only if the server's final call to 382 GSS_Accept_sec_context() produced a non-zero-length final reply token 383 to be sent to the client and if no previous call by the client to 384 GSS_Init_sec_context() has resulted in a major_status of 385 GSS_S_COMPLETE. Under these conditions, the client makes an 386 additional call to GSS_Init_sec_context() to process the final reply 387 token. This call is made exactly as described above. However, if 388 the resulting major_status is anything other than GSS_S_COMPLETE, or 389 a non-zero-length token is returned, it is an error and the key 390 exchange MUST fail. 392 7. C verifies that the key Q_S is valid the same way it is done in 393 step 3. If the key is not valid the key exchange MUST fail. 395 8. C computes the shared secret K and H and verifies that it is 396 valid the same way it is done in step 5. It then calls 397 GSS_VerifyMIC() to check that the MIC sent by S verifies H's 398 integrity. If the MIC is not successfully verified, the key exchange 399 MUST fail. 401 If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a 402 major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or 403 any other GSS-API call returns a major_status other than 404 GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations 405 expressed in Section 2.1 of [RFC4462] are followed with regards to 406 error reporting. 408 This exchange is implemented with the following messages: 410 The client sends: 412 byte SSH_MSG_KEXGSS_INIT 413 string output_token (from GSS_Init_sec_context()) 414 string Q_C, client's ephemeral public key octet string 416 The server may responds with: 418 byte SSH_MSG_KEXGSS_HOSTKEY 419 string server public host key and certificates (K_S) 421 Since this key exchange method does not require the host key to be 422 used for any encryption operations, this message is OPTIONAL. If the 423 "null" host key algorithm described in Section 5 of [RFC4462] is 424 used, this message MUST NOT be sent. 426 Each time the server's call to GSS_Accept_sec_context() returns a 427 major_status code of GSS_S_CONTINUE_NEEDED 428 The server replies: 430 byte SSH_MSG_KEXGSS_CONTINUE 431 string output_token (from GSS_Accept_sec_context()) 433 If the client receives this message after a call to 434 GSS_Init_sec_context() has returned a major_status code of 435 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 436 MUST fail. 438 Each time the client receives the message described above, it makes 439 another call to GSS_Init_sec_context(). 441 The client sends: 443 byte SSH_MSG_KEXGSS_CONTINUE 444 string output_token (from GSS_Init_sec_context()) 446 The server and client continue to trade these two messages as long as 447 the server's calls to GSS_Accept_sec_context() result in major_status 448 codes of GSS_S_CONTINUE_NEEDED. When a call results in a 449 major_status code of GSS_S_COMPLETE, it sends one of two final 450 messages. 452 If the server's final call to GSS_Accept_sec_context() (resulting in 453 a major_status code of GSS_S_COMPLETE) returns a non-zero-length 454 token to be sent to the client, it sends the following: 456 byte SSH_MSG_KEXGSS_COMPLETE 457 string Q_S, server's ephemeral public key octet string 458 string mic_token (MIC of H) 459 boolean TRUE 460 string output_token (from GSS_Accept_sec_context()) 462 If the client receives this message after a call to 463 GSS_Init_sec_context() has returned a major_status code of 464 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 465 MUST fail. 467 If the server's final call to GSS_Accept_sec_context() (resulting in 468 a major_status code of GSS_S_COMPLETE) returns a zero-length token or 469 no token at all, it sends the following: 471 byte SSH_MSG_KEXGSS_COMPLETE 472 string Q_S, server's ephemeral public key octet string 473 string mic_token (MIC of H) 474 boolean FALSE 476 If the client receives this message when no call to 477 GSS_Init_sec_context() has yet resulted in a major_status code of 478 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 479 MUST fail. 481 In case of errors the messages described in Section 2.1 of [RFC4462] 482 are used as well as the recommendation about the messages' order. 484 The hash H is computed as the HASH hash of the concatenation of the 485 following: 487 string V_C, the client's version string (CR, NL excluded) 488 string V_S, server's version string (CR, NL excluded) 489 string I_C, payload of the client's SSH_MSG_KEXINIT 490 string I_S, payload of the server's SSH_MSG_KEXINIT 491 string K_S, server's public host key 492 string Q_C, client's ephemeral public key octet string 493 string Q_S, server's ephemeral public key octet string 494 mpint K, shared secret 496 This value is called the exchange hash, and it is used to 497 authenticate the key exchange. The exchange hash SHOULD be kept 498 secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 499 server or received by the client, then the empty string is used in 500 place of K_S when computing the exchange hash. 502 The GSS_GetMIC call MUST be applied over H, not the original data. 504 5.2. ECDH Key Exchange Methods 506 The following new key exchange methods are defined: 508 +--------------------------+--------------------------------+ 509 | Key Exchange Method Name | Implementation Recommendations | 510 +--------------------------+--------------------------------+ 511 | gss-nistp256-sha256-* | SHOULD/RECOMMENDED | 512 | gss-nistp384-sha384-* | MAY/OPTIONAL | 513 | gss-nistp521-sha512-* | MAY/OPTIONAL | 514 | gss-curve25519-sha256-* | SHOULD/RECOMMENDED | 515 | gss-curve448-sha512-* | MAY/OPTIONAL | 516 +--------------------------+--------------------------------+ 518 Each key exchange method is implicitly registered by this document. 519 The IESG is considered to be the owner of all these key exchange 520 methods; this does NOT imply that the IESG is considered to be the 521 owner of the underlying GSS-API mechanism. 523 5.2.1. gss-nistp256-sha256-* 525 Each of these methods specifies GSS-API-authenticated Elliptic Curve 526 Diffie-Hellman key exchange as described in Section 5.1 of this 527 document with SHA-256 as HASH, and the curve and base point defined 528 in section 2.4.2 of [SEC2v2] as secp256r1. The method name for each 529 method is the concatenation of the string "gss-nistp256-sha256-" with 530 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 531 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 532 Base64 encoding is described in Section 6.8 of [RFC2045]. 534 5.2.2. gss-nistp384-sha384-* 536 Each of these methods specifies GSS-API-authenticated Elliptic Curve 537 Diffie-Hellman key exchange as described in Section 5.1 of this 538 document with SHA-384 as HASH, and the curve and base point defined 539 in section 2.5.1 of [SEC2v2] as secp384r1. The method name for each 540 method is the concatenation of the string "gss-nistp384-sha384-" with 541 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 542 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 543 Base64 encoding is described in Section 6.8 of [RFC2045]. 545 5.2.3. gss-nistp521-sha512-* 547 Each of these methods specifies GSS-API-authenticated Elliptic Curve 548 Diffie-Hellman key exchange as described in Section 5.1 of this 549 document with SHA-512 as HASH, and the curve and base point defined 550 in section 2.6.1 of [SEC2v2] as secp521r1. The method name for each 551 method is the concatenation of the string "gss-nistp521-sha512-" with 552 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 553 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 554 Base64 encoding is described in Section 6.8 of [RFC2045]. 556 5.2.4. gss-curve25519-sha256-* 558 Each of these methods specifies GSS-API-authenticated Elliptic Curve 559 Diffie-Hellman key exchange as described in Section 5.1 of this 560 document with SHA-256 as HASH, and the X25519 function defined in 561 section 5 of [RFC7748]. The method name for each method is the 562 concatenation of the string "gss-curve25519-sha256-" with the Base64 563 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 564 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 565 encoding is described in Section 6.8 of [RFC2045]. 567 5.2.5. gss-curve448-sha512-* 569 Each of these methods specifies GSS-API-authenticated Elliptic Curve 570 Diffie-Hellman key exchange as described in Section 5.1 of this 571 document with SHA-512 as HASH, and the X448 function defined in 572 section 5 of [RFC7748]. The method name for each method is the 573 concatenation of the string "gss-curve448-sha512-" with the Base64 574 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 575 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 576 encoding is described in Section 6.8 of [RFC2045]. 578 6. IANA Considerations 580 This document augments the SSH Key Exchange Method Names in 581 [RFC4462]. 583 IANA is requested to update the SSH algorithm registry with the 584 following entries: 586 +--------------------------+------------+------------------------+ 587 | Key Exchange Method Name | Reference | Implementation Support | 588 +--------------------------+------------+------------------------+ 589 | gss-group14-sha256-* | This draft | SHOULD | 590 | gss-group15-sha512-* | This draft | MAY | 591 | gss-group16-sha512-* | This draft | SHOULD | 592 | gss-group17-sha512-* | This draft | MAY | 593 | gss-group18-sha512-* | This draft | MAY | 594 | gss-nistp256-sha256-* | This draft | SHOULD | 595 | gss-nistp384-sha384-* | This draft | MAY | 596 | gss-nistp521-sha512-* | This draft | MAY | 597 | gss-curve25519-sha256-* | This draft | SHOULD | 598 | gss-curve448-sha512-* | This draft | MAY | 599 +--------------------------+------------+------------------------+ 601 7. Security Considerations 603 7.1. New Finite Field DH mechanisms 605 Except for the use of a different secure hash function and larger DH 606 groups, no significant changes has been made to the protocol 607 described by [RFC4462]; therefore all the original Security 608 Considerations apply. 610 7.2. New Elliptic Curve DH mechanisms 612 Although a new cryptographic primitive is used with these methods the 613 actual key exchange closely follows the key exchange defined in 615 [RFC5656]; therefore all the original Security Considerations as well 616 as those expressed in [RFC5656] apply. 618 7.3. GSSAPI Delegation 620 Some GSSAPI mechanisms can optionally delegate credentials to the 621 target host by setting the deleg_ret_flag. In this case extra care 622 must be taken to ensure that the acceptor being authenticated matches 623 the target the user intended. Some mechanisms implementations (like 624 commonly used krb5 libraries) may use insecure DNS resolution to 625 canonicalize the target name; in these cases spoofing a DNS response 626 that points to an attacker-controlled machine may results in the user 627 silently delegating credentials to the attacker, who can then 628 impersonate the user at will. 630 8. References 632 8.1. Normative References 634 [ANSI-X9-62-2005] 635 American National Standards Institute, "Public Key 636 Cryptography for the Financial Services Industry, The 637 Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI 638 Standard X9.62, 2005. 640 [I-D.ietf-curdle-ssh-curves] 641 Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 642 Shell (SSH) Key Exchange Method using Curve25519 and 643 Curve448", draft-ietf-curdle-ssh-curves-07 (work in 644 progress), January 2018. 646 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 647 DOI 10.17487/RFC1321, April 1992, 648 . 650 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 651 Extensions (MIME) Part One: Format of Internet Message 652 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 653 . 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, 657 DOI 10.17487/RFC2119, March 1997, 658 . 660 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 661 Diffie-Hellman groups for Internet Key Exchange (IKE)", 662 RFC 3526, DOI 10.17487/RFC3526, May 2003, 663 . 665 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 666 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 667 January 2006, . 669 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 670 "Generic Security Service Application Program Interface 671 (GSS-API) Authentication and Key Exchange for the Secure 672 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 673 2006, . 675 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 676 Integration in the Secure Shell Transport Layer", 677 RFC 5656, DOI 10.17487/RFC5656, December 2009, 678 . 680 [RFC7546] Kaduk, B., "Structure of the Generic Security Service 681 (GSS) Negotiation Loop", RFC 7546, DOI 10.17487/RFC7546, 682 May 2015, . 684 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 685 for Security", RFC 7748, DOI 10.17487/RFC7748, January 686 2016, . 688 [SEC2v2] Certicom Research, "SEC 2: Recommended Elliptic Curve 689 Domain Parameters", Standards for Efficient 690 Cryptography SEC 2, 2010. 692 8.2. Informative References 694 [ISO-IEC-8825-1] 695 International Organization for Standardization / 696 International Electrotechnical Commission, "ASN.1 encoding 697 rules: Specification of Basic Encoding Rules (BER), 698 Canonical Encoding Rules (CER) and Distinguished Encoding 699 Rules (DER)", ISO/IEC 8825-1, November 2015, 700 . 703 [NIST-SP-800-131Ar1] 704 National Institute of Standards and Technology, 705 "Transitions: Recommendation for Transitioning of the Use 706 of Cryptographic Algorithms and Key Lengths", NIST Special 707 Publication 800-131A Revision 1, November 2015, 708 . 711 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 712 Considerations for the SHA-0 and SHA-1 Message-Digest 713 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 714 . 716 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 717 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 718 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 719 . 721 Authors' Addresses 723 Simo Sorce 724 Red Hat, Inc. 725 140 Broadway 726 24th Floor 727 New York, NY 10025 728 USA 730 Email: simo@redhat.com 732 Hubert Kario 733 Red Hat, Inc. 734 Purkynova 99/71 735 Brno 612 45 736 Czech Republic 738 Email: hkario@redhat.com