idnits 2.17.1 draft-ietf-curdle-gss-keyex-sha2-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4462]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 408 has weird spacing: '... string out...' == Line 414 has weird spacing: '... string ser...' == Line 427 has weird spacing: '... string out...' == Line 440 has weird spacing: '... string out...' == Line 454 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 (April 26, 2017) is 2554 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: 'FIPS-180-4' is defined on line 621, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI-X9-62-2005' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' == Outdated reference: A later version (-12) exists of draft-ietf-curdle-ssh-curves-04 == Outdated reference: A later version (-09) exists of draft-ietf-curdle-ssh-modp-dh-sha2-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-IEC-8825-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SP-800-131Ar1' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 6194 ** 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: 5 errors (**), 0 flaws (~~), 10 warnings (==), 8 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 April 26, 2017 6 Expires: October 28, 2017 8 GSS-API Key Exchange with SHA2 9 draft-ietf-curdle-gss-keyex-sha2-00 11 Abstract 13 This document specifies additions and amendments to SSH GSS-API 14 Methods [RFC4462]. It defines a new key exchange method that uses 15 SHA-2 for integrity and deprecates weak DH groups. The purpose of 16 this specification is to modernize the cryptographic primitives used 17 by GSS Key Exchanges. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 28, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 56 4. New Diffie-Hellman Key Exchange methods . . . . . . . . . . . 3 57 4.1. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 3 58 4.2. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 3 59 4.3. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 4 60 4.4. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 4 61 4.5. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 4 62 5. New Elliptic Curve Diffie-Hellman Key Exchange methods . . . 4 63 5.1. Generic GSS-API Key Exchange with ECDH . . . . . . . . . 4 64 5.2. ECDH Key Exchange Methods . . . . . . . . . . . . . . . . 11 65 5.2.1. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . 11 66 5.2.2. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . 12 67 5.2.3. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . 12 68 5.2.4. gss-curve25519-sha256-* . . . . . . . . . . . . . . . 12 69 5.2.5. gss-curve448-sha512-* . . . . . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7.1. New Finite Field DH mechanisms . . . . . . . . . . . . . 13 73 7.2. New Elliptic Curve DH mechanisms . . . . . . . . . . . . 13 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for 80 authentication and key exchange in SSH. It defines three exchange 81 methods all based on DH groups and SHA-1. The new methods described 82 in this document are intended to support environments that desire to 83 use the SHA-2 cryptographic hash functions. 85 2. Rationale 87 Due to security concerns with SHA-1 [RFC6194] and with MODP groups 88 with less than 2048 bits [NIST-SP-800-131Ar1] we propose the use of 89 the SHA-2 based hashes with DH group14, group15, group16, group17 and 90 group18 [RFC3526]. Additionally we add support for key exchange 91 based on Elliptic Curve Diffie Hellman with NIST P-256, P-384 and 92 P-521 as well as X25519 and X448 curves. Following the rationale of 93 [I-D.ietf-curdle-ssh-modp-dh-sha2] only SHA-256 and SHA-512 hashes 94 are used for DH groups. For NIST curves the same curve-to-hashing 95 algorithm pairing used in [RFC5656] is adopted for consistency. 97 3. Document Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 4. New Diffie-Hellman Key Exchange methods 105 This document adopts the same naming convention defined in [RFC4462] 106 to define families of methods that cover any GSS-API mechanism used 107 with a specific Diffie-Hellman group and SHA-2 Hash combination. 109 The following new key exchange algorithms are defined: 111 +--------------------------+--------------------------------+ 112 | Key Exchange Method Name | Implementation Recommendations | 113 +--------------------------+--------------------------------+ 114 | gss-group14-sha256-* | SHOULD/RECOMMENDED | 115 | gss-group15-sha512-* | MAY/OPTIONAL | 116 | gss-group16-sha512-* | SHOULD/RECOMMENDED | 117 | gss-group17-sha512-* | MAY/OPTIONAL | 118 | gss-group18-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 4.1. gss-group14-sha256-* 128 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 129 key exchange as described in Section 2.1 of [RFC4462] with SHA-256 as 130 HASH, and the group defined in Section 8.2 of [RFC4253] The method 131 name for each method is the concatenation of the string "gss- 132 group14-sha256-" with the Base64 encoding of the MD5 hash [RFC1321] 133 of the ASN.1 DER encoding [ISO-IEC-8825-1] of the underlying GSS-API 134 mechanism's OID. Base64 encoding is described in Section 6.8 of 135 [RFC2045]. 137 4.2. gss-group15-sha512-* 139 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 140 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 141 HASH, and the group defined in Section 4 of [RFC3526] The method name 142 for each method is the concatenation of the string "gss- 143 group15-sha512-" with the Base64 encoding of the MD5 hash of the 144 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 146 4.3. gss-group16-sha512-* 148 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 149 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 150 HASH, and the group defined in Section 5 of [RFC3526] The method name 151 for each method is the concatenation of the string "gss- 152 group16-sha512-" with the Base64 encoding of the MD5 hash of the 153 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 155 4.4. gss-group17-sha512-* 157 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 158 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 159 HASH, and the group defined in Section 6 of [RFC3526] The method name 160 for each method is the concatenation of the string "gss- 161 group17-sha512-" with the Base64 encoding of the MD5 hash of the 162 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 164 4.5. gss-group18-sha512-* 166 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 167 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 168 HASH, and the group defined in Section 7 of [RFC3526] The method name 169 for each method is the concatenation of the string "gss- 170 group18-sha512-" with the Base64 encoding of the MD5 hash of the 171 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 173 5. New Elliptic Curve Diffie-Hellman Key Exchange methods 175 In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve 176 Cryptography are introduced. We reuse much of section 4 to implement 177 GSS-API-authenticated ECDH Key Exchanges. 179 Additionally we utilize also the curves defined in 180 [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined 181 curves required by [RFC5656]. 183 5.1. Generic GSS-API Key Exchange with ECDH 185 This section reuses much of the scheme defined in Section 2.1 of 186 [RFC4462] and combines it with the scheme defined in Section 4 of 187 [RFC5656]; in particular, all checks and verification steps 188 prescribed in Section 4 of [RFC5656] apply here as well. 190 The symbols used in this description conform to the symbols used in 191 Section 2.1 of [RFC4462]. Additionally, the following symbols are 192 defined: 194 Q_C is the client ephemeral public key octet string 196 Q_S is the server ephemeral public key octet string 198 This section defers to [RFC7546] as the source of information on GSS- 199 API context establishment operations, Section 3 being the most 200 relevant. All Security Considerations described in [RFC7546] apply 201 here too. 203 The Client: 205 1. C generates an ephemeral key pair with public key Q_C. It does 206 that by: 208 For NIST curves: 210 Selecting a value d_C uniformly at random from the interval [1, 211 n-1] where n is the order of generator of the curve associated 212 with the selected key exchange method. 214 Performing point multiplication between the curve base point 215 and selected integer d_C to get the public point q_C. 217 Converts the point q_C to the Q_C octet string by concatenation 218 of value 0x04 and big-endian representation of the x coordinate 219 and then y coordinate. The coordinate coversion MUST preserve 220 leading zero octets. Thus for nistp521 curve the encoded x 221 coordinate will always have a length of 66 octets while the Q_C 222 representation will be 133 octets long. This is the 223 uncompressed representation specified in Section 4.3.6 of 224 [ANSI-X9-62-2005]. 226 For curve25519 and curve448: 228 Selecting d_C as 32 uniformly distributed random octets for 229 curve25519 and 56 octets for curve448. 231 Preparing the generator g as the number 9 little-endian encoded 232 in 32 octets for curve25519 and number 5 in 56 octets for 233 curve448. This is the same as an octet of value 0x09 followed 234 by 31 zero octets for curve255519 and as an octect of value 235 0x05 followed by 55 zero octets. 237 Calculating Q_C as the result of the call to X25519 or X448 238 function, respectively for curve25519 and curve448 key 239 exchange, with parameters d_C and g. 241 2. C calls GSS_Init_sec_context(), using the most recent reply token 242 received from S during this exchange, if any. For this call, the 243 client MUST set mutual_req_flag to "true" to request that mutual 244 authentication be performed. It also MUST set integ_req_flag to 245 "true" to request that per-message integrity protection be supported 246 for this context. In addition, deleg_req_flag MAY be set to "true" 247 to request access delegation, if requested by the user. Since the 248 key exchange process authenticates only the host, the setting of 249 anon_req_flag is immaterial to this process. If the client does not 250 support the "gssapi-keyex" user authentication method described in 251 Section 4 of [RFC4462], or does not intend to use that method in 252 conjunction with the GSS-API context established during key exchange, 253 then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY 254 be set to true if the client wishes to hide its identity. Since the 255 key exchange process will involve the exchange of only a single token 256 once the context has been established, it is not necessary that the 257 GSS-API context support detection of replayed or out-of-sequence 258 tokens. Thus, replay_det_req_flag and sequence_req_flag need not be 259 set for this process. These flags SHOULD be set to "false". 261 If the resulting major_status code is GSS_S_COMPLETE and the 262 mutual_state flag is not true, then mutual authentication has not 263 been established, and the key exchange MUST fail. 265 If the resulting major_status code is GSS_S_COMPLETE and the 266 integ_avail flag is not true, then per-message integrity 267 protection is not available, and the key exchange MUST fail. 269 If the resulting major_status code is GSS_S_COMPLETE and both the 270 mutual_state and integ_avail flags are true, the resulting output 271 token is sent to S. 273 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the 274 output_token is sent to S, which will reply with a new token to be 275 provided to GSS_Init_sec_context(). 277 The client MUST also include Q_C with the first message it sends 278 to the server during this process; if the server receives more 279 than one Q_C or none at all, the key exchange MUST fail. 281 It is an error if the call does not produce a token of non- zero 282 length to be sent to the server. In this case, the key exchange 283 MUST fail. 285 3. When a Q_C key is received, S verifies that the key is valid. If 286 the key is not valid the key exchange MUST fail. 288 The server first checks if the length of the Q_C matches the 289 selected key exchange: 65 octets for nistp256, 97 octets for 290 nistp384, 133 octets for nistp521, 32 octets for curve25519 or 56 291 octets for curve448. If the value does not have matching length 292 the key exchange MUST fail. 294 In case of key exchanges that use NIST curves, the server MUST 295 check if the first octet of the Q_C is equal to 0x04. If the 296 octet has different value the key exchange MUST fail. 298 For NIST curves, the server converts the octet representation of 299 the key to q_C point representation by interpreting the first half 300 of remaining octets as the unsigned big-endian representation of 301 the x coordinate of the point and the second half as the unsigned 302 big-endian representation of the y coordinate. 304 For NIST curves, the server verifies that the q_C is not a point 305 at infinity, that both coordinates are in the interval [0, p - 1], 306 where p is the prime associated with the curve of the selected key 307 exchange and that the point lies on the curve (satisfies the curve 308 equation). 310 For curve25519, the server verifies that the the high-order bit of 311 the last octet is not set - this prevents distinguishing attacks 312 between implementations that use Montgomery ladder implementation 313 of the curve and ones that use generic elliptic-curve libraries. 314 If the bit is set, the key exchange SHOULD fail. For curve448 any 315 bit can be set. 317 For curve25519 and curve448, the point is not decoded but used as 318 is. Q_C and q_C are considered equivalent. 320 4. S calls GSS_Accept_sec_context(), using the token received from 321 C. 323 If the resulting major_status code is GSS_S_COMPLETE and the 324 mutual_state flag is not true, then mutual authentication has not 325 been established, and the key exchange MUST fail. 327 If the resulting major_status code is GSS_S_COMPLETE and the 328 integ_avail flag is not true, then per-message integrity 329 protection is not available, and the key exchange MUST fail. 331 If the resulting major_status code is GSS_S_COMPLETE and both the 332 mutual_state and integ_avail flags are true, then the security 333 context has been established, and processing continues with step 334 5. 336 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, then 337 the output token is sent to C, and processing continues with step 338 2. 340 If the resulting major_status code is GSS_S_COMPLETE, but a non- 341 zero-length reply token is returned, then that token is sent to 342 the client. 344 5. S generates an ephemeral key pair with public key Q_S calculated 345 the same way it is done in step 1 and peforms the following 346 computations: 348 K a shared secret obtained using ECDH key exchange: 350 Both client and server perform the same calculation where d_U 351 is the secret value, d_C for client and d_S for server and q_V 352 is the received public value, q_S for client and q_C for 353 server. 355 For NIST curves, the peers perform point multiplication using 356 d_U and q_V to get point P. 358 For NIST curves, peers verify that P is not a point at 359 infinity. If P is a point at infinity, the key exchange MUST 360 fail. 362 For NIST curves, the shared secret is the zero-padded big- 363 endian representation of the x coordinate of P. 365 For curve25519 and curve448, the peers apply the X25519 or X448 366 function, respectively for curve25519 and curve448, on the d_U 367 and q_V. The result of the function is the shared secret. 369 For curve25519 and curve448, if all the octets of the shared 370 secret are zero octets, the key exchange MUST fail. 372 H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). 374 MIC is the GSS-API message integrity code for H computed by 375 calling GSS_GetMIC(). 377 6. This step is performed only if the server's final call to 378 GSS_Accept_sec_context() produced a non-zero-length final reply token 379 to be sent to the client and if no previous call by the client to 380 GSS_Init_sec_context() has resulted in a major_status of 381 GSS_S_COMPLETE. Under these conditions, the client makes an 382 additional call to GSS_Init_sec_context() to process the final reply 383 token. This call is made exactly as described above. However, if 384 the resulting major_status is anything other than GSS_S_COMPLETE, or 385 a non-zero-length token is returned, it is an error and the key 386 exchange MUST fail. 388 7. C verifies that the key Q_S is valid the same way it is done in 389 step 3. If the key is not valid the key exchange MUST fail. 391 8. C computes the shared secret K and H the same way it is done in 392 step 5. It then calls GSS_VerifyMIC() to check that the MIC sent by 393 S verifies H's integrity. If the MIC is not successfully verified, 394 the key exchange MUST fail. 396 If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a 397 major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or 398 any other GSS-API call returns a major_status other than 399 GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations 400 expressed in Section 2.1 of [RFC4462] are followed with regards to 401 error reporting. 403 This exchange is implemented with the following messages: 405 The client sends: 407 byte SSH_MSG_KEXGSS_INIT 408 string output_token (from GSS_Init_sec_context()) 409 string Q_C, client's ephemeral public key octet string 411 The server may responds with: 413 byte SSH_MSG_KEXGSS_HOSTKEY 414 string server public host key and certificates (K_S) 416 Since this key exchange method does not require the host key to be 417 used for any encryption operations, this message is OPTIONAL. If the 418 "null" host key algorithm described in Section 5 of [RFC4462] is 419 used, this message MUST NOT be sent. 421 Each time the server's call to GSS_Accept_sec_context() returns a 422 major_status code of GSS_S_CONTINUE_NEEDED 424 The server replies: 426 byte SSH_MSG_KEXGSS_CONTINUE 427 string output_token (from GSS_Accept_sec_context()) 429 If the client receives this message after a call to 430 GSS_Init_sec_context() has returned a major_status code of 431 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 432 MUST fail. 434 Each time the client receives the message described above, it makes 435 another call to GSS_Init_sec_context(). 437 The client sends: 439 byte SSH_MSG_KEXGSS_CONTINUE 440 string output_token (from GSS_Init_sec_context()) 442 The server and client continue to trade these two messages as long as 443 the server's calls to GSS_Accept_sec_context() result in major_status 444 codes of GSS_S_CONTINUE_NEEDED. When a call results in a 445 major_status code of GSS_S_COMPLETE, it sends one of two final 446 messages. 448 If the server's final call to GSS_Accept_sec_context() (resulting in 449 a major_status code of GSS_S_COMPLETE) returns a non-zero-length 450 token to be sent to the client, it sends the following: 452 byte SSH_MSG_KEXGSS_COMPLETE 453 string Q_S, server's ephemeral public key octet string 454 string mic_token (MIC of H) 455 boolean TRUE 456 string output_token (from GSS_Accept_sec_context()) 458 If the client receives this message after a call to 459 GSS_Init_sec_context() has returned a major_status code of 460 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 461 MUST fail. 463 If the server's final call to GSS_Accept_sec_context() (resulting in 464 a major_status code of GSS_S_COMPLETE) returns a zero-length token or 465 no token at all, it sends the following: 467 byte SSH_MSG_KEXGSS_COMPLETE 468 string Q_S, server's ephemeral public key octet string 469 string mic_token (MIC of H) 470 boolean FALSE 472 If the client receives this message when no call to 473 GSS_Init_sec_context() has yet resulted in a major_status code of 474 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 475 MUST fail. 477 In case of errors the messages described in Section 2.1 of [RFC4462] 478 are used as well as the recommendation about the messages' order. 480 The hash H is computed as the HASH hash of the concatenation of the 481 following: 483 string V_C, the client's version string (CR, NL excluded) 484 string V_S, server's identification string (CR and LF excluded) 485 string I_C, payload of the client's SSH_MSG_KEXINIT 486 string I_S, payload of the server's SSH_MSG_KEXINIT 487 string K_S, server's public host key 488 string Q_C, client's ephemeral public key octet string 489 string Q_S, server's ephemeral public key octet string 490 mpint K, shared secret 492 This value is called the exchange hash, and it is used to 493 authenticate the key exchange. The exchange hash SHOULD be kept 494 secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 495 server or received by the client, then the empty string is used in 496 place of K_S when computing the exchange hash. 498 The GSS_GetMIC call MUST be applied over H, not the original data. 500 5.2. ECDH Key Exchange Methods 502 The following new key exchange methods are defined: 504 +--------------------------+--------------------------------+ 505 | Key Exchange Method Name | Implementation Recommendations | 506 +--------------------------+--------------------------------+ 507 | gss-nistp256-sha256-* | SHOULD/RECOMMENDED | 508 | gss-nistp384-sha384-* | MAY/OPTIONAL | 509 | gss-nistp521-sha512-* | MAY/OPTIONAL | 510 | gss-curve25519-sha256-* | SHOULD/RECOMMENDED | 511 | gss-curve448-sha512-* | MAY/OPTIONAL | 512 +--------------------------+--------------------------------+ 514 Each key exchange method is implicitly registered by this document. 515 The IESG is considered to be the owner of all these key exchange 516 methods; this does NOT imply that the IESG is considered to be the 517 owner of the underlying GSS-API mechanism. 519 5.2.1. gss-nistp256-sha256-* 521 Each of these methods specifies GSS-API-authenticated Elliptic Curve 522 Diffie-Hellman key exchange as described in Section 5.1 of this 523 document with SHA-256 as HASH, and the curve and base point defined 524 in section 2.4.2 of [SEC2v2] as secp256r1. The method name for each 525 method is the concatenation of the string "gss-nistp256-sha256-" with 526 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 527 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 528 Base64 encoding is described in Section 6.8 of [RFC2045]. 530 5.2.2. gss-nistp384-sha384-* 532 Each of these methods specifies GSS-API-authenticated Elliptic Curve 533 Diffie-Hellman key exchange as described in Section 5.1 of this 534 document with SHA-384 as HASH, and the curve and base point defined 535 in section 2.5.1 of [SEC2v2] as secp384r1. The method name for each 536 method is the concatenation of the string "gss-nistp384-sha384-" with 537 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 538 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 539 Base64 encoding is described in Section 6.8 of [RFC2045]. 541 5.2.3. gss-nistp521-sha512-* 543 Each of these methods specifies GSS-API-authenticated Elliptic Curve 544 Diffie-Hellman key exchange as described in Section 5.1 of this 545 document with SHA-512 as HASH, and the curve and base point defined 546 in section 2.6.1 of [SEC2v2] as secp521r1. The method name for each 547 method is the concatenation of the string "gss-nistp521-sha512-" with 548 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 549 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 550 Base64 encoding is described in Section 6.8 of [RFC2045]. 552 5.2.4. gss-curve25519-sha256-* 554 Each of these methods specifies GSS-API-authenticated Elliptic Curve 555 Diffie-Hellman key exchange as described in Section 5.1 of this 556 document with SHA-256 as HASH, and the X25519 function defined in 557 section 5 of [RFC7748]. The method name for each method is the 558 concatenation of the string "gss-curve25519-sha256-" with the Base64 559 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 560 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 561 encoding is described in Section 6.8 of [RFC2045]. 563 5.2.5. gss-curve448-sha512-* 565 Each of these methods specifies GSS-API-authenticated Elliptic Curve 566 Diffie-Hellman key exchange as described in Section 5.1 of this 567 document with SHA-512 as HASH, and the X448 function defined in 568 section 5 of [RFC7748]. The method name for each method is the 569 concatenation of the string "gss-curve448-sha512-" with the Base64 570 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 571 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 572 encoding is described in Section 6.8 of [RFC2045]. 574 6. IANA Considerations 576 This document augments the SSH Key Exchange Method Names in 577 [RFC4462]. 579 IANA is requested to update the SSH algorithm registry with the 580 following entries: 582 +--------------------------+------------+------------------------+ 583 | Key Exchange Method Name | Reference | Implementation Support | 584 +--------------------------+------------+------------------------+ 585 | gss-group14-sha256-* | This draft | SHOULD | 586 | gss-group15-sha512-* | This draft | MAY | 587 | gss-group16-sha512-* | This draft | SHOULD | 588 | gss-group17-sha512-* | This draft | MAY | 589 | gss-group18-sha512-* | This draft | MAY | 590 | gss-nistp256-sha256-* | This draft | SHOULD | 591 | gss-nistp384-sha384-* | This draft | MAY | 592 | gss-nistp521-sha512-* | This draft | MAY | 593 | gss-curve25519-sha256-* | This draft | SHOULD | 594 | gss-curve448-sha512-* | This draft | MAY | 595 +--------------------------+------------+------------------------+ 597 7. Security Considerations 599 7.1. New Finite Field DH mechanisms 601 Except for the use of a different secure hash function and larger DH 602 groups, no significant changes has been made to the protocol 603 described by [RFC4462]; therefore all the original Security 604 Considerations apply. 606 7.2. New Elliptic Curve DH mechanisms 608 Although a new cryptographic primitive is used with these methods the 609 actual key exchange closely follows the key exchange defined in 610 [RFC5656]; therefore all the original Security Considerations as well 611 as those expressed in [RFC5656] apply. 613 8. Normative References 615 [ANSI-X9-62-2005] 616 American National Standards Institute, "Public Key 617 Cryptography for the Financial Services Industry, The 618 Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI 619 Standard X9.62, 2005. 621 [FIPS-180-4] 622 National Institute of Standards and Technology, "FIPS PUB 623 180-4: Secure Hash Standard (SHS)", FIPS PUB 180-4, August 624 2015, . 627 [I-D.ietf-curdle-ssh-curves] 628 Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 629 Shell (SSH) Key Exchange Method using Curve25519 and 630 Curve448", draft-ietf-curdle-ssh-curves-04 (work in 631 progress), April 2017. 633 [I-D.ietf-curdle-ssh-modp-dh-sha2] 634 Baushke, M., "More Modular Exponential (MODP) Diffie- 635 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 636 (SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-04 (work in 637 progress), April 2017. 639 [ISO-IEC-8825-1] 640 International Organization for Standardization / 641 International Electrotechnical Commission, "ASN.1 encoding 642 rules: Specification of Basic Encoding Rules (BER), 643 Canonical Encoding Rules (CER) and Distinguished Encoding 644 Rules (DER)", ISO/IEC 8825-1, November 2015, 645 . 648 [NIST-SP-800-131Ar1] 649 National Institute of Standards and Technology, 650 "Transitions: Recommendation for Transitioning of the Use 651 of Cryptographic Algorithms and Key Lengths", NIST Special 652 Publication 800-131A Revision 1, November 2015, 653 . 656 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 657 DOI 10.17487/RFC1321, April 1992, 658 . 660 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 661 Extensions (MIME) Part One: Format of Internet Message 662 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 663 . 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, 667 DOI 10.17487/RFC2119, March 1997, 668 . 670 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 671 Diffie-Hellman groups for Internet Key Exchange (IKE)", 672 RFC 3526, DOI 10.17487/RFC3526, May 2003, 673 . 675 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 676 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 677 January 2006, . 679 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 680 "Generic Security Service Application Program Interface 681 (GSS-API) Authentication and Key Exchange for the Secure 682 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 683 2006, . 685 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 686 Integration in the Secure Shell Transport Layer", 687 RFC 5656, DOI 10.17487/RFC5656, December 2009, 688 . 690 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 691 Considerations for the SHA-0 and SHA-1 Message-Digest 692 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 693 . 695 [RFC7546] Kaduk, B., "Structure of the Generic Security Service 696 (GSS) Negotiation Loop", RFC 7546, DOI 10.17487/RFC7546, 697 May 2015, . 699 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 700 for Security", RFC 7748, DOI 10.17487/RFC7748, January 701 2016, . 703 [SEC2v2] Certicom Research, "SEC 2: Recommended Elliptic Curve 704 Domain Parameters", Standards for Efficient 705 Cryptography SEC 2, 2010. 707 Authors' Addresses 709 Simo Sorce 710 Red Hat, Inc. 711 140 Broadway 712 24th Floor 713 New York, NY 10025 714 USA 716 Email: simo@redhat.com 717 Hubert Kario 718 Red Hat, Inc. 719 Purkynova 99/71 720 Brno 612 45 721 Czech Republic 723 Email: hkario@redhat.com