idnits 2.17.1 draft-ietf-curdle-gss-keyex-sha2-03.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 412 has weird spacing: '... string out...' == Line 418 has weird spacing: '... string ser...' == Line 430 has weird spacing: '... string out...' == Line 443 has weird spacing: '... string out...' == Line 457 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 (December 12, 2017) is 2326 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 637, 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 December 12, 2017 6 Expires: June 15, 2018 8 GSS-API Key Exchange with SHA2 9 draft-ietf-curdle-gss-keyex-sha2-03 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 https://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 June 15, 2018. 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 (https://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-* . . . . . . . . . . . . . . . . 12 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-* . . . . . . . . . . . . . . . . 13 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 7.3. GSSAPI Delegation . . . . . . . . . . . . . . . . . . . . 14 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for 81 authentication and key exchange in SSH. It defines three exchange 82 methods all based on DH groups and SHA-1. The new methods described 83 in this document are intended to support environments that desire to 84 use the SHA-2 cryptographic hash functions. 86 2. Rationale 88 Due to security concerns with SHA-1 [RFC6194] and with MODP groups 89 with less than 2048 bits [NIST-SP-800-131Ar1] we propose the use of 90 the SHA-2 based hashes with DH group14, group15, group16, group17 and 91 group18 [RFC3526]. Additionally we add support for key exchange 92 based on Elliptic Curve Diffie Hellman with NIST P-256, P-384 and 93 P-521 as well as X25519 and X448 curves. Following the rationale of 94 [I-D.ietf-curdle-ssh-modp-dh-sha2] only SHA-256 and SHA-512 hashes 95 are used for DH groups. For NIST curves the same curve-to-hashing 96 algorithm pairing used in [RFC5656] is adopted for consistency. 98 3. Document Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 4. New Diffie-Hellman Key Exchange methods 106 This document adopts the same naming convention defined in [RFC4462] 107 to define families of methods that cover any GSS-API mechanism used 108 with a specific Diffie-Hellman group and SHA-2 Hash combination. 110 The following new key exchange algorithms are defined: 112 +--------------------------+--------------------------------+ 113 | Key Exchange Method Name | Implementation Recommendations | 114 +--------------------------+--------------------------------+ 115 | gss-group14-sha256-* | SHOULD/RECOMMENDED | 116 | gss-group15-sha512-* | MAY/OPTIONAL | 117 | gss-group16-sha512-* | SHOULD/RECOMMENDED | 118 | gss-group17-sha512-* | MAY/OPTIONAL | 119 | gss-group18-sha512-* | MAY/OPTIONAL | 120 +--------------------------+--------------------------------+ 122 Each key exchange method is implicitly registered by this document. 123 The IESG is considered to be the owner of all these key exchange 124 methods; this does NOT imply that the IESG is considered to be the 125 owner of the underlying GSS-API mechanism. 127 4.1. gss-group14-sha256-* 129 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 130 key exchange as described in Section 2.1 of [RFC4462] with SHA-256 as 131 HASH, and the group defined in Section 8.2 of [RFC4253] The method 132 name for each method is the concatenation of the string "gss- 133 group14-sha256-" with the Base64 encoding of the MD5 hash [RFC1321] 134 of the ASN.1 DER encoding [ISO-IEC-8825-1] of the underlying GSS-API 135 mechanism's OID. Base64 encoding is described in Section 6.8 of 136 [RFC2045]. 138 4.2. gss-group15-sha512-* 140 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 141 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 142 HASH, and the group defined in Section 4 of [RFC3526] The method name 143 for each method is the concatenation of the string "gss- 144 group15-sha512-" with the Base64 encoding of the MD5 hash of the 145 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 147 4.3. gss-group16-sha512-* 149 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 150 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 151 HASH, and the group defined in Section 5 of [RFC3526] The method name 152 for each method is the concatenation of the string "gss- 153 group16-sha512-" with the Base64 encoding of the MD5 hash of the 154 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 156 4.4. gss-group17-sha512-* 158 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 159 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 160 HASH, and the group defined in Section 6 of [RFC3526] The method name 161 for each method is the concatenation of the string "gss- 162 group17-sha512-" with the Base64 encoding of the MD5 hash of the 163 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 165 4.5. gss-group18-sha512-* 167 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 168 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 169 HASH, and the group defined in Section 7 of [RFC3526] The method name 170 for each method is the concatenation of the string "gss- 171 group18-sha512-" with the Base64 encoding of the MD5 hash of the 172 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 174 5. New Elliptic Curve Diffie-Hellman Key Exchange methods 176 In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve 177 Cryptography are introduced. We reuse much of section 4 to implement 178 GSS-API-authenticated ECDH Key Exchanges. 180 Additionally we utilize also the curves defined in 181 [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined 182 curves required by [RFC5656]. 184 5.1. Generic GSS-API Key Exchange with ECDH 186 This section reuses much of the scheme defined in Section 2.1 of 187 [RFC4462] and combines it with the scheme defined in Section 4 of 188 [RFC5656]; in particular, all checks and verification steps 189 prescribed in Section 4 of [RFC5656] apply here as well. 191 The symbols used in this description conform to the symbols used in 192 Section 2.1 of [RFC4462]. Additionally, the following symbols are 193 defined: 195 Q_C is the client ephemeral public key octet string 197 Q_S is the server ephemeral public key octet string 199 This section defers to [RFC7546] as the source of information on GSS- 200 API context establishment operations, Section 3 being the most 201 relevant. All Security Considerations described in [RFC7546] apply 202 here too. 204 The Client: 206 1. C generates an ephemeral key pair with public key Q_C. It does 207 that by: 209 For NIST curves: 211 Selecting a value d_C uniformly at random from the interval [1, 212 n-1] where n is the order of generator of the curve associated 213 with the selected key exchange method. 215 Performing point multiplication between the curve base point 216 and selected integer d_C to get the public point q_C. 218 Converts the point q_C to the Q_C octet string by concatenation 219 of value 0x04 and big-endian representation of the x coordinate 220 and then y coordinate. The coordinate coversion MUST preserve 221 leading zero octets. Thus for nistp521 curve the encoded x 222 coordinate will always have a length of 66 octets while the Q_C 223 representation will be 133 octets long. This is the 224 uncompressed representation specified in Section 4.3.6 of 225 [ANSI-X9-62-2005]. 227 For curve25519 and curve448: 229 Selecting d_C as 32 uniformly distributed random octets for 230 curve25519 and 56 octets for curve448. 232 Preparing the generator g as the number 9 little-endian encoded 233 in 32 octets for curve25519 and number 5 in 56 octets for 234 curve448. This is the same as an octet of value 0x09 followed 235 by 31 zero octets for curve255519 and as an octect of value 236 0x05 followed by 55 zero octets. 238 Calculating Q_C as the result of the call to X25519 or X448 239 function, respectively for curve25519 and curve448 key 240 exchange, with parameters d_C and g. 242 2. C calls GSS_Init_sec_context(), using the most recent reply token 243 received from S during this exchange, if any. For this call, the 244 client MUST set mutual_req_flag to "true" to request that mutual 245 authentication be performed. It also MUST set integ_req_flag to 246 "true" to request that per-message integrity protection be supported 247 for this context. In addition, deleg_req_flag MAY be set to "true" 248 to request access delegation, if requested by the user. Since the 249 key exchange process authenticates only the host, the setting of 250 anon_req_flag is immaterial to this process. If the client does not 251 support the "gssapi-keyex" user authentication method described in 252 Section 4 of [RFC4462], or does not intend to use that method in 253 conjunction with the GSS-API context established during key exchange, 254 then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY 255 be set to true if the client wishes to hide its identity. Since the 256 key exchange process will involve the exchange of only a single token 257 once the context has been established, it is not necessary that the 258 GSS-API context support detection of replayed or out-of-sequence 259 tokens. Thus, replay_det_req_flag and sequence_req_flag need not be 260 set for this process. These flags SHOULD be set to "false". 262 If the resulting major_status code is GSS_S_COMPLETE and the 263 mutual_state flag is not true, then mutual authentication has not 264 been established, and the key exchange MUST fail. 266 If the resulting major_status code is GSS_S_COMPLETE and the 267 integ_avail flag is not true, then per-message integrity 268 protection is not available, and the key exchange MUST fail. 270 If the resulting major_status code is GSS_S_COMPLETE and both the 271 mutual_state and integ_avail flags are true, the resulting output 272 token is sent to S. 274 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the 275 output_token is sent to S, which will reply with a new token to be 276 provided to GSS_Init_sec_context(). 278 The client MUST also include Q_C with the first message it sends 279 to the server during this process; if the server receives more 280 than one Q_C or none at all, the key exchange MUST fail. 282 It is an error if the call does not produce a token of non-zero 283 length to be sent to the server. In this case, the key exchange 284 MUST fail. 286 3. When a Q_C key is received, S verifies that the key is valid. If 287 the key is not valid the key exchange MUST fail. 289 The server first checks if the length of the Q_C matches the 290 selected key exchange: 65 octets for nistp256, 97 octets for 291 nistp384, 133 octets for nistp521, 32 octets for curve25519 or 56 292 octets for curve448. If the value does not have matching length 293 the key exchange MUST fail. 295 In case of key exchanges that use NIST curves, the server MUST 296 check if the first octet of the Q_C is equal to 0x04. If the 297 octet has different value the key exchange MUST fail. 299 For NIST curves, the server converts the octet representation of 300 the key to q_C point representation by interpreting the first half 301 of remaining octets as the unsigned big-endian representation of 302 the x coordinate of the point and the second half as the unsigned 303 big-endian representation of the y coordinate. 305 For NIST curves, the server verifies that the q_C is not a point 306 at infinity, that both coordinates are in the interval [0, p - 1], 307 where p is the prime associated with the curve of the selected key 308 exchange and that the point lies on the curve (satisfies the curve 309 equation). 311 For curve25519, the server verifies that the the high-order bit of 312 the last octet is not set - this prevents distinguishing attacks 313 between implementations that use Montgomery ladder implementation 314 of the curve and ones that use generic elliptic-curve libraries. 315 If the bit is set, the key exchange SHOULD fail. For curve448 any 316 bit can be set. 318 For curve25519 and curve448, the point is not decoded but used as 319 is. Q_C and q_C are considered equivalent. 321 4. S calls GSS_Accept_sec_context(), using the token received from 322 C. 324 If the resulting major_status code is GSS_S_COMPLETE and the 325 mutual_state flag is not true, then mutual authentication has not 326 been established, and the key exchange MUST fail. 328 If the resulting major_status code is GSS_S_COMPLETE and the 329 integ_avail flag is not true, then per-message integrity 330 protection is not available, and the key exchange MUST fail. 332 If the resulting major_status code is GSS_S_COMPLETE and both the 333 mutual_state and integ_avail flags are true, then the security 334 context has been established, and processing continues with step 335 5. 337 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, then 338 the output token is sent to C, and processing continues with step 339 2. 341 If the resulting major_status code is GSS_S_COMPLETE, but a non- 342 zero-length reply token is returned, then that token is sent to 343 the client. 345 5. S generates an ephemeral key pair with public key Q_S calculated 346 the same way it is done in step 1 and peforms the following 347 computations: 349 K a shared secret obtained using ECDH key exchange: 351 Both client and server perform the same calculation where d_U 352 is the secret value, d_C for client and d_S for server and q_V 353 is the received public value, q_S for client and q_C for 354 server. 356 For NIST curves, the peers perform point multiplication using 357 d_U and q_V to get point P. 359 For NIST curves, peers verify that P is not a point at 360 infinity. If P is a point at infinity, the key exchange MUST 361 fail. 363 For NIST curves, the shared secret is the zero-padded big- 364 endian representation of the x coordinate of P. 366 For curve25519 and curve448, the peers apply the X25519 or X448 367 function, respectively for curve25519 and curve448, on the d_U 368 and q_V. The result of the function is the shared secret. 370 For curve25519 and curve448, if all the octets of the shared 371 secret are zero octets, the key exchange MUST fail. 373 H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). 375 MIC is the GSS-API message integrity code for H computed by 376 calling GSS_GetMIC(). 378 S then sends Q_S and the message integrity code (MIC) to C. 380 6. This step is performed only if the server's final call to 381 GSS_Accept_sec_context() produced a non-zero-length final reply token 382 to be sent to the client and if no previous call by the client to 383 GSS_Init_sec_context() has resulted in a major_status of 384 GSS_S_COMPLETE. Under these conditions, the client makes an 385 additional call to GSS_Init_sec_context() to process the final reply 386 token. This call is made exactly as described above. However, if 387 the resulting major_status is anything other than GSS_S_COMPLETE, or 388 a non-zero-length token is returned, it is an error and the key 389 exchange MUST fail. 391 7. C verifies that the key Q_S is valid the same way it is done in 392 step 3. If the key is not valid the key exchange MUST fail. 394 8. C computes the shared secret K and H and verifies that it is 395 valid the same way it is done in step 5. It then calls 396 GSS_VerifyMIC() to check that the MIC sent by S verifies H's 397 integrity. If the MIC is not successfully verified, the key exchange 398 MUST fail. 400 If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a 401 major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or 402 any other GSS-API call returns a major_status other than 403 GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations 404 expressed in Section 2.1 of [RFC4462] are followed with regards to 405 error reporting. 407 This exchange is implemented with the following messages: 409 The client sends: 411 byte SSH_MSG_KEXGSS_INIT 412 string output_token (from GSS_Init_sec_context()) 413 string Q_C, client's ephemeral public key octet string 415 The server may responds with: 417 byte SSH_MSG_KEXGSS_HOSTKEY 418 string server public host key and certificates (K_S) 420 Since this key exchange method does not require the host key to be 421 used for any encryption operations, this message is OPTIONAL. If the 422 "null" host key algorithm described in Section 5 of [RFC4462] is 423 used, this message MUST NOT be sent. 425 Each time the server's call to GSS_Accept_sec_context() returns a 426 major_status code of GSS_S_CONTINUE_NEEDED 427 The server replies: 429 byte SSH_MSG_KEXGSS_CONTINUE 430 string output_token (from GSS_Accept_sec_context()) 432 If the client receives this message after a call to 433 GSS_Init_sec_context() has returned a major_status code of 434 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 435 MUST fail. 437 Each time the client receives the message described above, it makes 438 another call to GSS_Init_sec_context(). 440 The client sends: 442 byte SSH_MSG_KEXGSS_CONTINUE 443 string output_token (from GSS_Init_sec_context()) 445 The server and client continue to trade these two messages as long as 446 the server's calls to GSS_Accept_sec_context() result in major_status 447 codes of GSS_S_CONTINUE_NEEDED. When a call results in a 448 major_status code of GSS_S_COMPLETE, it sends one of two final 449 messages. 451 If the server's final call to GSS_Accept_sec_context() (resulting in 452 a major_status code of GSS_S_COMPLETE) returns a non-zero-length 453 token to be sent to the client, it sends the following: 455 byte SSH_MSG_KEXGSS_COMPLETE 456 string Q_S, server's ephemeral public key octet string 457 string mic_token (MIC of H) 458 boolean TRUE 459 string output_token (from GSS_Accept_sec_context()) 461 If the client receives this message after a call to 462 GSS_Init_sec_context() has returned a major_status code of 463 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 464 MUST fail. 466 If the server's final call to GSS_Accept_sec_context() (resulting in 467 a major_status code of GSS_S_COMPLETE) returns a zero-length token or 468 no token at all, it sends the following: 470 byte SSH_MSG_KEXGSS_COMPLETE 471 string Q_S, server's ephemeral public key octet string 472 string mic_token (MIC of H) 473 boolean FALSE 475 If the client receives this message when no call to 476 GSS_Init_sec_context() has yet resulted in a major_status code of 477 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 478 MUST fail. 480 In case of errors the messages described in Section 2.1 of [RFC4462] 481 are used as well as the recommendation about the messages' order. 483 The hash H is computed as the HASH hash of the concatenation of the 484 following: 486 string V_C, the client's version string (CR, NL excluded) 487 string V_S, server's version string (CR, NL excluded) 488 string I_C, payload of the client's SSH_MSG_KEXINIT 489 string I_S, payload of the server's SSH_MSG_KEXINIT 490 string K_S, server's public host key 491 string Q_C, client's ephemeral public key octet string 492 string Q_S, server's ephemeral public key octet string 493 mpint K, shared secret 495 This value is called the exchange hash, and it is used to 496 authenticate the key exchange. The exchange hash SHOULD be kept 497 secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 498 server or received by the client, then the empty string is used in 499 place of K_S when computing the exchange hash. 501 The GSS_GetMIC call MUST be applied over H, not the original data. 503 5.2. ECDH Key Exchange Methods 505 The following new key exchange methods are defined: 507 +--------------------------+--------------------------------+ 508 | Key Exchange Method Name | Implementation Recommendations | 509 +--------------------------+--------------------------------+ 510 | gss-nistp256-sha256-* | SHOULD/RECOMMENDED | 511 | gss-nistp384-sha384-* | MAY/OPTIONAL | 512 | gss-nistp521-sha512-* | MAY/OPTIONAL | 513 | gss-curve25519-sha256-* | SHOULD/RECOMMENDED | 514 | gss-curve448-sha512-* | MAY/OPTIONAL | 515 +--------------------------+--------------------------------+ 517 Each key exchange method is implicitly registered by this document. 518 The IESG is considered to be the owner of all these key exchange 519 methods; this does NOT imply that the IESG is considered to be the 520 owner of the underlying GSS-API mechanism. 522 5.2.1. gss-nistp256-sha256-* 524 Each of these methods specifies GSS-API-authenticated Elliptic Curve 525 Diffie-Hellman key exchange as described in Section 5.1 of this 526 document with SHA-256 as HASH, and the curve and base point defined 527 in section 2.4.2 of [SEC2v2] as secp256r1. The method name for each 528 method is the concatenation of the string "gss-nistp256-sha256-" with 529 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 530 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 531 Base64 encoding is described in Section 6.8 of [RFC2045]. 533 5.2.2. gss-nistp384-sha384-* 535 Each of these methods specifies GSS-API-authenticated Elliptic Curve 536 Diffie-Hellman key exchange as described in Section 5.1 of this 537 document with SHA-384 as HASH, and the curve and base point defined 538 in section 2.5.1 of [SEC2v2] as secp384r1. The method name for each 539 method is the concatenation of the string "gss-nistp384-sha384-" with 540 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 541 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 542 Base64 encoding is described in Section 6.8 of [RFC2045]. 544 5.2.3. gss-nistp521-sha512-* 546 Each of these methods specifies GSS-API-authenticated Elliptic Curve 547 Diffie-Hellman key exchange as described in Section 5.1 of this 548 document with SHA-512 as HASH, and the curve and base point defined 549 in section 2.6.1 of [SEC2v2] as secp521r1. The method name for each 550 method is the concatenation of the string "gss-nistp521-sha512-" with 551 the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER 552 encoding [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. 553 Base64 encoding is described in Section 6.8 of [RFC2045]. 555 5.2.4. gss-curve25519-sha256-* 557 Each of these methods specifies GSS-API-authenticated Elliptic Curve 558 Diffie-Hellman key exchange as described in Section 5.1 of this 559 document with SHA-256 as HASH, and the X25519 function defined in 560 section 5 of [RFC7748]. The method name for each method is the 561 concatenation of the string "gss-curve25519-sha256-" with the Base64 562 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 563 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 564 encoding is described in Section 6.8 of [RFC2045]. 566 5.2.5. gss-curve448-sha512-* 568 Each of these methods specifies GSS-API-authenticated Elliptic Curve 569 Diffie-Hellman key exchange as described in Section 5.1 of this 570 document with SHA-512 as HASH, and the X448 function defined in 571 section 5 of [RFC7748]. The method name for each method is the 572 concatenation of the string "gss-curve448-sha512-" with the Base64 573 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding 574 [ISO-IEC-8825-1] of the underlying GSS-API mechanism's OID. Base64 575 encoding is described in Section 6.8 of [RFC2045]. 577 6. IANA Considerations 579 This document augments the SSH Key Exchange Method Names in 580 [RFC4462]. 582 IANA is requested to update the SSH algorithm registry with the 583 following entries: 585 +--------------------------+------------+------------------------+ 586 | Key Exchange Method Name | Reference | Implementation Support | 587 +--------------------------+------------+------------------------+ 588 | gss-group14-sha256-* | This draft | SHOULD | 589 | gss-group15-sha512-* | This draft | MAY | 590 | gss-group16-sha512-* | This draft | SHOULD | 591 | gss-group17-sha512-* | This draft | MAY | 592 | gss-group18-sha512-* | This draft | MAY | 593 | gss-nistp256-sha256-* | This draft | SHOULD | 594 | gss-nistp384-sha384-* | This draft | MAY | 595 | gss-nistp521-sha512-* | This draft | MAY | 596 | gss-curve25519-sha256-* | This draft | SHOULD | 597 | gss-curve448-sha512-* | This draft | MAY | 598 +--------------------------+------------+------------------------+ 600 7. Security Considerations 602 7.1. New Finite Field DH mechanisms 604 Except for the use of a different secure hash function and larger DH 605 groups, no significant changes has been made to the protocol 606 described by [RFC4462]; therefore all the original Security 607 Considerations apply. 609 7.2. New Elliptic Curve DH mechanisms 611 Although a new cryptographic primitive is used with these methods the 612 actual key exchange closely follows the key exchange defined in 614 [RFC5656]; therefore all the original Security Considerations as well 615 as those expressed in [RFC5656] apply. 617 7.3. GSSAPI Delegation 619 Some GSSAPI mechanisms can optionally delegate credentials to the 620 target host by setting the deleg_ret_flag. In this case extra care 621 must be taken to ensure that the acceptor being authenticated matches 622 the target the user intended. Some mechanisms implementations (like 623 commonly used krb5 libraries) may use insecure DNS resolution to 624 canonicalize the target name; in these cases spoofing a DNS response 625 that points to an attacker-controlled machine may results in the user 626 silently delegating credentials to the attacker, who can then 627 impersonate the user at will. 629 8. Normative References 631 [ANSI-X9-62-2005] 632 American National Standards Institute, "Public Key 633 Cryptography for the Financial Services Industry, The 634 Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI 635 Standard X9.62, 2005. 637 [FIPS-180-4] 638 National Institute of Standards and Technology, "FIPS PUB 639 180-4: Secure Hash Standard (SHS)", FIPS PUB 180-4, August 640 2015, . 643 [I-D.ietf-curdle-ssh-curves] 644 Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 645 Shell (SSH) Key Exchange Method using Curve25519 and 646 Curve448", draft-ietf-curdle-ssh-curves-04 (work in 647 progress), April 2017. 649 [I-D.ietf-curdle-ssh-modp-dh-sha2] 650 Baushke, M., "More Modular Exponential (MODP) Diffie- 651 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 652 (SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-04 (work in 653 progress), April 2017. 655 [ISO-IEC-8825-1] 656 International Organization for Standardization / 657 International Electrotechnical Commission, "ASN.1 encoding 658 rules: Specification of Basic Encoding Rules (BER), 659 Canonical Encoding Rules (CER) and Distinguished Encoding 660 Rules (DER)", ISO/IEC 8825-1, November 2015, 661 . 664 [NIST-SP-800-131Ar1] 665 National Institute of Standards and Technology, 666 "Transitions: Recommendation for Transitioning of the Use 667 of Cryptographic Algorithms and Key Lengths", NIST Special 668 Publication 800-131A Revision 1, November 2015, 669 . 672 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 673 DOI 10.17487/RFC1321, April 1992, 674 . 676 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 677 Extensions (MIME) Part One: Format of Internet Message 678 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 679 . 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 687 Diffie-Hellman groups for Internet Key Exchange (IKE)", 688 RFC 3526, DOI 10.17487/RFC3526, May 2003, 689 . 691 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 692 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 693 January 2006, . 695 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 696 "Generic Security Service Application Program Interface 697 (GSS-API) Authentication and Key Exchange for the Secure 698 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 699 2006, . 701 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 702 Integration in the Secure Shell Transport Layer", 703 RFC 5656, DOI 10.17487/RFC5656, December 2009, 704 . 706 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 707 Considerations for the SHA-0 and SHA-1 Message-Digest 708 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 709 . 711 [RFC7546] Kaduk, B., "Structure of the Generic Security Service 712 (GSS) Negotiation Loop", RFC 7546, DOI 10.17487/RFC7546, 713 May 2015, . 715 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 716 for Security", RFC 7748, DOI 10.17487/RFC7748, January 717 2016, . 719 [SEC2v2] Certicom Research, "SEC 2: Recommended Elliptic Curve 720 Domain Parameters", Standards for Efficient 721 Cryptography SEC 2, 2010. 723 Authors' Addresses 725 Simo Sorce 726 Red Hat, Inc. 727 140 Broadway 728 24th Floor 729 New York, NY 10025 730 USA 732 Email: simo@redhat.com 734 Hubert Kario 735 Red Hat, Inc. 736 Purkynova 99/71 737 Brno 612 45 738 Czech Republic 740 Email: hkario@redhat.com