idnits 2.17.1 draft-ietf-secsh-gsskeyex-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1274. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 298 has weird spacing: '... string out...' == Line 306 has weird spacing: '... string ser...' == Line 345 has weird spacing: '... string out...' == Line 356 has weird spacing: '... string out...' == Line 370 has weird spacing: '... string per...' == (12 more instances...) -- 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 (August 22, 2005) is 6820 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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. 'ASN1' ** Obsolete normative reference: RFC 3066 (ref. 'LANGTAG') (Obsoleted by RFC 4646, RFC 4647) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. 'KRB5') (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2478 (ref. 'SPNEGO') (Obsoleted by RFC 4178) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group J. Hutzelman 3 Internet-Draft CMU 4 Expires: February 23, 2006 J. Salowey 5 Cisco Systems 6 J. Galbraith 7 Van Dyke Technologies, Inc. 8 V. Welch 9 U Chicago / ANL 10 August 22, 2005 12 GSSAPI Authentication and Key Exchange for the Secure Shell Protocol 13 draft-ietf-secsh-gsskeyex-10 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 23, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The Secure Shell protocol (SSH) is a protocol for secure remote login 47 and other secure network services over an insecure network. 49 The Generic Security Service Application Program Interface (GSS-API) 50 provides security services to callers in a mechanism-independent 51 fashion. 53 This memo describes methods for using the GSS-API for authentication 54 and key exchange in SSH. It defines an SSH user authentication 55 method which uses a specified GSSAPI mechanism to authenticate a 56 user, and a family of SSH key exchange methods which use GSSAPI to 57 authenticate a Diffie-Hellman key exchange. 59 This memo also defines a new host public key algorithm which can be 60 used when no operations are needed using a host's public key, and a 61 new user authentication method which allows an authorization name to 62 be used in conjunction with any authentication which has already 63 occurred as a side-effect of GSSAPI-based key exchange. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. SSH terminology . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. GSSAPI Authenticated Diffie-Hellman Key Exchange . . . . . . . 5 71 2.1. Generic GSSAPI Key Exchange . . . . . . . . . . . . . . . 5 72 2.2. Group Exchange . . . . . . . . . . . . . . . . . . . . . . 11 73 2.3. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 13 74 2.4. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . . 13 75 2.5. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . . 13 76 2.6. Other GSSAPI key exchange methods . . . . . . . . . . . . 13 77 3. GSSAPI User Authentication . . . . . . . . . . . . . . . . . . 15 78 3.1. GSSAPI Authentication Overview . . . . . . . . . . . . . . 15 79 3.2. Initiating GSSAPI authentication . . . . . . . . . . . . . 15 80 3.3. Initial server response . . . . . . . . . . . . . . . . . 16 81 3.4. GSSAPI session . . . . . . . . . . . . . . . . . . . . . . 16 82 3.5. Binding Encryption Keys . . . . . . . . . . . . . . . . . 17 83 3.6. Client acknowledgement . . . . . . . . . . . . . . . . . . 18 84 3.7. Completion . . . . . . . . . . . . . . . . . . . . . . . . 19 85 3.8. Error Status . . . . . . . . . . . . . . . . . . . . . . . 19 86 3.9. Error Token . . . . . . . . . . . . . . . . . . . . . . . 20 87 4. Authentication using GSSAPI Key Exchange . . . . . . . . . . . 21 88 5. Null Host Key Algorithm . . . . . . . . . . . . . . . . . . . 23 89 6. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 24 90 7. GSSAPI Considerations . . . . . . . . . . . . . . . . . . . . 25 91 7.1. Naming Conventions . . . . . . . . . . . . . . . . . . . . 25 92 7.2. Channel Bindings . . . . . . . . . . . . . . . . . . . . . 25 93 7.3. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 97 11. Changes the last version . . . . . . . . . . . . . . . . . . . 30 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 100 12.2. Non-Normative References . . . . . . . . . . . . . . . . . 32 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 102 Intellectual Property and Copyright Statements . . . . . . . . . . 34 104 1. Introduction 106 This document describes the methods used to perform key exchange and 107 user authentication in the Secure Shell protocol using the GSSAPI. 108 To do this, it defines a family of key exchange methods, two user 109 authentication methods, and a new host key algorithm. These 110 definitions allow any GSSAPI mechanism to be used with the Secure 111 Shell protocol. 113 This document should be read only after reading the documents 114 describing the SSH protocol architecture [SSH-ARCH], transport layer 115 protocol [SSH-TRANSPORT], and user authentication protocol [SSH- 116 USERAUTH]. This document freely uses terminology and notation from 117 the architecture document without reference or further explanation. 119 1.1. SSH terminology 121 The data types used in the packets are defined in the SSH 122 architecture document [SSH-ARCH]. It is particularly important to 123 note the definition of string allows binary content. 125 The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this service 126 name is an SSH service name, and has no relationship to GSSAPI 127 service names. Currently, the only defined service name is "ssh- 128 connection", which refers to the SSH connection protocol [SSH- 129 CONNECT]. 131 1.2. Keywords 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [KEYWORDS]. 137 2. GSSAPI Authenticated Diffie-Hellman Key Exchange 139 This section defines a class of key exchange methods which combine 140 the Diffie-Hellman key exchange from section 8 of [SSH-TRANSPORT] 141 with mutual authentication using GSSAPI. 143 Since the GSSAPI key exchange methods described in this section do 144 not require the use of public key signature or encryption algorithms, 145 they MAY be used with any host key algorithm, including the "null" 146 algorithm described in Section 5. 148 2.1. Generic GSSAPI Key Exchange 150 The following symbols are used in this description: 152 o C is the client, and S is the server 154 o p is a large safe prime, g is a generator for a subgroup of GF(p), 155 and q is the order of the subgroup 157 o V_S is S's version string, and V_C is C's version string 159 o I_C is C's KEXINIT message, and I_S is S's KEXINIT message 161 1. C generates a random number x (1 < x < q) and computes e = g^x 162 mod p. 164 2. C calls GSS_Init_sec_context, using the most recent reply token 165 received from S during this exchange, if any. For this call, the 166 client MUST set the mutual_req_flag to "true" to request that 167 mutual authentication be performed. It also MUST set the 168 integ_req_flag to "true" to request that per-message integrity 169 protection be supported for this context. In addition, the 170 deleg_req_flag MAY be set to "true" to request access delegation, 171 if requested by the user. Since the key exchange process 172 authenticates only the host, the setting of the anon_req_flag is 173 immaterial to this process. If the client does not support the 174 "gssapi-keyex" user authentication method described in Section 4, 175 or does not intend to use that method in conjunction with the 176 GSSAPI context established during key exchange, then the 177 anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY 178 be set to true if the client wishes to hide its identity. Since 179 the key exchange process will involve the exchange of only a 180 single token once the context has been established, it is not 181 necessary that the GSSAPI context support detection of replayed 182 or out-of-sequence tokens. Thus, the setting of the 183 replay_det_req_flag and sequence_req_flag are not needed for this 184 process. These flags SHOULD be set to "false". 186 * If the resulting major_status code is GSS_S_COMPLETE and the 187 mutual_state flag is not true, then mutual authentication has 188 not been established, and the key exchange MUST fail. 190 * If the resulting major_status code is GSS_S_COMPLETE and the 191 integ_avail flag is not true, then per-message integrity 192 protection is not available, and the key exchange MUST fail. 194 * If the resulting major_status code is GSS_S_COMPLETE and both 195 the mutual_state and integ_avail flags are true, the resulting 196 output token is sent to S. 198 * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, 199 the output_token is sent to S, which will reply with a new 200 token to be provided to GSS_Init_sec_context. 202 * The client MUST also include "e" with the first message it 203 sends to the server during this process; if the server 204 receives more than one "e" or none at all, the key exchange 205 fails. 207 * It is an error if the call does not produce a token of non- 208 zero length to be sent to the server. In this case, the key 209 exchange MUST fail. 211 3. S calls GSS_Accept_sec_context, using the token received from C. 213 * If the resulting major_status code is GSS_S_COMPLETE and the 214 mutual_state flag is not true, then mutual authentication has 215 not been established, and the key exchange MUST fail. 217 * If the resulting major_status code is GSS_S_COMPLETE and the 218 integ_avail flag is not true, then per-message integrity 219 protection is not available, and the key exchange MUST fail. 221 * If the resulting major_status code is GSS_S_COMPLETE and both 222 the mutual_state and integ_avail flags are true, then the 223 security context has been established, and processing 224 continues with step 4. 226 * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, 227 then the output token is sent to C, and processing continues 228 with step 2. 230 * If the resulting major_status code is GSS_S_COMPLETE, but a 231 non-zero-length reply token is returned, then that token is 232 sent to the client. 234 4. S generates a random number y (0 < y < q) and computes f = g^y 235 mod p. It computes K = e ^ y mod p, and H = hash(V_C || V_S || 236 I_C || I_S || K_S || e || f || K). It then calls GSS_GetMIC to 237 obtain a GSSAPI message integrity code for H. S then sends f and 238 the MIC to C. 240 5. This step is performed only if the server's final call to 241 GSS_Accept_sec_context produced a non-zero-length final reply 242 token to be sent to the client _and_ no previous call by the 243 client to GSS_Init_sec_context has resulted in a major_status of 244 GSS_S_COMPLETE. Under these conditions, the client makes an 245 additional call to GSS_Init_sec_context to process the final 246 reply token. This call is made exactly as described above. 247 However, if the resulting major_status is anything other than 248 GSS_S_COMPLETE, or a non-zero-length token is returned, it is an 249 error and the key exchange MUST fail. 251 6. C computes K = f^x mod p, and H = hash(V_C || V_S || I_C || I_S 252 || K_S || e || f || K). It then calls GSS_VerifyMIC to verify 253 that the MIC sent by S matches H. If the MIC is not successfully 254 verified, the key exchange MUST fail. 256 Either side MUST NOT send or accept e or f values that are not in the 257 range [1, p-1]. If this condition is violated, the key exchange 258 fails. 260 If any call to GSS_Init_sec_context or GSS_Accept_sec_context returns 261 a major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or 262 any other GSSAPI call returns a major_status other than 263 GSS_S_COMPLETE, the key exchange fails. In this case, several 264 mechanisms are available for communicating error information to the 265 peer before terminating the connection as required by [SSH- 266 TRANSPORT]: 268 o If the key exchange fails due to any GSSAPI error on the server 269 (including errors returned by GSS_Accept_sec_context), the server 270 MAY send a message informing the client of the details of the 271 error. In this case, if an error token is also sent (see below), 272 then this message MUST be sent before the error token. 274 o If the key exchange fails due to a GSSAPI error returned from the 275 server's call to GSS_Accept_sec_context, and an "error token" is 276 also returned, then the server SHOULD send the error token to the 277 client to allow completion of the GSS security exchange. 279 o If the key exchange fails due to a GSSAPI error returned from the 280 client's call to GSS_Init_sec_context, and an "error token" is 281 also returned, then the client SHOULD send the error token to the 282 server to allow completion of the GSS security exchange. 284 As noted in Section 9, it may be desirable under site security policy 285 to obscure information about the precise nature of the error; thus, 286 it is RECOMMENDED that implementations provide a method to suppress 287 these messages as a matter of policy. 289 This is implemented with the following messages. The hash algorithm 290 for computing the exchange hash is defined by the method name, and is 291 called HASH. The group used for Diffie-Hellman key exchange and the 292 underlying GSSAPI mechanism are also defined by the method name. 294 After the client's first call to GSS_Init_sec_context, it sends the 295 following: 297 byte SSH_MSG_KEXGSS_INIT 298 string output_token (from GSS_Init_sec_context) 299 mpint e 301 Upon receiving the SSH_MSG_KEXGSS_INIT message, the server MAY send 302 the following message, prior to any other messages, to inform the 303 client of its host key. 305 byte SSH_MSG_KEXGSS_HOSTKEY 306 string server public host key and certificates (K_S) 308 Since this key exchange method does not require the host key to be 309 used for any encryption operations, this message is OPTIONAL. If the 310 "null" host key algorithm described in Section 5 is used, this 311 message MUST NOT be sent. If this message is sent, the server public 312 host key(s) and/or certificate(s) in this message are encoded as a 313 single string, in the format specified by the public key type in use 314 (see [SSH-TRANSPORT], section 6.6). 316 In traditional SSH deployments, host keys are normally expected to 317 change infrequently, and there is often no mechanism for validating 318 host keys not already known to the client. As a result, the use of a 319 new host key by an already-known host is usually considered an 320 indication of a possible man-in-the-middle attack, and clients often 321 present strong warnings and/or abort the connection in such cases. 323 By contrast, when GSSAPI-based key exchange is used, host keys sent 324 via the SSH_MSG_KEXGSS_HOSTKEY message are authenticated as part of 325 the GSSAPI key exchange, even when previously unknown to the client. 326 Further, in environments in which GSSAPI-based key exchange is used 327 heavily, it is possible and even likely that host keys will change 328 much more frequently and/or without advance warning. 330 Therefore, when a new key for an already-known host is received via 331 the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue strong 332 warnings or abort the connection, provided the GSSAPI-based key 333 exchange succeeds. 335 In order to facilitate key re-exchange after the user's GSSAPI 336 credentials have expired, client implementations SHOULD store host 337 keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the 338 session, even when such keys are not stored for long-term use. 340 Each time the server's call to GSS_Accept_sec_context returns a 341 major_status code of GSS_S_CONTINUE_NEEDED, it sends the following 342 reply to the client: 344 byte SSH_MSG_KEXGSS_CONTINUE 345 string output_token (from GSS_Accept_sec_context) 347 If the client receives this message after a call to 348 GSS_Init_sec_context has returned a major_status code of 349 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 350 MUST fail. 352 Each time the client receives the message described above, it makes 353 another call to GSS_Init_sec_context. It then sends the following: 355 byte SSH_MSG_KEXGSS_CONTINUE 356 string output_token (from GSS_Init_sec_context) 358 The server and client continue to trade these two messages as long as 359 the server's calls to GSS_Accept_sec_context result in major_status 360 codes of GSS_S_CONTINUE_NEEDED. When a call results in a 361 major_status code of GSS_S_COMPLETE, it sends one of two final 362 messages. 364 If the server's final call to GSS_Accept_sec_context (resulting in a 365 major_status code of GSS_S_COMPLETE) returns a non-zero-length token 366 to be sent to the client, it sends the following: 368 byte SSH_MSG_KEXGSS_COMPLETE 369 mpint f 370 string per_msg_token (MIC of H) 371 boolean TRUE 372 string output_token (from GSS_Accept_sec_context) 374 If the client receives this message after a call to 375 GSS_Init_sec_context has returned a major_status code of 376 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 377 MUST fail. 379 If the server's final call to GSS_Accept_sec_context (resulting in a 380 major_status code of GSS_S_COMPLETE) returns a zero-length token or 381 no token at all, it sends the following: 383 byte SSH_MSG_KEXGSS_COMPLETE 384 mpint f 385 string per_msg_token (MIC of H) 386 boolean FALSE 388 If the client receives this message when no call to 389 GSS_Init_sec_context has yet resulted in a major_status code of 390 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 391 MUST fail. 393 If either the client's call to GSS_Init_sec_context or the server's 394 call to GSS_Accept_sec_context returns an error status and produces 395 an output token (called an "error token"), then the following SHOULD 396 be sent to convey the error information to the peer: 398 byte SSH_MSG_KEXGSS_CONTINUE 399 string error_token 401 If a server sends both this message and an SSH_MSG_KEXGSS_ERROR 402 message, the SSH_MSG_KEXGSS_ERROR message MUST be sent first, to 403 allow clients to record and/or display the error information before 404 processing the error token. This is important because a client 405 processing an error token will likely disconnect without reading any 406 further messages. 408 In the event of a GSSAPI error on the server, the server MAY send the 409 following message before terminating the connection: 411 byte SSH_MSG_KEXGSS_ERROR 412 uint32 major_status 413 uint32 minor_status 414 string message 415 string language tag 417 The message text MUST be encoded in the UTF-8 encoding described in 418 [UTF8]. Language tags are those described in [LANGTAG]. Note that 419 the message text may contain multiple lines separated by carriage 420 return-line feed (CRLF) sequences. Application developers should 421 take this into account when displaying these messages. 423 The hash H is computed as the HASH hash of the concatenation of the 424 following: 426 string V_C, the client's version string (CR, NL excluded) 427 string V_S, the server's version string (CR, NL excluded) 428 string I_C, the payload of the client's SSH_MSG_KEXINIT 429 string I_S, the payload of the server's SSH_MSG_KEXINIT 430 string K_S, the host key 431 mpint e, exchange value sent by the client 432 mpint f, exchange value sent by the server 433 mpint K, the shared secret 435 This value is called the exchange hash, and it is used to 436 authenticate the key exchange. The exchange hash SHOULD be kept 437 secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 438 server or received by the client, then the empty string is used in 439 place of K_S when computing the exchange hash. 441 The GSS_GetMIC call MUST be applied over H, not the original data. 443 2.2. Group Exchange 445 This section describes a modification to the generic GSSAPI 446 authenticated Diffie-Hellman key exchange to allow the negotiation of 447 the group to be used, using a method based on that described in 448 [GROUP-EXCHANGE]. 450 The server keeps a list of safe primes and corresponding generators 451 that it can select from. These are chosen as described in section 3 452 of [GROUP-EXCHANGE]. The client requests a modulus from the server, 453 indicating the minimum, maximum, and preferred sizes; the server 454 responds with a suitable modulus and generator. The exchange then 455 proceeds as described in Section 2.1 above. 457 This description uses the following symbols, in addition to those 458 defined above: 460 o n is the size of the modulus p in bits that the client would like 461 to receive from the server 463 o min and max are the minimal and maximal sizes of p in bits that 464 are acceptable to the client 466 1. C sends "min || n || max" to S, indicating the minimal acceptable 467 group size, the preferred size of the group, and the maximal 468 group size in bits the client will accept. 470 2. S finds a group that best matches the client's request, and sends 471 "p || g" to C. 473 3. The exchange proceeds as described in Section 2.1 above, 474 beginning with step 1, except that the exchange hash is computed 475 as described below. 477 Servers and clients SHOULD support groups with a modulus length of k 478 bits, where 1024 <= k <= 8192. The recommended values for min and 479 max are 1024 and 8192, respectively. 481 This is implemented using the following messages, in addition to 482 those described above: 484 First, the client sends: 486 byte SSH_MSG_KEXGSS_GROUPREQ 487 uint32 min, minimal size in bits of an acceptable group 488 uint32 n, preferred size in bits of the group the server 489 should send 490 uint32 max, maximal size in bits of an acceptable group 492 The server responds with: 494 byte SSH_MSG_KEXGSS_GROUP 495 mpint p, safe prime 496 mpint g, generator for subgroup in GF(p) 498 This is followed by the message exchange described above in 499 Section 2.1, except that the exchange hash H is computed as the HASH 500 hash of the concatenation of the following: 502 string V_C, the client's version string (CR, NL excluded) 503 string V_S, the server's version string (CR, NL excluded) 504 string I_C, the payload of the client's SSH_MSG_KEXINIT 505 string I_S, the payload of the server's SSH_MSG_KEXINIT 506 string K_S, the host key 507 uint32 min, minimal size in bits of an acceptable group 508 uint32 n, preferred size in bits of the group the server 509 should send 510 uint32 max, maximal size in bits of an acceptable group 511 mpint p, safe prime 512 mpint g, generator for subgroup in GF(p) 513 mpint e, exchange value sent by the client 514 mpint f, exchange value sent by the server 515 mpint K, the shared secret 517 2.3. gss-group1-sha1-* 519 Each of these methods specifies GSSAPI authenticated Diffie-Hellman 520 key exchange as described in Section 2.1 with SHA-1 as HASH, and the 521 group defined in section 8.1 of [SSH-TRANSPORT]. The method name for 522 each method is the concatenation of the string "gss-group1-sha1-" 523 with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 DER 524 encoding [ASN1] of the underlying GSSAPI mechanism's OID. Base64 525 encoding is described in section 6.8 of [MIME]. 527 Each and every such key exchange method is implicitly registered by 528 this specification. The IESG is considered to be the owner of all 529 such key exchange methods; this does NOT imply that the IESG is 530 considered to be the owner of the underlying GSSAPI mechanism. 532 2.4. gss-group14-sha1-* 534 Each of these methods specifies GSSAPI authenticated Diffie-Hellman 535 key exchange as described in Section 2.1 with SHA-1 as HASH, and the 536 group defined in section 8.2 of [SSH-TRANSPORT]. The method name for 537 each method is the concatenation of the string "gss-group14-sha1-" 538 with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 DER 539 encoding [ASN1] of the underlying GSSAPI mechanism's OID. Base64 540 encoding is described in section 6.8 of [MIME]. 542 Each and every such key exchange method is implicitly registered by 543 this specification. The IESG is considered to be the owner of all 544 such key exchange methods; this does NOT imply that the IESG is 545 considered to be the owner of the underlying GSSAPI mechanism. 547 2.5. gss-gex-sha1-* 549 Each of these methods specifies GSSAPI authenticated Diffie-Hellman 550 key exchange as described in Section 2.2 with SHA-1 as HASH. The 551 method name for each method is the concatenation of the string "gss- 552 gex-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the 553 ASN.1 DER encoding [ASN1] of the underlying GSSAPI mechanism's OID. 554 Base64 encoding is described in section 6.8 of [MIME]. 556 Each and every such key exchange method is implicitly registered by 557 this specification. The IESG is considered to be the owner of all 558 such key exchange methods; this does NOT imply that the IESG is 559 considered to be the owner of the underlying GSSAPI mechanism. 561 2.6. Other GSSAPI key exchange methods 563 Key exchange method names starting with "gss-" are reserved for key 564 exchange methods which conform to this document; in particular, for 565 those methods which use the GSSAPI authenticated Diffie-Hellman key 566 exchange algorithm described in Section 2.1, including any future 567 methods which use different groups and/or hash functions. The intent 568 is that the names for any such future methods methods be defined in a 569 similar manner to that used in Section 2.3. 571 3. GSSAPI User Authentication 573 This section describes a general-purpose user authentication method 574 based on [GSSAPI]. It is intended to be run over the SSH user 575 authentication protocol [SSH-USERAUTH]. 577 The authentication method name for this protocol is "gssapi-with- 578 mic". 580 3.1. GSSAPI Authentication Overview 582 GSSAPI authentication must maintain a context. Authentication begins 583 when the client sends a SSH_MSG_USERAUTH_REQUEST, which specifies the 584 mechanism OIDs the client supports. 586 If the server supports any of the requested mechanism OIDs, the 587 server sends a SSH_MSG_USERAUTH_GSSAPI_RESPONSE message containing 588 the mechanism OID. 590 After the client receives SSH_MSG_USERAUTH_GSSAPI_RESPONSE, the 591 client and server exchange SSH_MSG_USERAUTH_GSSAPI_TOKEN packets 592 until the authentication mechanism either succeeds or fails. 594 If at any time during the exchange, the client sends a new 595 SSH_MSG_USERAUTH_REQUEST packet, the GSSAPI context is completely 596 discarded and destroyed, and any further GSSAPI authentication MUST 597 restart from the beginning. 599 3.2. Initiating GSSAPI authentication 601 The GSSAPI authentication method is initiated when the client sends a 602 SSH_MSG_USERAUTH_REQUEST: 604 byte SSH_MSG_USERAUTH_REQUEST 605 string user name (in ISO-10646 UTF-8 encoding) 606 string service name (in US-ASCII) 607 string "gssapi-with-mic" (US-ASCII method name) 608 uint32 n, the number of mechanism OIDs client supports 609 string[n] mechanism OIDs 611 Mechanism OIDs are encoded according to the ASN.1 distinguished 612 encoding rules (DER), as described in [ASN1] and in section 3.1 of 613 [GSSAPI]. The mechanism OIDs MUST be listed in order of preference, 614 and the server must choose the first mechanism OID on the list that 615 it supports. 617 The client SHOULD send GSSAPI mechanism OID's only for mechanisms 618 which are of the same priority, compared to non-GSSAPI authentication 619 methods. Otherwise, authentication methods may be executed out of 620 order. Thus, the client could first send a SSH_MSG_USERAUTH_REQUEST 621 for one GSSAPI mechanism, then try public key authentication, and 622 then try another GSSAPI mechanism. 624 If the server does not support any of the specified OIDs, the server 625 MUST fail the request by sending a SSH_MSG_USERAUTH_FAILURE packet. 627 The user name may be an empty string if it can be deduced from the 628 results of the GSSAPI authentication. If the user name is not empty, 629 and the requested user does not exist, the server MAY disconnect, or 630 MAY send a bogus list of acceptable authentications but never accept 631 any. This makes it possible for the server to avoid disclosing 632 information about which accounts exist. In any case, if the user 633 does not exist, the authentication request MUST NOT be accepted. 635 The client MAY at any time continue with a new 636 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 637 abandon the previous authentication attempt and continue with the new 638 one. 640 3.3. Initial server response 642 The server responds to the SSH_MSG_USERAUTH_REQUEST with either a 643 SSH_MSG_USERAUTH_FAILURE if none of the mechanisms are supported, or 644 with SSH_MSG_USERAUTH_GSSAPI_RESPONSE as follows: 646 byte SSH_MSG_USERAUTH_GSSAPI_RESPONSE 647 string selected mechanism OID 649 The mechanism OID must be one of the OIDs sent by the client in the 650 SSH_MSG_USERAUTH_REQUEST packet. 652 3.4. GSSAPI session 654 Once the mechanism OID has been selected, the client will then 655 initiate an exchange of one or more pairs of 656 SSH_MSG_USERAUTH_GSSAPI_TOKEN packets. These packets contain the 657 tokens produced from the 'GSS_Init_sec_context()' and 658 'GSS_Accept_sec_context()' calls. The actual number of packets 659 exchanged is determined by the underlying GSSAPI mechanism. 661 byte SSH_MSG_USERAUTH_GSSAPI_TOKEN 662 string data returned from either GSS_Init_sec_context() 663 or GSS_Accept_sec_context() 665 If an error occurs during this exchange on server side, the server 666 can terminate the method by sending a SSH_MSG_USERAUTH_FAILURE 667 packet. If an error occurs on client side, the client can terminate 668 the method by sending a new SSH_MSG_USERAUTH_REQUEST packet. 670 When calling GSS_Init_sec_context(), the client MUST set the the 671 integ_req_flag to "true" to request that per-message integrity 672 protection be supported for this context. In addition, the 673 deleg_req_flag MAY be set to "true" to request access delegation, if 674 requested by the user. 676 Since the user authentication process by its nature authenticates 677 only the client, the setting of the mutual_req_flag is not needed for 678 this process. This flag SHOULD be set to "false". 680 Since the user authentication process will involve the exchange of 681 only a single token once the context has been established, it is not 682 necessary that the context support detection of replayed or out-of- 683 sequence tokens. Thus, the setting of the replay_det_req_flag and 684 sequence_req_flag are not needed for this process. These flags 685 SHOULD be set to "false". 687 Additional SSH_MSG_USERAUTH_GSSAPI_TOKEN messages are sent if and 688 only if the calls to the GSSAPI routines produce send tokens of non- 689 zero length. 691 Any major status code other than GSS_S_COMPLETE or 692 GSS_S_CONTINUE_NEEDED SHOULD be a failure. 694 3.5. Binding Encryption Keys 696 In some cases, it is possible to obtain improved security by allowing 697 access only if the client sends a valid message integrity code (MIC) 698 binding the GSSAPI context to the keys used for encryption and 699 integrity protection of the SSH session. With this extra level of 700 protection, a "man-in-the-middle" attacker who has convinced a client 701 of his authenticity cannot then relay user authentication messages 702 between the real client and server, thus gaining access to the real 703 server. This additional protection is available when the negotiated 704 GSSAPI context supports per-message integrity protection, as 705 indicated by the setting of the integ_avail flag on successful return 706 from GSS_Init_sec_context() or GSS_Accept_sec_context(). 708 When the client's call to GSS_Init_sec_context() returns 709 GSS_S_COMPLETE with the integ_avail flag set, the client MUST 710 conclude the user authentication exchange by sending the following 711 message: 713 byte SSH_MSG_USERAUTH_GSSAPI_MIC 714 string MIC 716 This message MUST be sent only if GSS_Init_sec_context() returned 717 GSS_S_COMPLETE. If a token is also returned then the 718 SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one. 720 The contents of the MIC field are obtained by calling GSS_GetMIC over 721 the following, using the GSSAPI context which was just established: 723 string session identifier 724 byte SSH_MSG_USERAUTH_REQUEST 725 string user name 726 string service 727 string "gssapi-with-mic" 729 If this message is received by the server before the GSSAPI context 730 is fully established, the server MUST fail the authentication. 732 If this message is received by the server when the negotiated GSSAPI 733 context does not support per-message integrity protection, the server 734 MUST fail the authentication. 736 3.6. Client acknowledgement 738 Some servers may wish to permit user authentication to proceed even 739 when the negotitated GSSAPI context does not support per-message 740 integrity protection. In such cases, it is possible for the server 741 to successfully complete the GSSAPI method, while the client's last 742 call to GSS_Init_sec_context fails. If the server simply assumed 743 success on the part of the client and completed the authentication 744 service, it is possible that the client would fail to complete the 745 authentication method, but not be able to retry other methods because 746 the server had already moved on. To protect against this, a final 747 message is sent by the client to indicate it has completed 748 authentication. 750 When the client's call to GSS_Init_sec_context() returns 751 GSS_S_COMPLETE with the integ_avail flag not set, the client MUST 752 conclude the user authentication exchange by sending the following 753 message: 755 byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 757 This message MUST be sent only if GSS_Init_sec_context() returned 758 GSS_S_COMPLETE. If a token is also returned then the 759 SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one. 761 If this message is received by the server before the GSSAPI context 762 is fully established, the server MUST fail the authentication. 764 If this message is received by the server when the negotiated GSSAPI 765 context supports per-message integrity protection, the server MUST 766 fail the authentication. 768 It is a site policy descision for the server whether or not to permit 769 authentication using GSSAPI mechanisms and/or contexts which do not 770 support per-message integrity protection. The server MAY fail the 771 otherwise valid gssapi-with-mic authentication if per-message 772 integrity protection is not supported. 774 3.7. Completion 776 As with all SSH authentication methods, successful completion is 777 indicated by a SSH_MSG_USERAUTH_SUCCESS if no other authentication is 778 required, or a SSH_MSG_USERAUTH_FAILURE with the partial success flag 779 set if the server requires further authentication. This packet 780 SHOULD be sent immediately following receipt of the the 781 SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet. 783 3.8. Error Status 785 In the event a GSSAPI error occurs on the server during context 786 establishment, the server MAY send the following message to inform 787 the client of the details of the error before sending a 788 SSH_MSG_USERAUTH_FAILURE message: 790 byte SSH_MSG_USERAUTH_GSSAPI_ERROR 791 uint32 major_status 792 uint32 minor_status 793 string message 794 string language tag 796 The message text MUST be encoded in the UTF-8 encoding described in 797 [UTF8]. Language tags are those described in [LANGTAG]. Note that 798 the message text may contain multiple lines separated by carriage 799 return-line feed (CRLF) sequences. Application developers should 800 take this into account when displaying these messages. 802 Clients receiving this message MAY log the error details and/or 803 report them to the user. Any server sending this message MUST ignore 804 any SSH_MSG_UNIMPLEMENTED sent by the client in response. 806 3.9. Error Token 808 In the event that, during context establishment, a client's call to 809 GSS_Init_sec_context or a server's call to GSS_Accept_sec_context 810 returns a token along with an error status, the resulting "error 811 token" SHOULD be sent to the peer using the following message: 813 byte SSH_MSG_USERAUTH_GSSAPI_ERRTOK 814 string error token 816 This message implies that the authentication is about to fail, and is 817 defined to allow the error token to be communicated without losing 818 synchronization. 820 When a server sends this message, it MUST be followed by a 821 SSH_MSG_USERAUTH_FAILURE message, which is to be interpreted as 822 applying to the same authentication request. A client receiving this 823 message SHOULD wait for the following SSH_MSG_USERAUTH_FAILURE 824 message before beginning another authentication attempt. 826 When a client sends this message, it MUST be followed by a new 827 authentication request or by terminating the connection. A server 828 receiving this message MUST NOT send a SSH_MSG_USERAUTH_FAILURE in 829 reply, since such a message might otherwise be interpreted by a 830 client as a response to the following authentication sequence. 832 Any server sending this message MUST ignore any SSH_MSG_UNIMPLEMENTED 833 sent by the client in response. If a server sends both this message 834 and an SSH_MSG_USERAUTH_GSSAPI_ERROR message, the 835 SSH_MSG_USERAUTH_GSSAPI_ERROR message MUST be sent first, to allow 836 the client to store and/or display the error status before processing 837 the error token. 839 4. Authentication using GSSAPI Key Exchange 841 This section describes a user authentication method building on the 842 framework described in [SSH-USERAUTH]. This method performs user 843 authentication by making use of an existing GSSAPI context 844 established during key exchange. 846 The authentication method name for this protocol is "gssapi-keyex". 848 This method may be used only if the initial key exchange was 849 performed using a GSSAPI-based key exchange method defined in 850 accordance with Section 2. The GSSAPI context used with this method 851 is always that established during an initial GSSAPI-based key 852 exchange. Any context established during key exchange for the 853 purpose of rekeying MUST NOT be used with this method. 855 The server SHOULD include this user authentication method in the list 856 of methods that can continue (in a SSH_MSG_USERAUTH_FAILURE) if the 857 initial key exchange was performed using a GSSAPI-based key exchange 858 method and provides information about the user's identity which is 859 useful to the server. It MUST NOT include this method if the initial 860 key exchange was not performed using a GSSAPI-based key exchange 861 method defined in accordance with Section 2. 863 The client SHOULD attempt to use this method if it is advertised by 864 the server, initial key exchange was performed using a GSSAPI-based 865 key exchange method, and this method has not already been tried. The 866 client SHOULD NOT try this method more than once per session. It 867 MUST NOT try this method if initial key exchange was not performed 868 using a GSSAPI-based key exchange method defined in accordance with 869 Section 2. 871 If a server receives a request for this method when initial key 872 exchange was not performed using a GSSAPI-based key exchange method 873 defined in accordance with Section 2, it MUST return 874 SSH_MSG_USERAUTH_FAILURE. 876 This method is defined as a single message: 878 byte SSH_MSG_USERAUTH_REQUEST 879 string user name 880 string service 881 string "gssapi-keyex" 882 string MIC 884 The contents of the MIC field are obtained by calling GSS_GetMIC over 885 the following, using the GSSAPI context which was established during 886 initial key exchange: 888 string session identifier 889 byte SSH_MSG_USERAUTH_REQUEST 890 string user name 891 string service 892 string "gssapi-keyex" 894 Upon receiving this message when initial key exchange was performed 895 using a GSSAPI-based key exchange method, the server uses 896 GSS_VerifyMIC() to verify that the MIC received is valid. If the MIC 897 is not valid, the user authentication fails, and the server MUST 898 return SSH_MSG_USERAUTH_FAILURE. 900 If the MIC is valid and the server is satisfied as to the user's 901 credentials, it MAY return either SSH_MSG_USERAUTH_SUCCESS, or 902 SSH_MSG_USERAUTH_FAILURE with the partial success flag set, depending 903 on whether additional authentications are needed. 905 5. Null Host Key Algorithm 907 The "null" host key algorithm has no associated host key material, 908 and provides neither signature nor encryption algorithms. Thus, it 909 can be used only with key exchange methods that do not require any 910 public-key operations and do not require the use of host public key 911 material. The key exchange methods described in Section 2 are 912 examples of such methods. 914 This algorithm is used when, as a matter of configuration, the host 915 does not have or does not wish to use a public key. For example, it 916 can be used when the administrator has decided as a matter of policy 917 to require that all key exchanges be authenticated using Kerberos 918 [KRB5], and thus the only permitted key exchange method is the 919 GSSAPI-authenticated Diffie-Hellman exchange described above, with 920 Kerberos V5 as the underlying GSSAPI mechanism. In such a 921 configuration, the server implementation supports the "ssh-dss" key 922 algorithm (as required by [SSH-TRANSPORT]), but could be prohibited 923 by configuration from using it. In this situation, the server needs 924 some key exchange algorithm to advertise; the "null" algorithm fills 925 this purpose. 927 Note that the use of the "null" algorithm in this way means that the 928 server will not be able to interoperate with clients which do not 929 support this algorithm. This is not a significant problem, since in 930 the configuration described, it will also be unable to interoperate 931 with implementations that do not support the GSSAPI-authenticated key 932 exchange and Kerberos. 934 Any implementation supporting at least one key exchange method which 935 conforms to Section 2 MUST also support the "null" host key 936 algorithm. Servers MUST NOT advertise the "null" host key algorithm 937 unless it is the only algorithm advertised. 939 6. Summary of Message Numbers 941 The following message numbers have been defined for use with GSSAPI- 942 based key exchange methods: 944 #define SSH_MSG_KEXGSS_INIT 30 945 #define SSH_MSG_KEXGSS_CONTINUE 31 946 #define SSH_MSG_KEXGSS_COMPLETE 32 947 #define SSH_MSG_KEXGSS_HOSTKEY 33 948 #define SSH_MSG_KEXGSS_ERROR 34 949 #define SSH_MSG_KEXGSS_GROUPREQ 40 950 #define SSH_MSG_KEXGSS_GROUP 41 952 The numbers 30-49 are specific to key exchange and may be redefined 953 by other kex methods. 955 The following message numbers have been defined for use with the 956 'gssapi-with-mic' user authentication method: 958 #define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60 959 #define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61 960 #define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63 961 #define SSH_MSG_USERAUTH_GSSAPI_ERROR 64 962 #define SSH_MSG_USERAUTH_GSSAPI_ERRTOK 65 963 #define SSH_MSG_USERAUTH_GSSAPI_MIC 66 965 The numbers 60-79 are specific to user authentication and may be 966 redefined by other user auth methods. Note that in the method 967 described in this document, message number 62 is unused. 969 7. GSSAPI Considerations 971 7.1. Naming Conventions 973 In order to establish a GSSAPI security context, the SSH client needs 974 to determine the appropriate targ_name to use in identifying the 975 server when calling GSS_Init_sec_context. For this purpose, the 976 GSSAPI mechanism-independent name form for host-based services is 977 used, as described in section 4.1 of [GSSAPI]. 979 In particular, the targ_name to pass to GSS_Init_sec_context is 980 obtained by calling GSS_Import_name with an input_name_type of 981 GSS_C_NT_HOSTBASED_SERVICE, and an input_name_string consisting of 982 the string "host@" concatenated with the hostname of the SSH server. 984 7.2. Channel Bindings 986 This document recommends that channel bindings SHOULD NOT be 987 specified in the calls during context establishment. This document 988 does not specify any standard data to be used as channel bindings and 989 the use of network addresses as channel bindings may break SSH in 990 environments where it is most useful. 992 7.3. SPNEGO 994 The use of the Simple and Protected GSS-API Negotiation Mechanism 995 [SPNEGO] in conjunction with the authentication and key exchange 996 methods described in this document is both unnecessary and 997 undesirable. As a result, mechanisms conforming to this document 998 MUST NOT use SPNEGO as the underlying GSSAPI mechanism. 1000 Since SSH performs its own negotiation of authentication and key 1001 exchange methods, the negotiation capability of SPNEGO alone does not 1002 provide any added benefit. In fact, as described below, it has the 1003 potential to result in the use of a weaker method than desired. 1005 Normally, SPNEGO provides the added benefit of protecting the GSSAPI 1006 mechanism negotiation. It does this by having the server compute a 1007 MIC of the list of mechanisms proposed by the client, and then 1008 checking that value at the client. In the case of key exchange, this 1009 protection is not needed because the key exchange methods described 1010 here already perform an equivalent operation; namely, they generate a 1011 MIC of the SSH exchange hash, which is a hash of several items 1012 including the lists of key exchange mechanisms supported by both 1013 sides. In the case of user authentication, the protection is not 1014 needed because the negotiation occurs over a secure channel, and the 1015 host's identity has already been proved to the user. 1017 The use of SPNEGO combined with GSSAPI mechanisms used without SPNEGO 1018 can lead to interoperability problems. For example, a client which 1019 supports key exchange using the Kerberos V5 GSSAPI mechanism [KRB5- 1020 GSS] only underneath SPNEGO will not interoperate with a server which 1021 supports key exchange only using the Kerberos V5 GSSAPI mechanism 1022 directly. As a result, allowing GSSAPI mechanisms to be used both 1023 with and without SPNEGO is undesirable. 1025 If a client's policy is to first prefer GSSAPI-based key exchange 1026 method X, then non-GSSAPI method Y, then GSSAPI-based method Z, and 1027 if a server supports mechanisms Y and Z but not X, then an attempt to 1028 use SPNEGO to negotiate a GSSAPI mechanism might result in the use of 1029 method Z when method Y would have been preferable. As a result, the 1030 use of SPNEGO could result in the subversion of the negotiation 1031 algorithm for key exchange methods as described in section 7.1 of 1032 [SSH-TRANSPORT] and/or the negotiation algorithm for user 1033 authentication methods as described in [SSH-USERAUTH]. 1035 8. IANA Considerations 1037 Consistent with section 8 of [SSH-ARCH] and section 4.6 of [SSH- 1038 NUMBERS], this document makes the following registrations: 1040 The family of SSH key exchange method names beginning with "gss- 1041 group1-sha1-" and not containing the at-sign ('@'), to name the 1042 key exchange methods defined in Section 2.3. 1044 The family of SSH key exchange method names beginning with "gss- 1045 gex-sha1-" and not containing the at-sign ('@'), to name the key 1046 exchange methods defined in Section 2.5. 1048 All other SSH key exchange method names beginning with "gss-" and 1049 not containing the at-sign ('@'), to be reserved for future key 1050 exchange methods defined in conformance with this document, as 1051 noted in Section 2.6. 1053 The SSH host public key algorithm name "null", to name the NULL 1054 host key algorithm defined in Section 5. 1056 The SSH user authentication method name "gssapi-with-mic", to name 1057 the GSSAPI user authentication method defined in Section 3. 1059 The SSH user authentication method name "gssapi-keyex", to name 1060 the GSSAPI user authentication method defined in Section 4. 1062 The SSH user authentication method name "gssapi" is to be 1063 reserved, in order to avoid conflicts with implementations 1064 supporting an earlier version of this specification. 1066 The SSH user authentication method name "external-keyx" is to be 1067 reserved, in order to avoid conflicts with implementations 1068 supporting an earlier version of this specification. 1070 This document creates no new registries. 1072 9. Security Considerations 1074 This document describes authentication and key-exchange protocols. 1075 As such, security considerations are discussed throughout. 1077 This protocol depends on the SSH protocol itself, the GSSAPI, any 1078 underlying GSSAPI mechanisms which are used, and any protocols on 1079 which such mechanisms might depend. Each of these components plays a 1080 part in the security of the resulting connection, and each will have 1081 its own security considerations. 1083 The key exchange method described in Section 2 depends on the 1084 underlying GSSAPI mechanism to provide both mutual authentication and 1085 per-message integrity services. If either of these features is not 1086 supported by a particular GSSAPI mechanism, or by a particular 1087 implementation of a GSSAPI mechanism, then the key exchange is not 1088 secure and MUST fail. 1090 In order for the "external-keyx" user authentication method to be 1091 used, it MUST have access to user authentication information obtained 1092 as a side-effect of the key exchange. If this information is 1093 unavailable, the authentication MUST fail. 1095 Revealing information about the reason for an authentication failure 1096 may be considered by some sites to be an unacceptable security risk 1097 for a production environment. However, having that information 1098 available can be invaluable for debugging purposes. Thus, it is 1099 RECOMMENDED that implementations provide a means for controlling, as 1100 a matter of policy, whether to send SSH_MSG_USERAUTH_GSSAPI_ERROR, 1101 SSH_MSG_USERAUTH_GSSAPI_ERRTOK, and SSH_MSG_KEXGSS_ERROR messages, 1102 and SSH_MSG_KEXGSS_CONTINUE messages containing a GSSAPI error token. 1104 10. Acknowledgements 1106 The authors would like to thank the following individuals for their 1107 invaluable assistance and contributions to this document: 1109 o Sam Hartman 1111 o Love Hornquist-Astrand 1113 o Joel N. Weber II 1115 o Simon Wilkinson 1117 o Nicolas Williams 1119 Much of the text describing DH group exchnage was borrowed from 1120 [GROUP-EXCHANGE], by Markus Friedl, Niels Provos, and William A. 1121 Simpson. 1123 11. Changes the last version 1125 This section lists important changes since the previous version of 1126 this internet-draft. This section should be removed at the time of 1127 publication of this document as an RFC. 1129 o Fixed editorial issues raised in WGLC, AD review, and IETF last 1130 call 1132 o Fixed a SHOULD that should have been capitalized but wasn't (per 1133 comments from David Leonard and confirmation from Joseph 1134 Galbraith) 1136 o Updated the reference to 1137 draft-ietf-secsh-dh-group-exchange-05.txt, and corrected for 1138 changes in the section numbering of that document. 1140 12. References 1142 12.1. Normative References 1144 [ASN1] ISO/IEC, "ASN.1 Encoding Rules: Specification of Basic 1145 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1146 Distinguished Encoding Rules (DER)", ITU-T 1147 Recommendation X.690 (1997), ISO/IEC 8825-1:1998, 1148 November 1998. 1150 [GROUP-EXCHANGE] 1151 Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 1152 Group Exchange for the SSH Transport Layer Protocol", 1153 draft-ietf-secsh-dh-group-exchange-05.txt (work in 1154 progress), July 2005. 1156 [GSSAPI] Linn, J., "Generic Security Service Application Program 1157 Interface Version 2, Update 1", RFC 2743, January 2000. 1159 [KEYWORDS] 1160 Bradner, S., "Key words for use in RFCs to Indicate 1161 Requirement Levels", RFC 2119, BCP 14, March 1997. 1163 [LANGTAG] Alvestrand, H., "Tags for the Identification of 1164 Languages", RFC 3066, BCP 47, January 2001. 1166 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1167 April 1992. 1169 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1170 Extensions (MIME) Part One: Format of Internet Message 1171 Bodies", RFC 2045, November 1996. 1173 [SSH-ARCH] 1174 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 1175 draft-ietf-secsh-architecture-22.txt (work in progress), 1176 March 2005. 1178 [SSH-CONNECT] 1179 Ylonen, T. and C. Lonvick, "SSH Connection Protocol", 1180 draft-ietf-secsh-connect-25.txt (work in progress), 1181 March 2005. 1183 [SSH-NUMBERS] 1184 Lehtinen, S. and C. Lonvick, "SSH Connection Protocol", 1185 draft-ietf-secsh-assignednumbers-12.txt (work in 1186 progress), March 2005. 1188 [SSH-TRANSPORT] 1189 Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", 1190 draft-ietf-secsh-transport-24.txt (work in progress), 1191 March 2005. 1193 [SSH-USERAUTH] 1194 Ylonen, T. and C. Lonvick, "SSH Authentication Protocol", 1195 draft-ietf-secsh-userauth-27.txt (work in progress), 1196 March 2005. 1198 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 1199 10646", RFC 3629, STD 63, November 2003. 1201 12.2. Non-Normative References 1203 [KRB5] Kohl, J. and C. Neuman, "The Kerberos Network 1204 Authentication Service (V5)", RFC 1510, September 1993. 1206 [KRB5-GSS] 1207 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1208 RFC 1964, June 1996. 1210 [SPNEGO] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 1211 Negotiation Mechanism", RFC 2478, December 1998. 1213 Authors' Addresses 1215 Jeffrey Hutzelman 1216 Carnegie Mellon University 1217 5000 Forbes Ave 1218 Pittsburgh, PA 15213 1219 US 1221 Phone: +1 412 268 7225 1222 Email: jhutz+@cmu.edu 1223 URI: http://www.cs.cmu.edu/~jhutz/ 1225 Joseph Salowey 1226 Cisco Systems 1227 2901 Third Avenue 1228 Seattle, WA 98121 1229 US 1231 Phone: +1 206 256 3380 1232 Email: jsalowey@cisco.com 1234 Joseph Galbraith 1235 Van Dyke Technologies, Inc. 1236 4848 Tramway Ridge Dr. NE 1237 Suite 101 1238 Albuquerque, NM 87111 1239 US 1241 Email: galb@vandyke.com 1243 Von Welch 1244 University of Chicago & Argonne National Laboratory 1245 Distributed Systems Laboratory 1246 701 E. Washington 1247 Urbana, IL 61801 1248 US 1250 Email: welch@mcs.anl.gov 1252 Intellectual Property Statement 1254 The IETF takes no position regarding the validity or scope of any 1255 Intellectual Property Rights or other rights that might be claimed to 1256 pertain to the implementation or use of the technology described in 1257 this document or the extent to which any license under such rights 1258 might or might not be available; nor does it represent that it has 1259 made any independent effort to identify any such rights. Information 1260 on the procedures with respect to rights in RFC documents can be 1261 found in BCP 78 and BCP 79. 1263 Copies of IPR disclosures made to the IETF Secretariat and any 1264 assurances of licenses to be made available, or the result of an 1265 attempt made to obtain a general license or permission for the use of 1266 such proprietary rights by implementers or users of this 1267 specification can be obtained from the IETF on-line IPR repository at 1268 http://www.ietf.org/ipr. 1270 The IETF invites any interested party to bring to its attention any 1271 copyrights, patents or patent applications, or other proprietary 1272 rights that may cover technology that may be required to implement 1273 this standard. Please address the information to the IETF at 1274 ietf-ipr@ietf.org. 1276 Disclaimer of Validity 1278 This document and the information contained herein are provided on an 1279 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1280 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1281 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1282 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1283 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1284 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1286 Copyright Statement 1288 Copyright (C) The Internet Society (2005). This document is subject 1289 to the rights, licenses and restrictions contained in BCP 78, and 1290 except as set forth therein, the authors retain all their rights. 1292 Acknowledgment 1294 Funding for the RFC Editor function is currently provided by the 1295 Internet Society.