idnits 2.17.1 draft-ietf-secsh-gsskeyex-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [7], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 168 has weird spacing: '... string out...' == Line 173 has weird spacing: '... string out...' == Line 180 has weird spacing: '... string out...' == Line 187 has weird spacing: '... string per...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2001) is 8504 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1510 (ref. '3') (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') ** Obsolete normative reference: RFC 2478 (ref. '8') (Obsoleted by RFC 4178) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hutzelman 3 Internet-Draft CMU 4 Expires: July 14, 2001 J. Salowey 5 Cisco Systems 6 January 13, 2001 8 Using GSSAPI authentication for key exchange in Secure Shell 9 draft-ietf-secsh-gsskeyex-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 14, 2001. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 This memo describes a method for using the Generic Security Service 41 Application Program Interface [2] for key exchange in the Secure 42 Shell protocol, by defining a class of SSH key exchange methods 43 which use GSSAPI to authenticate the Diffie-Hellman exchange 44 described in [10]. 46 This memo also defines a new host public key algorithm which can be 47 used when no operations are needed using a host's public key, and a 48 new user authentication method which allows an authorization name to 49 be used in conjunction with any authentication which has already 50 occurred as a side-effect of key exchange. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [7]. 56 1. GSSAPI Authenticated Diffie-Hellman Key Exchange 58 This section defines a class of key exchange methods which combine 59 the Diffie-Hellman key exchange from section 6 of [10] with mutual 60 authentication using GSSAPI. 62 Since the GSSAPI key exchange methods described in this section do 63 not require the use of public key signature or encryption 64 algorithms, they MAY be used with any host hey algorithm, including 65 the "null" algorithm described in section 2 of this document. 67 1.1 Generic method description 69 The following symbols are used in this description: 71 o C is the client, and S is the server 73 o p is a large safe prime, g is a generator for a subgroup of 74 GF(p), and q is the order of the subgroup 76 o V_S is S's version string, and V_C is C's version string 78 o I_C is C's KEXINIT message, and I_S is S's KEXINIT message 80 1. C generates a random number x (1 < x < q) and computes e = g^x 81 mod p. 83 2. C calls GSS_Init_sec_context, using the most reply token 84 received from S during this exchange, if any. For this call, 85 the client MUST set the mutual_req_flag to "true" to request 86 that mutual authentication be performed. It also MUST set the 87 integ_req_flag to "true" to request that per-message integrity 88 protection be supported for this context. In addition, the 89 deleg_req_flag MAY be set to "true" to request access 90 delegation, if requested by the user. Since the key exchange 91 process authenticates only the host, the setting of the 92 anon_req_flag is immaterial to this process. If the client or 93 server does not support the "external-keyx" user authentication 94 method described in section 3 of this document, or if the client 95 does not intend to use that method, then the anon_req_flag 96 SHOULD be set to "true". Otherwise, this flag MAY be set to 97 true if the client wishes to hide its identity. 99 * If the resulting major_status code is GSS_S_COMPLETE and the 100 mutual_state flag is not true, then mutual authentication has 101 not been established, and the key exchange MUST fail. 103 * If the resulting major_status code is GSS_S_COMPLETE and the 104 integ_avail flag is not true, then per-message integrity 105 protection is not available, and the key exchange MUST fail. 107 * If the resulting major_status code is GSS_S_COMPLETE and the 108 mutual_state flag is true, the resulting output token is sent 109 to S along with "e". 111 * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, 112 the the output_token (only) is sent to S, which will reply 113 with a new token to be provided to GSS_Init_sec_context. 115 * The client MUST include "e" with exactly one of the messages 116 it sends to the server during this process; if the server 117 receives more than one "e" or none at all, the key exchange 118 fails. The client SHOULD wait until the last message (that 119 is, the one containing the token returned by 120 GSS_Init_sec_context at the same time it returned 121 GSS_S_COMPLETE) to send "e", so that it is not sent if there 122 is an error in the course of setting up the GSSAPI security 123 context. 125 3. S calls GSS_Accept_sec_context, using the token received from C. 127 * If the resulting major_status code is GSS_S_COMPLETE and the 128 mutual_state flag is not true, then mutual authentication has 129 not been established, and the key exchange MUST fail. 131 * If the resulting major_status code is GSS_S_COMPLETE and the 132 mutual_state flag is true, then the security context has been 133 established, and processing continues with step 4. 135 * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, 136 then the output token is sent to C, and processing continues 137 with step 2. 139 4. S generates a random number y (0 < y < q) and computes f = g^y 140 mod p. It computes K = e ^ y mod p, and H = hash(V_C || V_S || 141 I_C || I_S || e || f || K). It then calls GSS_GetMIC to obtain 142 a GSSAPI message integrity code for H. S then sends f and the 143 MIC to C. 145 5. C computes K = f^x mod p, and H = hash(V_C || V_S || I_C || I_S 146 || e || f || K). It then calls GSS_VerifyMIC to verify that the 147 MIC sent by S matches H. 149 Either side MUST NOT send or accept e or f values that are not in 150 the range [1, p-1]. If this condition is violated, the key exchange 151 fails. 153 If any call to GSS_Init_sec_context or GSS_Accept_sec_context 154 returns a major_status other than GSS_S_COMPLETE or 155 GSS_S_CONTINUE_NEEDED, or any other GSSAPI call returns a 156 major_status other than GSS_S_COMPLETE, the key exchange fails. 158 This is implemented with the following messages. The hash algorithm 159 for computing the exchange hash is defined by the method name, and 160 is called HASH. The group used for Diffie-Hellman key exchange and 161 the underlying GSSAPI mechanism are also defined by the method name. 163 Each time GSS_Init_sec_context returns a major_status code of 164 GSS_S_CONTINUE_NEEDED, the client sends the following: 166 byte SSH_MSG_GSSAPI_INIT 167 boolean FALSE 168 string output_token (from GSS_Init_sec_context) 170 The server responds with the following: 172 byte SSH_MSG_GSSAPI_CONTINUE 173 string output_token (from GSS_Accept_sec_context) 175 When GSS_Init_sec_context returns a major_status code of 176 GSS_S_COMPLETE, the client sends the following: 178 byte SSH_MSG_GSSAPI_INIT 179 boolean TRUE 180 string output_token (from GSS_Init_sec_context) 181 mpint e 183 The server responds with the following: 185 byte SSH_MSG_GSSAPI_COMPLETE 186 mpint f 187 string per_msg_token (MIC of H) 189 The hash H is computed as the HASH hash of the concatenation of the 190 following: 192 string V_C, the client's version string (CR and NL excluded) 193 string V_S, the server's version string (CR and NL excluded) 194 string I_C, the payload of the client's SSH_MSG_KEXINIT 195 string I_S, the payload of the server's SSH_MSG_KEXINIT 196 mpint e, exchange value sent by the client 197 mpint f, exchange value sent by the server 198 mpint K, the shared secret 200 This value is called the exchange hash, and it is used to 201 authenticate the key exchange. The exchange hash SHOULD be kept 202 secret. 204 The GSS_GetMIC call MUST be applied over H, not the original data. 206 1.2 gss-group1-sha1-* 208 Each of these methods specifies GSSAPI authenticated Diffie-Hellman 209 key exchange as described in section 1.1 of this document, with 210 SHA-1 as HASH, and the group defined in section 6.1 of [10]. The 211 method name for each method is the concatenation of the string 212 "gss-group1-sha1-" with the Base64 encoding of the first ten bytes 213 of the MD5 hash [5] of the ASN.1 DER encoding [1] of the underlying 214 GSSAPI mechanism's OID. Base64 encoding is described in section 6.8 215 of [6]. 217 Each and every such key exchange method is implicitly registered by 218 this specification. The IESG is considered to be the owner of all 219 such key exchange methods; this does NOT imply that the IESG is 220 considered to be the owner of the underlying GSSAPI mechanism. 222 1.3 Other GSSAPI key exchange methods 224 Key exchange method names starting with "gss-" are reserved for key 225 exchange methods which conform to this document; in particular, for 226 those methods which use the GSSAPI authenticated Diffie-Hellman key 227 exchange algorithm described in section 1.1 of this document, 228 including any future methods which use different groups and/or hash 229 functions. The intent is that the names for any such future methods 230 methods be defined in a similar manner to that used in section 1.2 231 of this document. 233 1.4 SPNEGO 235 The use of the Simple and Protected GSS-API Negotiation Mechanism 236 [8] in conjunction with the key exchange methods described in this 237 document is both unnecessary and undesirable. As a result, key 238 exchange mechanisms conforming to this document MUST NOT use SPNEGO 239 as the underlying GSSAPI mechanism. 241 Since SSH performs its own negotiation of key exchange methods, and 242 there exists a separate method name corresponding to every possible 243 underlying GSSAPI mechanism, the negotiation capability of SPNEGO 244 alone does not provide any added benefit. In fact, as described 245 below, it has the potential to result in the use of a weaker method 246 than desired. 248 Normally, SPNEGO provides the added benefit of protecting the GSSAPI 249 mechanism negotiation. It does this by having the server compute a 250 MIC of the list of mechanisms proposed by the client, and then 251 checking that value at the client. The key exchange methods 252 described in this document already perform an equivalent operation; 253 namely, they generate a MIC of the SSH exchange hash, which is a 254 hash of several items including the lists of key exchange mechanisms 255 supported by both sides. Thus, the extra level of protection 256 offered by SPNEGO is unnecessary in this case. 258 The use of SPNEGO combined with GSSAPI mechanisms used without 259 SPNEGO can lead to interoperability problems. For example, a client 260 which supports key exchange using the Kerberos V5 GSSAPI mechanism 261 [4] only underneath SPNEGO will not interoperate with a server which 262 supports key exchange only using the Kerberos V5 GSSAPI mechanism 263 directly. As a result, allowing GSSAPI mechanisms to be used both 264 with and without SPNEGO is undesirable. 266 If a client's policy is to first prefer GSSAPI-based key exchange 267 method X, then non-GSSAPI method Y, then GSSAPI-based method Z, and 268 if a server supports mechanisms Y and Z but not X, then an attempt 269 to use SPNEGO to negotiate a GSSAPI mechanism might result in the 270 use of method Z when method Y would have been preferable. As a 271 result, the use of SPNEGO could result in the subversion of the 272 negotiation algorithm for key exchange methods as described in 273 section 5.1 of [10]. 275 1.5 Naming Conventions 277 In order to establish a GSSAPI security context, the SSH client 278 needs to determine the appropriate targ_name to use in identifying 279 the server when calling GSS_Init_sec_context. For this purpose, the 280 GSSAPI mechanism-independent name form for host-based services is 281 used, as described in section 4.1 of [2]. 283 In particular, the targ_name to pass to GSS_Init_sec_context is 284 obtained by calling GSS_Import_name with an input_name_type of 285 GSS_C_NT_HOSTBASED_SERVICE, and an input_name_string consisting of 286 the string "host@" concatenated with the hostname of the SSH server. 288 2. Null Host Key Algorithm 290 The "null" host key algorithm has no associated host key material, 291 and provides neither signature nor encryption algorithms. Thus, it 292 can be used only with key exchange methods that do not require any 293 public-key operations and do not require the use of host public key 294 material. The key exchange methods described in section 1 of this 295 document are examples of such methods. 297 This algorithm is used when, as a matter of configuration, the host 298 does not have or does not wish to use a public key. For example, it 299 can be used when the administrator has decided as a matter of policy 300 to require that all key exchanges be authenticated using Kerberos 301 [3], and thus the only permitted key exchange method is the 302 GSSAPI-authenticated Diffie-Hellman exchange described above, with 303 Kerberos V5 as the underlying GSSAPI mechanism. In such a 304 configuration, the server implementation supports the "ssh-dss" key 305 algorithm (as required by [10], but could be prohibited by 306 configuration from using it. In this situation, the server needs 307 some key exchange algorithm to advertise; the "null" algorithm fills 308 this purpose. 310 Note that the use of the "null" algorithm in this way means that the 311 server will not be able to interoperate with clients which do not 312 support this algorithm. This is not a significant problem, since in 313 the configuration described, it will also be unable to interoperate 314 with implementations that do not support the GSSAPI-authenticated 315 key exchange and Kerberos. 317 Any implementation supporting at least one key exchange method which 318 conforms to section 1 of this document MUST also support the "null" 319 host key algorithm. Servers MUST NOT advertise the "null" host key 320 algorithm unless it is the only algorithm advertised. 322 3. External Key Exchange user authentication 324 This section describes a user authentication method building on the 325 framework described in [11]. This method relies upon the key 326 exchange to authenticate both the client and the server. If the key 327 exchange did not successfully perform these functions then the 328 server MUST always respond to this request with 329 SSH_MSG_USERAUTH_FAILURE with partial success set to false. 331 The new mechanism is defined as follows: 333 byte SSH_MSG_USERAUTH_REQUEST 334 string authorization-ID 335 string service 336 string "external-keyx" 338 If the user authenticated in the key-exchange is allowed to assume 339 the authorization identity, this method is successful, and the 340 server responds with SSH_MSG_USERAUTH_SUCCESS if no more 341 authentications are needed, or with SSH_MSG_USERAUTH_FAILURE with 342 partial success set to true if more authentications are needed. 344 If the user authenticated in the key-exchange is not allowed to 345 assume the authorization identity, then SSH_MSG_USERAUTH_FAILURE is 346 returned with partial success set to false. 348 Any implementation supporting at least one key exchange method which 349 conforms to section 1 of this document SHOULD also support the 350 "external-keyx" user authentication method, in order to allow user 351 authentication to be performed at the same time as key exchange, 352 thereby reducing the number of round trips needed for connection 353 setup. 355 4. Security Considerations 357 This document describes an authentication and key-exchange protocol. 358 As such, security considerations are discussed throughout. 360 This protocol depends on the SSH protocol itself, the GSSAPI, any 361 underlying GSSAPI mechanisms which are used, and any protocols on 362 which such mechanisms might depend. Each of these components plays 363 a part in the security of the resulting connection, and each will 364 have its own security considerations. 366 The key exchange method described in section 1 of this document 367 depends on the underlying GSSAPI mechanism to provide both mutual 368 authentication and per-message integrity services. If either of 369 these features is not supported by a particular GSSAPI mechanism, or 370 by a particular implementation of a GSSAPI mechanism, then the key 371 exchange is not secure and MUST fail. 373 In order for the "external-keyx" user authentication method to be 374 used, it MUST have access to user authentication information 375 obtained as a side-effect of the key exchange. If this information 376 is unavailable, the authentication MUST fail. 378 5. Trademark Issues 380 SSH is a registered trademark and Secure Shell is a trademark of SSH 381 Communications Security Corp (www.ssh.com), and are used herein to 382 describe and refer to the SSH protocol, as permitted in section 9 of 383 [9]. These trademarks may not be used as part of a product name or 384 in otherwise confusing manner without prior written permission of 385 SSH Communications Security Corp. 387 References 389 [1] ISO/IEC, "Specification of Abstract Syntax Notation One 390 (ASN.1)", ISO/IEC 8824, November 1998. 392 [2] Linn, J., "Generic Security Service Application Program 393 Interface Version 2, Update 1", RFC 2743, January 2000. 395 [3] Kohl, J. and C. Neuman, "The Kerberos Network Authentication 396 Service (V5)", RFC 1510, September 1993. 398 [4] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 399 1964, June 1996. 401 [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 402 April 1992. 404 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 405 Extensions (MIME) Part One: Format of Internet Message 406 Bodies", RFC 2045, November 1996. 408 [7] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", RFC 2119, BCP 14, March 1997. 411 [8] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 412 Negotiation Mechanism", RFC 2478, December 1998. 414 [9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 415 Lehtinen, "SSH Protocol Architecture", November 2000. 417 [10] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 418 Lehtinen, "SSH Transport Layer Protocol", November 2000. 420 [11] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 421 Lehtinen, "SSH Authentication Protocol", November 2000. 423 Authors' Addresses 425 Jeffrey Hutzelman 426 Carnegie Mellon University 427 5000 Forbes Ave 428 Pittsburgh, PA 15213 429 US 431 Phone: +1 412 268 7225 432 EMail: jhutz+@cmu.edu 433 URI: http://www.cs.cmu.edu/~jhutz/ 434 Joseph Salowey 435 Cisco Systems 436 Bldg 20 437 725 Alder Drive 438 Milpitas, CA 95035 439 US 441 Phone: +1 408 525 6381 442 EMail: jsalowey@cisco.com 444 Full Copyright Statement 446 Copyright (C) The Internet Society (2001). All Rights Reserved. 448 This document and translations of it may be copied and furnished to 449 others, and derivative works that comment on or otherwise explain it 450 or assist in its implementation may be prepared, copied, published 451 and distributed, in whole or in part, without restriction of any 452 kind, provided that the above copyright notice and this paragraph 453 are included on all such copies and derivative works. However, this 454 document itself may not be modified in any way, such as by removing 455 the copyright notice or references to the Internet Society or other 456 Internet organizations, except as needed for the purpose of 457 developing Internet standards in which case the procedures for 458 copyrights defined in the Internet Standards process must be 459 followed, or as required to translate it into languages other than 460 English. 462 The limited permissions granted above are perpetual and will not be 463 revoked by the Internet Society or its successors or assigns. 465 This document and the information contained herein is provided on an 466 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 467 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 468 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 469 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 470 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Acknowledgement 474 Funding for the RFC editor function is currently provided by the 475 Internet Society.