idnits 2.17.1 draft-ssorce-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 308 has weird spacing: '... string out...' == Line 314 has weird spacing: '... string ser...' == Line 327 has weird spacing: '... string out...' == Line 340 has weird spacing: '... string out...' == Line 354 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 13, 2016) is 2691 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 460, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' == Outdated reference: A later version (-12) exists of draft-ietf-curdle-ssh-curves-00 == Outdated reference: A later version (-20) exists of draft-ietf-curdle-ssh-kex-sha2-05 -- 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 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 6 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 13, 2016 6 Expires: June 16, 2017 8 GSS-API Key Exchange with SHA2 9 draft-ssorce-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 June 16, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 2 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-* . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7.1. New Finite Field DH mechanisms . . . . . . . . . . . . . 10 68 7.2. New Elliptic Curve DH mechanisms . . . . . . . . . . . . 10 69 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for 75 authentication and key exchange in SSH. It defines three exchange 76 methods all based on DH groups and SHA-1. The new methods described 77 in this document are intended to support environments that desired to 78 use the SHA-2 cryptographic hash functions. 80 2. Rationale 82 Due to security concerns with SHA-1 [RFC6194] and with MODP groups 83 with less than 2048 bits [NIST-SP-800-131Ar1] we propose the use of 84 the SHA-2 based hashes with DH group14, group15, group16, group17 and 85 group18 [RFC3526]. Additionally we add support for key exchange 86 based on Elliptic Curve Diffie Hellman with NIST P-256, P-384 and 87 P-521 as well as X25519 and X448 curves. Following the rationale of 88 [I-D.ietf-curdle-ssh-kex-sha2] only SHA-256 and SHA-512 hashes are 89 used. 91 3. Document Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 4. New Diffie-Hellman Key Exchange methods 99 This document adopts the same naming convention defined in [RFC4462] 100 to define families of methods that cover any GSS-API mechanism used 101 with a specific Diffie-Hellman group and SHA-2 Hash combination. 103 The following new key exchange algorithms are defined: 105 +--------------------------+--------------------------------+ 106 | Key Exchange Method Name | Implementation Recommendations | 107 +--------------------------+--------------------------------+ 108 | gss-group14-sha256-* | SHOULD/RECOMMENDED | 109 | gss-group15-sha512-* | MAY/OPTIONAL | 110 | gss-group16-sha512-* | SHOULD/RECOMMENDED | 111 | gss-group17-sha512-* | MAY/OPTIONAL | 112 | gss-group18-sha512-* | MAY/OPTIONAL | 113 +--------------------------+--------------------------------+ 115 Each key exchange method is implicitly registered by this document. 116 The IESG is considered to be the owner of all these key exchange 117 methods; this does NOT imply that the IESG is considered to be the 118 owner of the underlying GSS-API mechanism. 120 4.1. gss-group14-sha256-* 122 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 123 key exchange as described in Section 2.1 of [RFC4462] with SHA-256 as 124 HASH, and the group defined in Section 8.2 of [RFC4253] The method 125 name for each method is the concatenation of the string "gss- 126 group14-sha256-" with the Base64 encoding of the MD5 hash [RFC1321] 127 of the ASN.1 DER encoding [ISO-IEC-8825-1] of the underlying GSS-API 128 mechanism's OID. Base64 encoding is described in Section 6.8 of 129 [RFC2045]. 131 4.2. gss-group15-sha512-* 133 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 134 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 135 HASH, and the group defined in Section 5 of [RFC3526] The method name 136 for each method is the concatenation of the string "gss- 137 group15-sha512-" with the Base64 encoding of the MD5 hash of the 138 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 140 4.3. gss-group16-sha512-* 142 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 143 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 144 HASH, and the group defined in Section 5 of [RFC3526] The method name 145 for each method is the concatenation of the string "gss- 146 group16-sha512-" with the Base64 encoding of the MD5 hash of the 147 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 149 4.4. gss-group17-sha512-* 151 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 152 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 153 HASH, and the group defined in Section 5 of [RFC3526] The method name 154 for each method is the concatenation of the string "gss- 155 group17-sha512-" with the Base64 encoding of the MD5 hash of the 156 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 158 4.5. gss-group18-sha512-* 160 Each of these methods specifies GSS-API-authenticated Diffie-Hellman 161 key exchange as described in Section 2.1 of [RFC4462] with SHA-512 as 162 HASH, and the group defined in Section 7 of [RFC3526] The method name 163 for each method is the concatenation of the string "gss- 164 group18-sha512-" with the Base64 encoding of the MD5 hash of the 165 ASN.1 DER encoding of the underlying GSS-API mechanism's OID. 167 5. New Elliptic Curve Diffie-Hellman Key Exchange methods 169 In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve 170 Cryptography are introduced. We reuse much of section 4 to implement 171 GSS-API-authenticated ECDH Key Exchanges. 173 Additionally we utilize also the curves defined in 174 [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined 175 curves required by [RFC5656]. 177 5.1. Generic GSS-API Key Exchange with ECDH 179 This section reuses much of the scheme defined in Section 2.1 of 180 [RFC4462] and combines it with the scheme defined in Section 4 of 181 [RFC5656]; in particular, all checks and verification steps 182 prescribed in Section 4 of [RFC5656] apply here as well. 184 The symbols used in this description conform to the symbols used in 185 Section 2.1 of [RFC4462]. Additionally, the following symbols are 186 defined: 188 Q_C is the client ephemeral public key octet string 190 Q_S is the server ephemeral public key octet string 192 The Client: 194 1. C generates an ephemeral key pair with public key Q_C 196 2. C calls GSS_Init_sec_context(), using the most recent reply token 197 received from S during this exchange, if any. For this call, the 198 client MUST set mutual_req_flag to "true" to request that mutual 199 authentication be performed. It also MUST set integ_req_flag to 200 "true" to request that per-message integrity protection be supported 201 for this context. In addition, deleg_req_flag MAY be set to "true" 202 to request access delegation, if requested by the user. Since the 203 key exchange process authenticates only the host, the setting of 204 anon_req_flag is immaterial to this process. If the client does not 205 support the "gssapi-keyex" user authentication method described in 206 Section 4 of [RFC4462], or does not intend to use that method in 207 conjunction with the GSS-API context established during key exchange, 208 then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY 209 be set to true if the client wishes to hide its identity. Since the 210 key exchange process will involve the exchange of only a single token 211 once the context has been established, it is not necessary that the 212 GSS-API context support detection of replayed or out-of-sequence 213 tokens. Thus, replay_det_req_flag and sequence_req_flag need not be 214 set for this process. These flags SHOULD be set to "false". 216 If the resulting major_status code is GSS_S_COMPLETE and the 217 mutual_state flag is not true, then mutual authentication has not 218 been established, and the key exchange MUST fail. 220 If the resulting major_status code is GSS_S_COMPLETE and the 221 integ_avail flag is not true, then per-message integrity 222 protection is not available, and the key exchange MUST fail. 224 If the resulting major_status code is GSS_S_COMPLETE and both the 225 mutual_state and integ_avail flags are true, the resulting output 226 token is sent to S. 228 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the 229 output_token is sent to S, which will reply with a new token to be 230 provided to GSS_Init_sec_context(). 232 The client MUST also include Q_C with the first message it sends 233 to the server during this process; if the server receives more 234 than one Q_C or none at all, the key exchange MUST fail. 236 It is an error if the call does not produce a token of non- zero 237 length to be sent to the server. In this case, the key exchange 238 MUST fail. 240 3. When a Q_C key is received, S verifies that the key is valid. If 241 the key is not valid the key exchange MUST fail. 243 4. S calls GSS_Accept_sec_context(), using the token received from 244 C. 246 If the resulting major_status code is GSS_S_COMPLETE and the 247 mutual_state flag is not true, then mutual authentication has not 248 been established, and the key exchange MUST fail. 250 If the resulting major_status code is GSS_S_COMPLETE and the 251 integ_avail flag is not true, then per-message integrity 252 protection is not available, and the key exchange MUST fail. 254 If the resulting major_status code is GSS_S_COMPLETE and both the 255 mutual_state and integ_avail flags are true, then the security 256 context has been established, and processing continues with step 257 5. 259 If the resulting major_status code is GSS_S_CONTINUE_NEEDED, then 260 the output token is sent to C, and processing continues with step 261 2. 263 If the resulting major_status code is GSS_S_COMPLETE, but a non- 264 zero-length reply token is returned, then that token is sent to 265 the client. 267 5. S generates an ephemeral key pair with public key Q_S and 268 performs the following computations: 270 K a shared secret obtained using Q_C and Q_S. 272 H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). 274 MIC is the GSS-API message integrity code for H computed by 275 calling GSS_GetMIC(). 277 6. This step is performed only if the server's final call to 278 GSS_Accept_sec_context() produced a non-zero-length final reply token 279 to be sent to the client and if no previous call by the client to 280 GSS_Init_sec_context() has resulted in a major_status of 281 GSS_S_COMPLETE. Under these conditions, the client makes an 282 additional call to GSS_Init_sec_context() to process the final reply 283 token. This call is made exactly as described above. However, if 284 the resulting major_status is anything other than GSS_S_COMPLETE, or 285 a non-zero-length token is returned, it is an error and the key 286 exchange MUST fail. 288 7. C verifies that the key Q_S is valid. If the key is not valid 289 the key exchange MUST fail. 291 8. C computes the shared secret K and H the same way it is done in 292 step 5. It then calls GSS_VerifyMIC() to check that the MIC sent by 293 S verifies H's integrity. If the MIC is not successfully verified, 294 the key exchange MUST fail. 296 If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a 297 major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or 298 any other GSS-API call returns a major_status other than 299 GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations 300 expressed in Section 2.1 of [RFC4462] are followed with regards to 301 error reporting. 303 This excahnge is implemented with the following messages: 305 The client sends: 307 byte SSH_MSG_KEXGSS_INIT 308 string output_token (from GSS_Init_sec_context()) 309 string Q_C, client's ephemeral public key octet string 311 The server may responds with: 313 byte SSH_MSG_KEXGSS_HOSTKEY 314 string server public host key and certificates (K_S) 316 Since this key exchange method does not require the host key to be 317 used for any encryption operations, this message is OPTIONAL. If the 318 "null" host key algorithm described in Section 5 of [RFC4462]is used, 319 this message MUST NOT be sent. 321 Each time the server's call to GSS_Accept_sec_context() returns a 322 major_status code of GSS_S_CONTINUE_NEEDED 324 The server replies: 326 byte SSH_MSG_KEXGSS_CONTINUE 327 string output_token (from GSS_Accept_sec_context()) 329 If the client receives this message after a call to 330 GSS_Init_sec_context() has returned a major_status code of 331 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 332 MUST fail. 334 Each time the client receives the message described above, it makes 335 another call to GSS_Init_sec_context(). 337 The client sends: 339 byte SSH_MSG_KEXGSS_CONTINUE 340 string output_token (from GSS_Init_sec_context()) 342 The server and client continue to trade these two messages as long as 343 the server's calls to GSS_Accept_sec_context() result in major_status 344 codes of GSS_S_CONTINUE_NEEDED. When a call results in a 345 major_status code of GSS_S_COMPLETE, it sends one of two final 346 messages. 348 If the server's final call to GSS_Accept_sec_context() (resulting in 349 a major_status code of GSS_S_COMPLETE) returns a non-zero-length 350 token to be sent to the client, it sends the following: 352 byte SSH_MSG_KEXGSS_COMPLETE 353 string Q_S, server's ephemeral public key octet string 354 string mic_token (MIC of H) 355 boolean TRUE 356 string output_token (from GSS_Accept_sec_context()) 358 If the client receives this message after a call to 359 GSS_Init_sec_context() has returned a major_status code of 360 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 361 MUST fail. 363 If the server's final call to GSS_Accept_sec_context() (resulting in 364 a major_status code of GSS_S_COMPLETE) returns a zero-length token or 365 no token at all, it sends the following: 367 byte SSH_MSG_KEXGSS_COMPLETE 368 string Q_S, server's ephemeral public key octet string 369 string mic_token (MIC of H) 370 boolean FALSE 372 If the client receives this message when no call to 373 GSS_Init_sec_context() has yet resulted in a major_status code of 374 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 375 MUST fail. 377 In case of errors the messages described in Section 2.1 of [RFC4462] 378 are used as well as the recommendation about the messages' order. 380 The hash H is computed as the HASH hash of the concatenation of the 381 following: 383 string V_C, the client's version string (CR, NL excluded) 384 string V_S, server's identification string (CR and LF excluded) 385 string I_C, payload of the client's SSH_MSG_KEXINIT 386 string I_S, payload of the server's SSH_MSG_KEXINIT 387 string K_S, server's public host key 388 string Q_C, client's ephemeral public key octet string 389 string Q_S, server's ephemeral public key octet string 390 mpint K, shared secret 392 This value is called the exchange hash, and it is used to 393 authenticate the key exchange. The exchange hash SHOULD be kept 394 secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 395 server or received by the client, then the empty string is used in 396 place of K_S when computing the exchange hash. 398 The GSS_GetMIC call MUST be applied over H, not the original data. 400 5.2. ECDH Key Exchange Methods 402 The following new key exchange methods are defined: 404 +--------------------------+--------------------------------+ 405 | Key Exchange Method Name | Implementation Recommendations | 406 +--------------------------+--------------------------------+ 407 | gss-secp256r1-sha256-* | SHOULD/RECOMMENDED | 408 | gss-secp384r1-sha512-* | MAY/OPTIONAL | 409 | gss-secp521r1-sha512-* | MAY/OPTIONAL | 410 | gss-curve25519-sha256-* | SHOULD/RECOMMENDED | 411 | gss-curve448-sha512-* | MAY/OPTIONAL | 412 +--------------------------+--------------------------------+ 414 Each key exchange method is implicitly registered by this document. 415 The IESG is considered to be the owner of all these key exchange 416 methods; this does NOT imply that the IESG is considered to be the 417 owner of the underlying GSS-API mechanism. 419 6. IANA Considerations 421 This document augments the SSH Key Exchange Method Names in 422 [RFC4462]. 424 IANA is requested to update the SSH algorithm registry with the 425 following entries: 427 +--------------------------+------------+------------------------+ 428 | Key Exchange Method Name | Reference | Implementation Support | 429 +--------------------------+------------+------------------------+ 430 | gss-group14-sha256-* | This draft | SHOULD | 431 | gss-group15-sha512-* | This draft | MAY | 432 | gss-group16-sha512-* | This draft | SHOULD | 433 | gss-group17-sha512-* | This draft | MAY | 434 | gss-group18-sha512-* | This draft | MAY | 435 | gss-secp256r1-sha256-* | This draft | SHOULD | 436 | gss-secp384r1-sha512-* | This draft | MAY | 437 | gss-secp521r1-sha512-* | This draft | MAY | 438 | gss-curve25519-sha256-* | This draft | SHOULD | 439 | gss-curve448-sha512-* | This draft | MAY | 440 +--------------------------+------------+------------------------+ 442 7. Security Considerations 444 7.1. New Finite Field DH mechanisms 446 Except for the use of a different secure hash function and larger DH 447 groups, no significant changes has been made to the protocol 448 described by [RFC4462]; therefore all the original Security 449 Considerations apply. 451 7.2. New Elliptic Curve DH mechanisms 453 Although a new cryptographic primitive is used with these methods the 454 actual key exchange closely follows the key exchange defined in 455 [RFC5656]; therefore all the original Security Considerations as well 456 as those expressed in [RFC5656] apply. 458 8. Normative References 460 [FIPS-180-4] 461 National Institute of Standards and Technology, "FIPS PUB 462 180-4: Secure Hash Standard (SHS)", FIPS PUB 180-4, August 463 2015, . 466 [I-D.ietf-curdle-ssh-curves] 467 Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key 468 Exchange Method using Curve25519 and Curve448", draft- 469 ietf-curdle-ssh-curves-00 (work in progress), March 2016. 471 [I-D.ietf-curdle-ssh-kex-sha2] 472 Baushke, M., "Key Exchange (KEX) Method Updates and 473 Recommendations for Secure Shell (SSH)", draft-ietf- 474 curdle-ssh-kex-sha2-05 (work in progress), September 2016. 476 [ISO-IEC-8825-1] 477 International Organization for Standardization / 478 International Electrotechnical Commission, "ASN.1 encoding 479 rules: Specification of Basic Encoding Rules (BER), 480 Canonical Encoding Rules (CER) and Distinguished Encoding 481 Rules (DER)", ISO/IEC 8825-1, November 2015, 482 . 485 [NIST-SP-800-131Ar1] 486 National Institute of Standards and Technology, 487 "Transitions: Recommendation for Transitioning of the Use 488 of Cryptographic Algorithms and Key Lengths", NIST Special 489 Publication 800-131A Revision 1, November 2015, 490 . 493 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 494 DOI 10.17487/RFC1321, April 1992, 495 . 497 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 498 Extensions (MIME) Part One: Format of Internet Message 499 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 500 . 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 508 Diffie-Hellman groups for Internet Key Exchange (IKE)", 509 RFC 3526, DOI 10.17487/RFC3526, May 2003, 510 . 512 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 513 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 514 January 2006, . 516 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 517 "Generic Security Service Application Program Interface 518 (GSS-API) Authentication and Key Exchange for the Secure 519 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 520 2006, . 522 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 523 Integration in the Secure Shell Transport Layer", 524 RFC 5656, DOI 10.17487/RFC5656, December 2009, 525 . 527 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 528 Considerations for the SHA-0 and SHA-1 Message-Digest 529 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 530 . 532 Authors' Addresses 534 Simo Sorce 535 Red Hat, Inc. 536 140 Broadway 537 24th Floor 538 New York, NY 10025 539 USA 541 Email: simo@redhat.com 543 Hubert Kario 544 Red Hat, Inc. 545 Purkynova 99/71 546 Brno 612 45 547 Czech Republic 549 Email: hkario@redhat.com