idnits 2.17.1 draft-ietf-secsh-gsskeyex-07.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 : ---------------------------------------------------------------------------- ** 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], [5], [8]), 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 286 has weird spacing: '... string out...' == Line 294 has weird spacing: '... string ser...' == Line 309 has weird spacing: '... string out...' == Line 320 has weird spacing: '... string out...' == Line 334 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 (September 12, 2003) is 7531 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. '1' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-11 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-14 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-11 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-13 ** Obsolete normative reference: RFC 2279 (ref. '10') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 1766 (ref. '11') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1510 (ref. '12') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2478 (ref. '14') (Obsoleted by RFC 4178) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 4 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: March 12, 2004 J. Salowey 5 Cisco Systems 6 J. Galbraith 7 Van Dyke Technologies, Inc. 8 V. Welch 9 U Chicago / ANL 10 September 12, 2003 12 GSSAPI Authentication and Key Exchange for the Secure Shell Protocol 13 draft-ietf-secsh-gsskeyex-07 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 12, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 The Secure Shell protocol (SSH) is a protocol for secure remote login 44 and other secure network services over an insecure network. 46 The Generic Security Service Application Program Interface (GSS-API) 47 [2] provides security services to callers in a mechanism-independent 48 fashion. 50 This memo describes methods for using the GSS-API for authentication 51 and key exchange in SSH. It defines an SSH user authentication method 52 which uses a specified GSSAPI mechanism to authenticate a user, and a 53 family of SSH key exchange methods which use GSSAPI to authenticate 54 the Diffie-Hellman exchange described in [8]. 56 This memo also defines a new host public key algorithm which can be 57 used when no operations are needed using a host's public key, and a 58 new user authentication method which allows an authorization name to 59 be used in conjunction with any authentication which has already 60 occurred as a side-effect of GSSAPI-based key exchange. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [5]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1 SSH terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. GSSAPI Authenticated Diffie-Hellman Key Exchange . . . . . . . 5 71 2.1 Generic GSSAPI Key Exchange . . . . . . . . . . . . . . . . . 5 72 2.2 gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . . . 10 73 2.3 Other GSSAPI key exchange methods . . . . . . . . . . . . . . 11 74 3. GSSAPI User Authentication . . . . . . . . . . . . . . . . . . 12 75 3.1 GSSAPI Authentication Overview . . . . . . . . . . . . . . . . 12 76 3.2 Initiating GSSAPI authentication . . . . . . . . . . . . . . . 12 77 3.3 Initial server response . . . . . . . . . . . . . . . . . . . 13 78 3.4 GSSAPI session . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.5 Binding Encryption Keys . . . . . . . . . . . . . . . . . . . 14 80 3.6 Client acknowledgement . . . . . . . . . . . . . . . . . . . . 15 81 3.7 Completion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 3.8 Error Status . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 3.9 Error Token . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 4. Authentication using GSSAPI Key Exchange . . . . . . . . . . . 18 85 5. Null Host Key Algorithm . . . . . . . . . . . . . . . . . . . 20 86 6. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 21 87 7. GSSAPI Considerations . . . . . . . . . . . . . . . . . . . . 22 88 7.1 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 22 89 7.2 Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 22 90 7.3 SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 94 11. Changes the last version . . . . . . . . . . . . . . . . . . . 27 95 Normative References . . . . . . . . . . . . . . . . . . . . . 28 96 Normative References . . . . . . . . . . . . . . . . . . . . . 29 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 98 Intellectual Property and Copyright Statements . . . . . . . . 31 100 1. Introduction 102 This document describes the methods used to perform key exchange and 103 user authentication in the Secure Shell protocol using the GSSAPI. 104 To do this, it defines a family of key exchange methods, two user 105 authentication methods, and a new host key algorithm. These 106 definitions allow any GSSAPI mechanism to be used with the Secure 107 Shell protocol. 109 This document should be read only after reading the documents 110 describing the SSH protocol architecture [6], transport layer 111 protocol [8], and user authentication protocol [9]. This document 112 freely uses terminology and notation from the architecture document 113 without reference or further explanation. 115 1.1 SSH terminology 117 The data types used in the packets are defined in the SSH 118 architecture document [6]. It is particularly important to note the 119 definition of string allows binary content. 121 The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this service 122 name is an SSH service name, and has no relationship to GSSAPI 123 service names. Currently, the only defined service name is 124 "ssh-connection", which refers to the SSH connection protocol [7]. 126 2. GSSAPI Authenticated Diffie-Hellman Key Exchange 128 This section defines a class of key exchange methods which combine 129 the Diffie-Hellman key exchange from section 6 of [8] with mutual 130 authentication using GSSAPI. 132 Since the GSSAPI key exchange methods described in this section do 133 not require the use of public key signature or encryption algorithms, 134 they MAY be used with any host key algorithm, including the "null" 135 algorithm described in Section 5. 137 2.1 Generic GSSAPI Key Exchange 139 The following symbols are used in this description: 141 o C is the client, and S is the server 143 o p is a large safe prime, g is a generator for a subgroup of GF(p), 144 and q is the order of the subgroup 146 o V_S is S's version string, and V_C is C's version string 148 o I_C is C's KEXINIT message, and I_S is S's KEXINIT message 150 1. C generates a random number x (1 < x < q) and computes e = g^x 151 mod p. 153 2. C calls GSS_Init_sec_context, using the most recent reply token 154 received from S during this exchange, if any. For this call, the 155 client MUST set the mutual_req_flag to "true" to request that 156 mutual authentication be performed. It also MUST set the 157 integ_req_flag to "true" to request that per-message integrity 158 protection be supported for this context. In addition, the 159 deleg_req_flag MAY be set to "true" to request access delegation, 160 if requested by the user. Since the key exchange process 161 authenticates only the host, the setting of the anon_req_flag is 162 immaterial to this process. If the client does not support the 163 "gssapi-keyex" user authentication method described in Section 4, 164 or does not intend to use that method in conjunction with the 165 GSSAPI context established during key exchange, then the 166 anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY 167 be set to true if the client wishes to hide its identity. Since 168 the key exchange process will involve the exchange of only a 169 single token once the context has been established, it is not 170 necessary that the GSSAPI context support detection of replayed 171 or out-of-sequence tokens. Thus, the setting of the 172 replay_det_req_flag and sequence_req_flag are not needed for this 173 process. These flags SHOULD be set to "false". 175 * If the resulting major_status code is GSS_S_COMPLETE and the 176 mutual_state flag is not true, then mutual authentication has 177 not been established, and the key exchange MUST fail. 179 * If the resulting major_status code is GSS_S_COMPLETE and the 180 integ_avail flag is not true, then per-message integrity 181 protection is not available, and the key exchange MUST fail. 183 * If the resulting major_status code is GSS_S_COMPLETE and both 184 the mutual_state and integ_avail flags are true, the resulting 185 output token is sent to S. 187 * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, 188 the the output_token is sent to S, which will reply with a new 189 token to be provided to GSS_Init_sec_context. 191 * The client MUST also include "e" with the first message it 192 sends to the server during this process; if the server 193 receives more than one "e" or none at all, the key exchange 194 fails. 196 * It is an error if the call does not produce a token of 197 non-zero length to be sent to the server. In this case, the 198 key exchange MUST fail. 200 3. S calls GSS_Accept_sec_context, using the token received from C. 202 * If the resulting major_status code is GSS_S_COMPLETE and the 203 mutual_state flag is not true, then mutual authentication has 204 not been established, and the key exchange MUST fail. 206 * If the resulting major_status code is GSS_S_COMPLETE and the 207 integ_avail flag is not true, then per-message integrity 208 protection is not available, and the key exchange MUST fail. 210 * If the resulting major_status code is GSS_S_COMPLETE and both 211 the mutual_state and integ_avail flags are true, then the 212 security context has been established, and processing 213 continues with step 4. 215 * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, 216 then the output token is sent to C, and processing continues 217 with step 2. 219 * If the resulting major_status code is GSS_S_COMPLETE, but a 220 non-zero-length reply token is returned, then that token is 221 sent to the client. 223 4. S generates a random number y (0 < y < q) and computes f = g^y 224 mod p. It computes K = e ^ y mod p, and H = hash(V_C || V_S || 225 I_C || I_S || K_S || e || f || K). It then calls GSS_GetMIC to 226 obtain a GSSAPI message integrity code for H. S then sends f and 227 the MIC to C. 229 5. This step is performed only if the server's final call to 230 GSS_Accept_sec_context produced a non-zero-length final reply 231 token to be sent to the client _and_ no previous call by the 232 client to GSS_Init_sec_context has resulted in a major_status of 233 GSS_S_COMPLETE. Under these conditions, the client makes an 234 additional call to GSS_Init_sec_context to process the final 235 reply token. This call is made exactly as described above. 236 However, if the resulting major_status is anything other than 237 GSS_S_COMPLETE, or a non-zero-length token is returned, it is an 238 error and the key exchange MUST fail. 240 6. C computes K = f^x mod p, and H = hash(V_C || V_S || I_C || I_S 241 || K_S || e || f || K). It then calls GSS_VerifyMIC to verify 242 that the MIC sent by S matches H. If the MIC is not successfully 243 verified, the key exchange MUST fail. 245 Either side MUST NOT send or accept e or f values that are not in the 246 range [1, p-1]. If this condition is violated, the key exchange 247 fails. 249 If any call to GSS_Init_sec_context or GSS_Accept_sec_context returns 250 a major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or 251 any other GSSAPI call returns a major_status other than 252 GSS_S_COMPLETE, the key exchange fails. In this case, several 253 mechanisms are available for communicating error information to the 254 peer before terminating the connection as required by [8]: 256 o If the key exchange fails due to any GSSAPI error on the server 257 (including errors returned by GSS_Accept_sec_context), the server 258 MAY send a message informing the client of the details of the 259 error. In this case, if an error token is also sent (see below), 260 then this message MUST be sent before the error token. 262 o If the key exchange fails due to a GSSAPI error returned from the 263 server's call to GSS_Accept_sec_context, and an "error token" is 264 also returned, then the server SHOULD send the error token to the 265 client to allow completion of the GSS security exchange. 267 o If the key exchange fails due to a GSSAPI error returned from the 268 client's call to GSS_Init_sec_context, and an "error token" is 269 also returned, then the client SHOULD send the error token to the 270 server to allow completion of the GSS security exchange. 272 As noted in Section 9, it may be desirable under site security policy 273 to obscure information about the precise nature of the error; thus, 274 it is RECOMMENDED that implementations provide a method to suppress 275 these messages as a matter of policy. 277 This is implemented with the following messages. The hash algorithm 278 for computing the exchange hash is defined by the method name, and is 279 called HASH. The group used for Diffie-Hellman key exchange and the 280 underlying GSSAPI mechanism are also defined by the method name. 282 After the client's first call to GSS_Init_sec_context, it sends the 283 following: 285 byte SSH_MSG_KEXGSS_INIT 286 string output_token (from GSS_Init_sec_context) 287 mpint e 289 Upon receiving the SSH_MSG_KEXGSS_INIT message, the server MAY send 290 the following message, prior to any other messages, to inform the 291 client of its host key. 293 byte SSH_MSG_KEXGSS_HOSTKEY 294 string server public host key and certificates (K_S) 296 Since this key exchange method does not require the host key to be 297 used for any encryption operations, this message is OPTIONAL. If the 298 "null" host key algorithm described in Section 5 is used, this 299 message MUST NOT be sent. If this message is sent, the server public 300 host key(s) and/or certificate(s) in this message are encoded as a 301 single string, in the format specified by the public key type in use 302 (see [8], section 4.6). 304 Each time the server's call to GSS_Accept_sec_context returns a 305 major_status code of GSS_S_CONTINUE_NEEDED, it sends the following 306 reply to the client: 308 byte SSH_MSG_KEXGSS_CONTINUE 309 string output_token (from GSS_Accept_sec_context) 311 If the client receives this message after a call to 312 GSS_Init_sec_context has returned a major_status code of 313 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 314 MUST fail. 316 Each time the client receives the message described above, it makes 317 another call to GSS_Init_sec_context. It then sends the following: 319 byte SSH_MSG_KEXGSS_CONTINUE 320 string output_token (from GSS_Init_sec_context) 322 The server and client continue to trade these two messages as long as 323 the server's calls to GSS_Accept_sec_context result in major_status 324 codes of GSS_S_CONTINUE_NEEDED. When a call results in a 325 major_status code of GSS_S_COMPLETE, it sends one of two final 326 messages. 328 If the server's final call to GSS_Accept_sec_context (resulting in a 329 major_status code of GSS_S_COMPLETE) returns a non-zero-length token 330 to be sent to the client, it sends the following: 332 byte SSH_MSG_KEXGSS_COMPLETE 333 mpint f 334 string per_msg_token (MIC of H) 335 boolean TRUE 336 string output_token (from GSS_Accept_sec_context) 338 If the client receives this message after a call to 339 GSS_Init_sec_context has returned a major_status code of 340 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 341 MUST fail. 343 If the server's final call to GSS_Accept_sec_context (resulting in a 344 major_status code of GSS_S_COMPLETE) returns a zero-length token or 345 no token at all, it sends the following: 347 byte SSH_MSG_KEXGSS_COMPLETE 348 mpint f 349 string per_msg_token (MIC of H) 350 boolean FALSE 352 If the client receives this message when no call to 353 GSS_Init_sec_context has yet resulted in a major_status code of 354 GSS_S_COMPLETE, a protocol error has occurred and the key exchange 355 MUST fail. 357 If either the client's call to GSS_Init_sec_context or the server's 358 call to GSS_Accept_sec_context returns an error status and produces 359 an output token (called an "error token"), then the following SHOULD 360 be sent to convey the error information to the peer: 362 byte SSH_MSG_KEXGSS_CONTINUE 363 string error_token 365 If a server sends both this message and an SSH_MSG_KEXGSS_ERROR 366 message, the SSH_MSG_KEXGSS_ERROR message MUST be sent first, to 367 allow clients to record and/or display the error information before 368 processing the error token. This is important because a client 369 processing an error token will likely disconnect without reading any 370 further messages. 372 In the event of a GSSAPI error on the server, the server MAY send the 373 following message before terminating the connection: 375 byte SSH_MSG_KEXGSS_ERROR 376 uint32 major_status 377 uint32 minor_status 378 string message 379 string language tag 381 The message text MUST be encoded in the UTF-8 encoding described in 382 [10]. Language tags are those described in [11]. Note that the 383 message text may contain multiple lines separated by carriage 384 return-line feed (CRLF) sequences. Application developers should 385 take this into account when displaying these messages. 387 The hash H is computed as the HASH hash of the concatenation of the 388 following: 390 string V_C, the client's version string (CR and NL excluded) 391 string V_S, the server's version string (CR and NL excluded) 392 string I_C, the payload of the client's SSH_MSG_KEXINIT 393 string I_S, the payload of the server's SSH_MSG_KEXINIT 394 string K_S, the host key 395 mpint e, exchange value sent by the client 396 mpint f, exchange value sent by the server 397 mpint K, the shared secret 399 This value is called the exchange hash, and it is used to 400 authenticate the key exchange. The exchange hash SHOULD be kept 401 secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 402 server or received by the client, then the empty string is used in 403 place of K_S when computing the exchange hash. 405 The GSS_GetMIC call MUST be applied over H, not the original data. 407 2.2 gss-group1-sha1-* 409 Each of these methods specifies GSSAPI authenticated Diffie-Hellman 410 key exchange as described in Section 2.1 with SHA-1 as HASH, and the 411 group defined in section 6.1 of [8]. The method name for each method 412 is the concatenation of the string "gss-group1-sha1-" with the Base64 413 encoding of the MD5 hash [3] of the ASN.1 DER encoding [1] of the 414 underlying GSSAPI mechanism's OID. Base64 encoding is described in 415 section 6.8 of [4]. 417 Each and every such key exchange method is implicitly registered by 418 this specification. The IESG is considered to be the owner of all 419 such key exchange methods; this does NOT imply that the IESG is 420 considered to be the owner of the underlying GSSAPI mechanism. 422 2.3 Other GSSAPI key exchange methods 424 Key exchange method names starting with "gss-" are reserved for key 425 exchange methods which conform to this document; in particular, for 426 those methods which use the GSSAPI authenticated Diffie-Hellman key 427 exchange algorithm described in Section 2.1, including any future 428 methods which use different groups and/or hash functions. The intent 429 is that the names for any such future methods methods be defined in a 430 similar manner to that used in Section 2.2. 432 3. GSSAPI User Authentication 434 This section describes a general-purpose user authentication method 435 based on [2]. It is intended to be run over the SSH user 436 authentication protocol [9]. 438 The authentication method name for this protocol is 439 "gssapi-with-mic". 441 3.1 GSSAPI Authentication Overview 443 GSSAPI authentication must maintain a context. Authentication begins 444 when the client sends a SSH_MSG_USERAUTH_REQUEST, which specifies the 445 mechanism OIDs the client supports. 447 If the server supports any of the requested mechanism OIDs, the 448 server sends a SSH_MSG_USERAUTH_GSSAPI_RESPONSE message containing 449 the mechanism OID. 451 After the client receives SSH_MSG_USERAUTH_GSSAPI_RESPONSE, the 452 client and server exchange SSH_MSG_USERAUTH_GSSAPI_TOKEN packets 453 until the authentication mechanism either succeeds or fails. 455 If at any time during the exchange, the client sends a new 456 SSH_MSG_USERAUTH_REQUEST packet, the GSSAPI context is completely 457 discarded and destroyed, and any further GSSAPI authentication MUST 458 restart from the beginning. 460 3.2 Initiating GSSAPI authentication 462 The GSSAPI authentication method is initiated when the client sends a 463 SSH_MSG_USERAUTH_REQUEST: 465 byte SSH_MSG_USERAUTH_REQUEST 466 string user name (in ISO-10646 UTF-8 encoding) 467 string service name (in US-ASCII) 468 string "gssapi-with-mic" (US-ASCII method name) 469 uint32 n, the number of mechanism OIDs client supports 470 string[n] mechanism OIDs 472 Mechanism OIDs are encoded according to the ASN.1 distinguished 473 encoding rules (DER), as described in [1] and in section 3.1 of [2]. 474 The mechanism OIDs MUST be listed in order of preference, and the 475 server must choose the first mechanism OID on the list that it 476 supports. 478 The client SHOULD send GSSAPI mechanism OID's only for mechanisms 479 which are of the same priority, compared to non-GSSAPI authentication 480 methods. Otherwise, authentication methods may be executed out of 481 order. Thus, the client could first send a SSH_MSG_USERAUTH_REQUEST 482 for one GSSAPI mechanism, then try public key authentication, and 483 then try another GSSAPI mechanism. 485 If the server does not support any of the specified OIDs, the server 486 MUST fail the request by sending a SSH_MSG_USERAUTH_FAILURE packet. 488 The user name may be an empty string if it can be deduced from the 489 results of the GSSAPI authentication. If the user name is not empty, 490 and the requested user does not exist, the server MAY disconnect, or 491 MAY send a bogus list of acceptable authentications but never accept 492 any. This makes it possible for the server to avoid disclosing 493 information about which accounts exist. In any case, if the user 494 does not exist, the authentication request MUST NOT be accepted. 496 The client MAY at any time continue with a new 497 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 498 abandon the previous authentication attempt and continue with the new 499 one. 501 3.3 Initial server response 503 The server responds to the SSH_MSG_USERAUTH_REQUEST with either a 504 SSH_MSG_USERAUTH_FAILURE if none of the mechanisms are supported, or 505 with SSH_MSG_USERAUTH_GSSAPI_RESPONSE as follows: 507 byte SSH_MSG_USERAUTH_GSSAPI_RESPONSE 508 string selected mechanism OID 510 The mechanism OID must be one of the OIDs sent by the client in the 511 SSH_MSG_USERAUTH_REQUEST packet. 513 3.4 GSSAPI session 515 Once the mechanism OID has been selected, the client will then 516 initiate an exchange of one or more pairs of 517 SSH_MSG_USERAUTH_GSSAPI_TOKEN packets. These packets contain the 518 tokens produced from the 'GSS_Init_sec_context()' and 519 'GSS_Accept_sec_context()' calls. The actual number of packets 520 exchanged is determined by the underlying GSSAPI mechanism. 522 byte SSH_MSG_USERAUTH_GSSAPI_TOKEN 523 string data returned from either GSS_Init_sec_context() 524 or GSS_Accept_sec_context() 526 If an error occurs during this exchange on server side, the server 527 can terminate the method by sending a SSH_MSG_USERAUTH_FAILURE 528 packet. If an error occurs on client side, the client can terminate 529 the method by sending a new SSH_MSG_USERAUTH_REQUEST packet. 531 When calling GSS_Init_sec_context(), the client MUST set the the 532 integ_req_flag to "true" to request that per-message integrity 533 protection be supported for this context. In addition, the 534 deleg_req_flag MAY be set to "true" to request access delegation, if 535 requested by the user. 537 Since the user authentication process by its nature authenticates 538 only the client, the setting of the mutual_req_flag is not needed for 539 this process. This flag SHOULD be set to "false". 541 Since the user authentication process will involve the exchange of 542 only a single token once the context has been established, it is not 543 necessary that the context support detection of replayed or 544 out-of-sequence tokens. Thus, the setting of the replay_det_req_flag 545 and sequence_req_flag are not needed for this process. These flags 546 SHOULD be set to "false". 548 Additional SSH_MSG_USERAUTH_GSSAPI_TOKEN messages are sent if and 549 only if the calls to the GSSAPI routines produce send tokens of 550 non-zero length. 552 Any major status code other than GSS_S_COMPLETE or 553 GSS_S_CONTINUE_NEEDED SHOULD be a failure. 555 3.5 Binding Encryption Keys 557 In some cases, it is possible to obtain improved security by allowing 558 access only if the client sends a valid message integrity code (MIC) 559 binding the GSSAPI context to the keys used for encryption and 560 integrity protection of the SSH session. With this extra level of 561 protection, a "man-in-the-middle" attacker who has convinced a client 562 of his authenticity cannot then relay user authentication messages 563 between the real client and server, thus gaining access to the real 564 server. This additional protection is available when the negotiated 565 GSSAPI context supports per-message integrity protection, as 566 indicated by the setting of the integ_avail flag on successful return 567 from GSS_Init_sec_context() or GSS_Accept_sec_context(). 569 When the client's call to GSS_Init_sec_context() returns 570 GSS_S_COMPLETE with the integ_avail flag set, the client MUST 571 conclude the user authentication exchange by sending the following 572 message: 574 byte SSH_MSG_USERAUTH_GSSAPI_MIC 575 string MIC 577 This message MUST be sent only if GSS_Init_sec_context() returned 578 GSS_S_COMPLETE. If a token is also returned then the 579 SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one. 581 The contents of the MIC field are obtained by calling GSS_GetMIC over 582 the following, using the GSSAPI context which was just established: 584 string session identifier 585 byte SSH_MSG_USERAUTH_REQUEST 586 string user name 587 string service 588 string "gssapi-with-mic" 590 If this message is received by the server before the GSSAPI context 591 is fully established, the server MUST fail the authentication. 593 If this message is received by the server when the negotiated GSSAPI 594 context does not support per-message integrity protection, the server 595 MUST fail the authentication. 597 3.6 Client acknowledgement 599 Some servers may wish to permit user authentication to proceed even 600 when the negotitated GSSAPI context does not support per-message 601 integrity protection. In such cases, it is possible for the server 602 to successfully complete the GSSAPI method, while the client's last 603 call to GSS_Init_sec_context fails. If the server simply assumed 604 success on the part of the client and completed the authentication 605 service, it is possible that the client would fail to complete the 606 authentication method, but not be able to retry other methods because 607 the server had already moved on. To protect against this, a final 608 message is sent by the client to indicate it has completed 609 authentication. 611 When the client's call to GSS_Init_sec_context() returns 612 GSS_S_COMPLETE with the integ_avail flag not set, the client MUST 613 conclude the user authentication exchange by sending the following 614 message: 616 byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 618 This message MUST be sent only if GSS_Init_sec_context() returned 619 GSS_S_COMPLETE. If a token is also returned then the 620 SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one. 622 If this message is received by the server before the GSSAPI context 623 is fully established, the server MUST fail the authentication. 625 If this message is received by the server when the negotiated GSSAPI 626 context supports per-message integrity protection, the server MUST 627 fail the authentication. 629 It is a site policy descision for the server whether or not to permit 630 authentication using GSSAPI mechanisms and/or contexts which do not 631 support per-message integrity protection. The server MAY fail the 632 otherwise valid gssapi-with-mic authentication if per-message 633 integrity protection is not supported. 635 3.7 Completion 637 As with all SSH authentication methods, successful completion is 638 indicated by a SSH_MSG_USERAUTH_SUCCESS if no other authentication is 639 required, or a SSH_MSG_USERAUTH_FAILURE with the partial success flag 640 set if the server requires further authentication. This packet 641 should be sent immediately following receipt of the the 642 SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet. 644 3.8 Error Status 646 In the event a GSSAPI error occurs on the server during context 647 establishment, the server MAY send the following message to inform 648 the client of the details of the error before sending a 649 SSH_MSG_USERAUTH_FAILURE message: 651 byte SSH_MSG_USERAUTH_GSSAPI_ERROR 652 uint32 major_status 653 uint32 minor_status 654 string message 655 string language tag 657 The message text MUST be encoded in the UTF-8 encoding described in 658 [10]. Language tags are those described in [11]. Note that the 659 message text may contain multiple lines separated by carriage 660 return-line feed (CRLF) sequences. Application developers should take 661 this into account when displaying these messages. 663 Clients receiving this message MAY log the error details and/or 664 report them to the user. Any server sending this message MUST ignore 665 any SSH_MSG_UNIMPLEMENTED sent by the client in response. 667 3.9 Error Token 669 In the event that, during context establishment, a client's call to 670 GSS_Init_sec_context or a server's call to GSS_Accept_sec_context 671 returns a token along with an error status, the resulting "error 672 token" SHOULD be sent to the peer using the following message: 674 byte SSH_MSG_USERAUTH_GSSAPI_ERRTOK 675 string error token 677 This message implies that the authentication is about to fail, and is 678 defined to allow the error token to be communicated without losing 679 synchronization. 681 When a server sends this message, it MUST be followed by a 682 SSH_MSG_USERAUTH_FAILURE message, which is to be interpreted as 683 applying to the same authentication request. A client receiving this 684 message SHOULD wait for the following SSH_MSG_USERAUTH_FAILURE 685 message before beginning another authentication attempt. 687 When a client sends this message, it MUST be followed by a new 688 authentication request or by terminating the connection. A server 689 receiving this message MUST NOT send a SSH_MSG_USERAUTH_FAILURE in 690 reply, since such a message might otherwise be interpreted by a 691 client as a response to the following authentication sequence. 693 Any server sending this message MUST ignore any SSH_MSG_UNIMPLEMENTED 694 sent by the client in response. If a server sends both this message 695 and an SSH_MSG_USERAUTH_GSSAPI_ERROR message, the 696 SSH_MSG_USERAUTH_GSSAPI_ERROR message MUST be sent first, to allow 697 the client to store and/or display the error status before processing 698 the error token. 700 4. Authentication using GSSAPI Key Exchange 702 This section describes a user authentication method building on the 703 framework described in [9]. This method performs user authentication 704 by making use of an existing GSSAPI context established during key 705 exchange. 707 The authentication method name for this protocol is "gssapi-keyex". 709 This method may be used only if the initial key exchange was 710 performed using a GSSAPI-based key exchange method defined in 711 accordance with Section 2. The GSSAPI context used with this method 712 is always that established during an initial GSSAPI-based key 713 exchange. Any context established during key exchange for the 714 purpose of rekeying MUST NOT be used with this method. 716 The server SHOULD include this user authentication method in the list 717 of methods that can continue (in a SSH_MSG_USERAUTH_FAILURE) if the 718 initial key exchange was performed using a GSSAPI-based key exchange 719 method and provides information about the user's identity which is 720 useful to the server. It MUST NOT include this method if the initial 721 key exchange was not performed using a GSSAPI-based key exchange 722 method defined in accordance with Section 2. 724 The client SHOULD attempt to use this method if it is advertised by 725 the server, initial key exchange was performed using a GSSAPI-based 726 key exchange method, and this method has already been tried. The 727 client SHOULD NOT try this method more than once per session. It 728 MUST NOT try this method if initial key exchange was not performed 729 using a GSSAPI-based key exchange method defined in accordance with 730 Section 2. 732 If a server receives a request for this method when initial key 733 exchange was not performed using a GSSAPI-based key exchange method 734 defined in accordance with Section 2, it MUST return 735 SSH_MSG_USERAUTH_FAILURE. 737 This method is defined as a single message: 739 byte SSH_MSG_USERAUTH_REQUEST 740 string user name 741 string service 742 string "gssapi-keyex" 743 string MIC 745 The contents of the MIC field are obtained by calling GSS_GetMIC over 746 the following, using the GSSAPI context which was established during 747 initial key exchange: 749 string session identifier 750 byte SSH_MSG_USERAUTH_REQUEST 751 string user name 752 string service 753 string "gssapi-keyex" 755 Upon receiving this message when initial key exchange was performed 756 using a GSSAPI-based key exchange method, the server uses 757 GSS_VerifyMIC() to verify that the MIC received is valid. If the MIC 758 is not valid, the user authentication fails, and the server MUST 759 return SSH_MSG_USERAUTH_FAILURE. 761 If the MIC is valid and the server is satisfied as to the user's 762 credentials, it MAY return either SSH_MSG_USERAUTH_SUCCESS, or 763 SSH_MSG_USERAUTH_FAILURE with the partial success flag set, depending 764 on whether additional authentications are needed. 766 5. Null Host Key Algorithm 768 The "null" host key algorithm has no associated host key material, 769 and provides neither signature nor encryption algorithms. Thus, it 770 can be used only with key exchange methods that do not require any 771 public-key operations and do not require the use of host public key 772 material. The key exchange methods described in section 1 of this 773 document are examples of such methods. 775 This algorithm is used when, as a matter of configuration, the host 776 does not have or does not wish to use a public key. For example, it 777 can be used when the administrator has decided as a matter of policy 778 to require that all key exchanges be authenticated using Kerberos 779 [12], and thus the only permitted key exchange method is the 780 GSSAPI-authenticated Diffie-Hellman exchange described above, with 781 Kerberos V5 as the underlying GSSAPI mechanism. In such a 782 configuration, the server implementation supports the "ssh-dss" key 783 algorithm (as required by [8]), but could be prohibited by 784 configuration from using it. In this situation, the server needs 785 some key exchange algorithm to advertise; the "null" algorithm fills 786 this purpose. 788 Note that the use of the "null" algorithm in this way means that the 789 server will not be able to interoperate with clients which do not 790 support this algorithm. This is not a significant problem, since in 791 the configuration described, it will also be unable to interoperate 792 with implementations that do not support the GSSAPI-authenticated key 793 exchange and Kerberos. 795 Any implementation supporting at least one key exchange method which 796 conforms to section 1 of this document MUST also support the "null" 797 host key algorithm. Servers MUST NOT advertise the "null" host key 798 algorithm unless it is the only algorithm advertised. 800 6. Summary of Message Numbers 802 The following message numbers have been defined for use with 803 GSSAPI-based key exchange methods: 805 #define SSH_MSG_KEXGSS_INIT 30 806 #define SSH_MSG_KEXGSS_CONTINUE 31 807 #define SSH_MSG_KEXGSS_COMPLETE 32 808 #define SSH_MSG_KEXGSS_HOSTKEY 33 809 #define SSH_MSG_KEXGSS_ERROR 34 811 The numbers 30-49 are specific to key exchange and may be redefined 812 by other kex methods. 814 The following message numbers have been defined for use with the 815 'gssapi' user authentication method: 817 #define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60 818 #define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61 819 #define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63 820 #define SSH_MSG_USERAUTH_GSSAPI_ERROR 64 821 #define SSH_MSG_USERAUTH_GSSAPI_ERRTOK 65 822 #define SSH_MSG_USERAUTH_GSSAPI_MIC 66 824 The numbers 60-79 are specific to user authentication and may be 825 redefined by other user auth methods. Note that in the method 826 described in this document, message number 62 is unused. 828 7. GSSAPI Considerations 830 7.1 Naming Conventions 832 In order to establish a GSSAPI security context, the SSH client needs 833 to determine the appropriate targ_name to use in identifying the 834 server when calling GSS_Init_sec_context. For this purpose, the 835 GSSAPI mechanism-independent name form for host-based services is 836 used, as described in section 4.1 of [2]. 838 In particular, the targ_name to pass to GSS_Init_sec_context is 839 obtained by calling GSS_Import_name with an input_name_type of 840 GSS_C_NT_HOSTBASED_SERVICE, and an input_name_string consisting of 841 the string "host@" concatenated with the hostname of the SSH server. 843 7.2 Channel Bindings 845 This document recommends that channel bindings SHOULD NOT be 846 specified in the calls during context establishment. This document 847 does not specify any standard data to be used as channel bindings and 848 the use of network addresses as channel bindings may break SSH in 849 environments where it is most useful. 851 7.3 SPNEGO 853 The use of the Simple and Protected GSS-API Negotiation Mechanism 854 [14] in conjunction with the authentication and key exchange methods 855 described in this document is both unnecessary and undesirable. As a 856 result, mechanisms conforming to this document MUST NOT use SPNEGO as 857 the underlying GSSAPI mechanism. 859 Since SSH performs its own negotiation of authentication and key 860 exchange methods, the negotiation capability of SPNEGO alone does not 861 provide any added benefit. In fact, as described below, it has the 862 potential to result in the use of a weaker method than desired. 864 Normally, SPNEGO provides the added benefit of protecting the GSSAPI 865 mechanism negotiation. It does this by having the server compute a 866 MIC of the list of mechanisms proposed by the client, and then 867 checking that value at the client. In the case of key exchange, this 868 protection is not needed because the key exchange methods described 869 here already perform an equivalent operation; namely, they generate a 870 MIC of the SSH exchange hash, which is a hash of several items 871 including the lists of key exchange mechanisms supported by both 872 sides. In the case of user authentication, the protection is not 873 needed because the negotiation occurs over a secure channel, and the 874 host's identity has already been proved to the user. 876 The use of SPNEGO combined with GSSAPI mechanisms used without SPNEGO 877 can lead to interoperability problems. For example, a client which 878 supports key exchange using the Kerberos V5 GSSAPI mechanism [13] 879 only underneath SPNEGO will not interoperate with a server which 880 supports key exchange only using the Kerberos V5 GSSAPI mechanism 881 directly. As a result, allowing GSSAPI mechanisms to be used both 882 with and without SPNEGO is undesirable. 884 If a client's policy is to first prefer GSSAPI-based key exchange 885 method X, then non-GSSAPI method Y, then GSSAPI-based method Z, and 886 if a server supports mechanisms Y and Z but not X, then an attempt to 887 use SPNEGO to negotiate a GSSAPI mechanism might result in the use of 888 method Z when method Y would have been preferable. As a result, the 889 use of SPNEGO could result in the subversion of the negotiation 890 algorithm for key exchange methods as described in section 5.1 of [8] 891 and/or the negotiation algorithm for user authentication methods as 892 described in [9]. 894 8. IANA Considerations 896 Consistent with section 7 of [6], the IANA is directed to make the 897 following registrations: 899 The family of SSH key exchange method names beginning with 900 "gss-group1-sha1-" and not containing the at-sign ('@'), to name 901 the key exchange methods defined in Section 2.2. 903 All other SSH key exchange method names beginning with "gss-" and 904 not containing the at-sign ('@'), to be reserved for future key 905 exchange methods defined in conformance with this document, as 906 noted in Section 2.3. 908 The SSH host public key algorithm name "null", to name the NULL 909 host key algorithm defined in Section 5. 911 The SSH user authentication method name "gssapi-with-mic", to name 912 the GSSAPI user authentication method defined in Section 3. 914 The SSH user authentication method name "gssapi-keyex", to name 915 the GSSAPI user authentication method defined in Section 4. 917 The SSH user authentication method name "gssapi" is to be 918 reserved, in order to avoid conflicts with implementations 919 supporting an earlier version of this specification. 921 The SSH user authentication method name "external-keyx" is to be 922 reserved, in order to avoid conflicts with implementations 923 supporting an earlier version of this specification. 925 This document creates no new registries. 927 9. Security Considerations 929 This document describes authentication and key-exchange protocols. As 930 such, security considerations are discussed throughout. 932 This protocol depends on the SSH protocol itself, the GSSAPI, any 933 underlying GSSAPI mechanisms which are used, and any protocols on 934 which such mechanisms might depend. Each of these components plays a 935 part in the security of the resulting connection, and each will have 936 its own security considerations. 938 The key exchange method described in section 1 of this document 939 depends on the underlying GSSAPI mechanism to provide both mutual 940 authentication and per-message integrity services. If either of 941 these features is not supported by a particular GSSAPI mechanism, or 942 by a particular implementation of a GSSAPI mechanism, then the key 943 exchange is not secure and MUST fail. 945 In order for the "external-keyx" user authentication method to be 946 used, it MUST have access to user authentication information obtained 947 as a side-effect of the key exchange. If this information is 948 unavailable, the authentication MUST fail. 950 Revealing information about the reason for an authentication failure 951 may be considered by some sites to be an unacceptable security risk 952 for a production environment. However, having that information 953 available can be invaluable for debugging purposes. Thus, it is 954 RECOMMENDED that implementations provide a means for controlling, as 955 a matter of policy, whether to send SSH_MSG_USERAUTH_GSSAPI_ERROR, 956 SSH_MSG_USERAUTH_GSSAPI_ERRTOK, and SSH_MSG_KEXGSS_ERROR messages, 957 and SSH_MSG_KEXGEE_CONTINUE messages containing a GSSAPI error token. 959 10. Acknowledgements 961 The authors would like to thank the following individuals for their 962 invaluable assistance and contributions to this document: 964 o Sam Hartman 966 o Love Hornquist-Astrand 968 o Joel N. Weber II 970 o Simon Wilkinson 972 o Nicolas Williams 974 11. Changes the last version 976 This section lists important changes since the previous version of 977 this internet-draft. This section should be removed at the time of 978 publication of this document as an RFC. 980 o Changed "gssapi" to "gssapi-with-mic", and added the description 981 and semantics of the SSH_MSG_USERAUTH_GSSAPI_MIC message. 983 o Added information in user auth describing when integrity should be 984 requested. 986 o Removed the definition of the "external-keyx" user authentication 987 method, and replaced it with the definition of the more secure 988 "gssapi-keyex" method. 990 o Added information in both key exchange and user auth describing 991 why replay and out-of-sequence detection are not needed. 993 o Improved the description in user auth of when it is OK to list 994 more than one mechanism OID in the same request, 996 o Added the table of contents. 998 o Split normative and informative references. 1000 o Added nemo and lha to the acknowledgements section. 1002 Normative References 1004 [1] ISO/IEC, "ASN.1 Encoding Rules: Specification of Basic Encoding 1005 Rules (BER), Canonical Encoding Rules (CER) and Distinguished 1006 Encoding Rules (DER)", ITU-T Recommendation X.690 (1997), ISO/ 1007 IEC 8825-1:1998, November 1998. 1009 [2] Linn, J., "Generic Security Service Application Program 1010 Interface Version 2, Update 1", RFC 2743, January 2000. 1012 [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1013 1992. 1015 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1016 Extensions (MIME) Part One: Format of Internet Message Bodies", 1017 RFC 2045, November 1996. 1019 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1020 Levels", RFC 2119, BCP 14, March 1997. 1022 [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 1023 Lehtinen, "SSH Protocol Architecture", 1024 draft-ietf-secsh-architecture-11.txt (work in progress), 1025 November 2001. 1027 [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 1028 Lehtinen, "SSH Connection Protocol", 1029 draft-ietf-secsh-connect-14.txt (work in progress), November 1030 2001. 1032 [8] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 1033 Lehtinen, "SSH Transport Layer Protocol", 1034 draft-ietf-secsh-transport-11.txt (work in progress), November 1035 2001. 1037 [9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 1038 Lehtinen, "SSH Authentication Protocol", 1039 draft-ietf-secsh-userauth-13.txt (work in progress), November 1040 2001. 1042 [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1043 2279, January 1998. 1045 [11] Alvestrand, H., "Tags for the Identification of Languages", RFC 1046 1766, March 1995. 1048 Normative References 1050 [12] Kohl, J. and C. Neuman, "The Kerberos Network Authentication 1051 Service (V5)", RFC 1510, September 1993. 1053 [13] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 1054 June 1996. 1056 [14] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 1057 Negotiation Mechanism", RFC 2478, December 1998. 1059 Authors' Addresses 1061 Jeffrey Hutzelman 1062 Carnegie Mellon University 1063 5000 Forbes Ave 1064 Pittsburgh, PA 15213 1065 US 1067 Phone: +1 412 268 7225 1068 EMail: jhutz+@cmu.edu 1069 URI: http://www.cs.cmu.edu/~jhutz/ 1071 Joseph Salowey 1072 Cisco Systems 1073 2901 Third Avenue 1074 Seattle, WA 98121 1075 US 1077 Phone: +1 206 256 3380 1078 EMail: jsalowey@cisco.com 1080 Joseph Galbraith 1081 Van Dyke Technologies, Inc. 1082 4848 Tramway Ridge Dr. NE 1083 Suite 101 1084 Albuquerque, NM 87111 1085 US 1087 EMail: galb@vandyke.com 1088 Von Welch 1089 University of Chicago & Argonne National Laboratory 1090 Distributed Systems Laboratory 1091 701 E. Washington 1092 Urbana, IL 61801 1093 US 1095 EMail: welch@mcs.anl.gov 1097 Intellectual Property Statement 1099 The IETF takes no position regarding the validity or scope of any 1100 intellectual property or other rights that might be claimed to 1101 pertain to the implementation or use of the technology described in 1102 this document or the extent to which any license under such rights 1103 might or might not be available; neither does it represent that it 1104 has made any effort to identify any such rights. Information on the 1105 IETF's procedures with respect to rights in standards-track and 1106 standards-related documentation can be found in BCP-11. Copies of 1107 claims of rights made available for publication and any assurances of 1108 licenses to be made available, or the result of an attempt made to 1109 obtain a general license or permission for the use of such 1110 proprietary rights by implementors or users of this specification can 1111 be obtained from the IETF Secretariat. 1113 The IETF invites any interested party to bring to its attention any 1114 copyrights, patents or patent applications, or other proprietary 1115 rights which may cover technology that may be required to practice 1116 this standard. Please address the information to the IETF Executive 1117 Director. 1119 Full Copyright Statement 1121 Copyright (C) The Internet Society (2003). All Rights Reserved. 1123 This document and translations of it may be copied and furnished to 1124 others, and derivative works that comment on or otherwise explain it 1125 or assist in its implementation may be prepared, copied, published 1126 and distributed, in whole or in part, without restriction of any 1127 kind, provided that the above copyright notice and this paragraph are 1128 included on all such copies and derivative works. However, this 1129 document itself may not be modified in any way, such as by removing 1130 the copyright notice or references to the Internet Society or other 1131 Internet organizations, except as needed for the purpose of 1132 developing Internet standards in which case the procedures for 1133 copyrights defined in the Internet Standards process must be 1134 followed, or as required to translate it into languages other than 1135 English. 1137 The limited permissions granted above are perpetual and will not be 1138 revoked by the Internet Society or its successors or assignees. 1140 This document and the information contained herein is provided on an 1141 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1142 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1143 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1144 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1145 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1147 Acknowledgment 1149 Funding for the RFC Editor function is currently provided by the 1150 Internet Society.