idnits 2.17.1 draft-ietf-secsh-userauth-21.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 : ---------------------------------------------------------------------------- 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 154 has weird spacing: '... string use...' == Line 155 has weird spacing: '... string ser...' == Line 156 has weird spacing: '... string met...' == Line 197 has weird spacing: '... string aut...' == Line 198 has weird spacing: '...boolean part...' == (41 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 2, 2004) is 7261 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) -- No information found for draft-ietf-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-ARCH' -- No information found for draft-ietf-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-CONNECT' -- No information found for draft-ietf-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' -- No information found for draft-ietf-assignednumbers - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-NUMBERS' -- Obsolete informational reference (is this intentional?): RFC 2279 (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 3066 (Obsoleted by RFC 4646, RFC 4647) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ylonen 3 Internet-Draft SSH Communications Security Corp 4 Expires: December 1, 2004 C. Lonvick, Ed. 5 Cisco Systems, Inc 6 June 2, 2004 8 SSH Authentication Protocol 9 draft-ietf-secsh-userauth-21.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 1, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 SSH is a protocol for secure remote login and other secure network 41 services over an insecure network. This document describes the SSH 42 authentication protocol framework and public key, password, and 43 host-based client authentication methods. Additional authentication 44 methods are described in separate documents. The SSH authentication 45 protocol runs on top of the SSH transport layer protocol and provides 46 a single authenticated tunnel for the SSH connection protocol. 48 Table of Contents 50 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3.1 The Authentication Protocol Framework . . . . . . . . . . 4 54 3.1.1 Authentication Requests . . . . . . . . . . . . . . . 4 55 3.1.2 Responses to Authentication Requests . . . . . . . . . 5 56 3.1.3 The "none" Authentication Request . . . . . . . . . . 6 57 3.1.4 Completion of User Authentication . . . . . . . . . . 6 58 3.1.5 Banner Message . . . . . . . . . . . . . . . . . . . . 7 59 3.2 Authentication Protocol Message Numbers . . . . . . . . . 7 60 3.3 Public Key Authentication Method: publickey . . . . . . . 8 61 3.4 Password Authentication Method: password . . . . . . . . . 10 62 3.5 Host-Based Authentication: hostbased . . . . . . . . . . . 11 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 6.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . 15 71 1. Contributors 73 The major original contributors of this document were: Tatu Ylonen, 74 Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 75 Communications Security Corp), and Markku-Juhani O. Saarinen 76 (University of Jyvaskyla). Darren Moffit was the original editor of 77 this document and also made very substantial contributions. 79 Additional contributors to this document include [need list]. 80 Listing their names here does not mean that they endorse this 81 document, but that they have contributed to it. 83 Comments on this internet draft should be sent to the IETF SECSH 84 working group, details at: 85 http://ietf.org/html.charters/secsh-charter.html Note: This paragraph 86 will be removed before this document progresses to become an RFC. 88 2. Introduction 90 The SSH authentication protocol is a general-purpose user 91 authentication protocol. It is intended to be run over the SSH 92 transport layer protocol [SSH-TRANS]. This protocol assumes that the 93 underlying protocols provide integrity and confidentiality 94 protection. 96 This document should be read only after reading the SSH architecture 97 document [SSH-ARCH]. This document freely uses terminology and 98 notation from the architecture document without reference or further 99 explanation. 101 The service name for this protocol is "ssh-userauth". 103 When this protocol starts, it receives the session identifier from 104 the lower-level protocol (this is the exchange hash H from the first 105 key exchange). The session identifier uniquely identifies this 106 session and is suitable for signing in order to prove ownership of a 107 private key. This protocol also needs to know whether the 108 lower-level protocol provides confidentiality protection. 110 3. Conventions Used in This Document 112 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 113 and "MAY" that appear in this document are to be interpreted as 114 described in [RFC2119] 116 The used data types and terminology are specified in the architecture 117 document [SSH-ARCH] 118 The architecture document also discusses the algorithm naming 119 conventions that MUST be used with the SSH protocols. 121 3.1 The Authentication Protocol Framework 123 The server drives the authentication by telling the client which 124 authentication methods can be used to continue the exchange at any 125 given time. The client has the freedom to try the methods listed by 126 the server in any order. This gives the server complete control over 127 the authentication process if desired, but also gives enough 128 flexibility for the client to use the methods it supports or that are 129 most convenient for the user, when multiple methods are offered by 130 the server. 132 Authentication methods are identified by their name, as defined in 133 [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as 134 supported. However, it MAY be sent by the client. The server MUST 135 always reject this request, unless the client is to be allowed in 136 without any authentication, in which case the server MUST accept this 137 request. The main purpose of sending this request is to get the list 138 of supported methods from the server. 140 The server SHOULD have a timeout for authentication, and disconnect 141 if the authentication has not been accepted within the timeout 142 period. The RECOMMENDED timeout period is 10 minutes. Additionally, 143 the implementation SHOULD limit the number of failed authentication 144 attempts a client may perform in a single session (the RECOMMENDED 145 limit is 20 attempts). If the threshold is exceeded, the server 146 SHOULD disconnect. 148 3.1.1 Authentication Requests 150 All authentication requests MUST use the following message format. 151 Only the first few fields are defined; the remaining fields depend on 152 the authentication method. 153 byte SSH_MSG_USERAUTH_REQUEST 154 string user name in ISO-10646 UTF-8 encoding [RFC2279] 155 string service name in US-ASCII 156 string method name in US-ASCII 157 The rest of the packet is method-specific. 159 The user name and service are repeated in every new authentication 160 attempt, and MAY change. The server implementation MUST carefully 161 check them in every message, and MUST flush any accumulated 162 authentication states if they change. If it is unable to flush some 163 authentication state, it MUST disconnect if the user or service name 164 changes. 166 The service name specifies the service to start after authentication. 167 There may be several different authenticated services provided. If 168 the requested service is not available, the server MAY disconnect 169 immediately or at any later time. Sending a proper disconnect 170 message is RECOMMENDED. In any case, if the service does not exist, 171 authentication MUST NOT be accepted. 173 If the requested user does not exist, the server MAY disconnect, or 174 MAY send a bogus list of acceptable authentication methods, but never 175 accept any. This makes it possible for the server to avoid 176 disclosing information on which accounts exist. In any case, if the 177 user does not exist, the authentication request MUST NOT be accepted. 179 While there is usually little point for clients to send requests that 180 the server does not list as acceptable, sending such requests is not 181 an error, and the server SHOULD simply reject requests that it does 182 not recognize. 184 An authentication request MAY result in a further exchange of 185 messages. All such messages depend on the authentication method 186 used, and the client MAY at any time continue with a new 187 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 188 abandon the previous authentication attempt and continue with the new 189 one. 191 3.1.2 Responses to Authentication Requests 193 If the server rejects the authentication request, it MUST respond 194 with the following: 196 byte SSH_MSG_USERAUTH_FAILURE 197 string authentications that can continue 198 boolean partial success 200 "Authentications that can continue" is a comma-separated list of 201 authentication method names that may productively continue the 202 authentication dialog. 204 It is RECOMMENDED that servers only include those methods in the list 205 that are actually useful. However, it is not illegal to include 206 methods that cannot be used to authenticate the user. 208 Already successfully completed authentications SHOULD NOT be included 209 in the list, unless they really should be performed again for some 210 reason. 212 "Partial success" MUST be TRUE if the authentication request to which 213 this is a response was successful. It MUST be FALSE if the request 214 was not successfully processed. 216 When the server accepts authentication, it MUST respond with the 217 following: 219 byte SSH_MSG_USERAUTH_SUCCESS 221 Note that this is not sent after each step in a multi-method 222 authentication sequence, but only when the authentication is 223 complete. 225 The client MAY send several authentication requests without waiting 226 for responses from previous requests. The server MUST process each 227 request completely and acknowledge any failed requests with a 228 SSH_MSG_USERAUTH_FAILURE message before processing the next request. 230 A request that results in further exchange of messages will be 231 aborted by a second request. It is not possible to send a second 232 request without waiting for a response from the server, if the first 233 request will result in further exchange of messages. No 234 SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. 236 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When 237 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 238 requests received after that SHOULD be silently ignored. 240 Any non-authentication messages sent by the client after the request 241 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed 242 to the service being run on top of this protocol. Such messages can 243 be identified by their message numbers (see Section 3.2). 245 3.1.3 The "none" Authentication Request 247 A client may request a list of authentication methods that may 248 continue by using the "none" authentication method. 250 If no authentication at all is needed for the user, the server MUST 251 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 252 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of 253 authentication methods that can continue. 255 This method MUST NOT be listed as supported by the server. 257 3.1.4 Completion of User Authentication 259 Authentication is complete when the server has responded with 260 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages 261 received after sending this message SHOULD be silently ignored. 263 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the 264 requested service. 266 3.1.5 Banner Message 268 In some jurisdictions, sending a warning message before 269 authentication may be relevant for getting legal protection. Many 270 UNIX machines, for example, normally display text from `/etc/issue', 271 or use "tcp wrappers" or similar software to display a banner before 272 issuing a login prompt. 274 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 275 before authentication is successful. This message contains text to 276 be displayed to the client user before authentication is attempted. 277 The format is as follows: 278 byte SSH_MSG_USERAUTH_BANNER 279 string message in ISO-10646 UTF-8 encoding 280 string language tag as defined in [RFC3066] 282 The client SHOULD by default display the message on the screen. 283 However, since the message is likely to be sent for every login 284 attempt, and since some client software will need to open a separate 285 window for this warning, the client software may allow the user to 286 explicitly disable the display of banners from the server. The 287 message may consist of multiple lines. 289 If the message string is displayed, control character filtering 290 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 291 terminal control characters. 293 3.2 Authentication Protocol Message Numbers 295 All message numbers used by this authentication protocol are in the 296 range from 50 to 79, which is part of the range reserved for 297 protocols running on top of the SSH transport layer protocol. 299 Message numbers of 80 and higher are reserved for protocols running 300 after this authentication protocol, so receiving one of them before 301 authentication is complete is an error, to which the server MUST 302 respond by disconnecting, preferably with a proper disconnect message 303 sent first to ease troubleshooting. 305 After successful authentication, such messages are passed to the 306 higher-level service. 308 These are the general authentication message codes: 310 #define SSH_MSG_USERAUTH_REQUEST 50 311 #define SSH_MSG_USERAUTH_FAILURE 51 312 #define SSH_MSG_USERAUTH_SUCCESS 52 313 #define SSH_MSG_USERAUTH_BANNER 53 315 In addition to the above, there is a range of message numbers 316 (60..79) reserved for method-specific messages. These messages are 317 only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST 318 messages). Different authentication methods reuse the same message 319 numbers. 321 3.3 Public Key Authentication Method: publickey 323 The only REQUIRED authentication method is public key authentication. 324 All implementations MUST support this method; however, not all users 325 need to have public keys, and most local policies are not likely to 326 require public key authentication for all users in the near future. 328 With this method, the possession of a private key serves as 329 authentication. This method works by sending a signature created 330 with a private key of the user. The server MUST check that the key 331 is a valid authenticator for the user, and MUST check that the 332 signature is valid. If both hold, the authentication request MUST be 333 accepted; otherwise it MUST be rejected. (Note that the server MAY 334 require additional authentications after successful authentication.) 336 Private keys are often stored in an encrypted form at the client 337 host, and the user must supply a passphrase before the signature can 338 be generated. Even if they are not, the signing operation involves 339 some expensive computation. To avoid unnecessary processing and user 340 interaction, the following message is provided for querying whether 341 authentication using the key would be acceptable. 343 byte SSH_MSG_USERAUTH_REQUEST 344 string user name 345 string service 346 string "publickey" 347 boolean FALSE 348 string public key algorithm name 349 string public key blob 351 Public key algorithms are defined in the transport layer 352 specification [SSH-TRANS]. The public key blob may contain 353 certificates. 355 Any public key algorithm may be offered for use in authentication. 356 In particular, the list is not constrained by what was negotiated 357 during key exchange. If the server does not support some algorithm, 358 it MUST simply reject the request. 360 The server MUST respond to this message with either 361 SSH_MSG_USERAUTH_FAILURE or with the following: 363 byte SSH_MSG_USERAUTH_PK_OK 364 string public key algorithm name from the request 365 string public key blob from the request 367 To perform actual authentication, the client MAY then send a 368 signature generated using the private key. The client MAY send the 369 signature directly without first verifying whether the key is 370 acceptable. The signature is sent using the following packet: 372 byte SSH_MSG_USERAUTH_REQUEST 373 string user name 374 string service 375 string "publickey" 376 boolean TRUE 377 string public key algorithm name 378 string public key to be used for authentication 379 string signature 381 Signature is a signature by the corresponding private key over the 382 following data, in the following order: 384 string session identifier 385 byte SSH_MSG_USERAUTH_REQUEST 386 string user name 387 string service 388 string "publickey" 389 boolean TRUE 390 string public key algorithm name 391 string public key to be used for authentication 393 When the server receives this message, it MUST check whether the 394 supplied key is acceptable for authentication, and if so, it MUST 395 check whether the signature is correct. 397 If both checks succeed, this method is successful. Note that the 398 server may require additional authentications. The server MUST 399 respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are 400 needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more 401 authentications are needed). 403 The following method-specific message numbers are used by the 404 publickey authentication method. 406 /* Key-based */ 407 #define SSH_MSG_USERAUTH_PK_OK 60 409 3.4 Password Authentication Method: password 411 Password authentication uses the following packets. Note that a 412 server MAY request the user to change the password. All 413 implementations SHOULD support password authentication. 415 byte SSH_MSG_USERAUTH_REQUEST 416 string user name 417 string service 418 string "password" 419 boolean FALSE 420 string plaintext password in ISO-10646 UTF-8 encoding 422 Note that the password is encoded in ISO-10646 UTF-8. It is up to 423 the server how it interprets the password and validates it against 424 the password database. However, if the client reads the password in 425 some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert 426 the password to ISO-10646 UTF-8 before transmitting, and the server 427 MUST convert the password to the encoding used on that system for 428 passwords. 430 Note that even though the cleartext password is transmitted in the 431 packet, the entire packet is encrypted by the transport layer. Both 432 the server and the client should check whether the underlying 433 transport layer provides confidentiality (i.e., if encryption is 434 being used). If no confidentiality is provided (none cipher), 435 password authentication SHOULD be disabled. If there is no 436 confidentiality or no MAC, password change SHOULD be disabled. 438 Normally, the server responds to this message with success or 439 failure. However, if the password has expired the server SHOULD 440 indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 441 In any case the server MUST NOT allow an expired password to be used 442 for authentication. 443 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 444 string prompt in ISO-10646 UTF-8 encoding 445 string language tag as defined in [RFC3066] 447 In this case, the client MAY continue with a different authentication 448 method, or request a new password from the user and retry password 449 authentication using the following message. The client MAY also send 450 this message instead of the normal password authentication request 451 without the server asking for it. 453 byte SSH_MSG_USERAUTH_REQUEST 454 string user name 455 string service 456 string "password" 457 boolean TRUE 458 string plaintext old password in ISO-10646 UTF-8 encoding 459 string plaintext new password in ISO-10646 UTF-8 encoding 461 The server must reply to request message with 462 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 463 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as 464 follows: 466 SSH_MSG_USERAUTH_SUCCESS The password has been changed, and 467 authentication has been successfully completed. 469 SSH_MSG_USERAUTH_FAILURE with partial success The password has 470 been changed, but more authentications are needed. 472 SSH_MSG_USERAUTH_FAILURE without partial success The password has 473 not been changed. Either password changing was not supported, or 474 the old password was bad. Note that if the server has already 475 sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports 476 changing the password. 478 SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because 479 the new password was not acceptable (e.g. too easy to guess). 481 The following method-specific message numbers are used by the 482 password authentication method. 484 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 486 3.5 Host-Based Authentication: hostbased 488 Some sites wish to allow authentication based on the host where the 489 user is coming from, and the user name on the remote host. While 490 this form of authentication is not suitable for high-security sites, 491 it can be very convenient in many environments. This form of 492 authentication is OPTIONAL. When used, special care SHOULD be taken 493 to prevent a regular user from obtaining the private host key. 495 The client requests this form of authentication by sending the 496 following message. It is similar to the UNIX "rhosts" and 497 "hosts.equiv" styles of authentication, except that the identity of 498 the client host is checked more rigorously. 500 This method works by having the client send a signature created with 501 the private key of the client host, which the server checks with that 502 host's public key. Once the client host's identity is established, 503 authorization (but no further authentication) is performed based on 504 the user names on the server and the client, and the client host 505 name. 507 byte SSH_MSG_USERAUTH_REQUEST 508 string user name 509 string service 510 string "hostbased" 511 string public key algorithm for host key 512 string public host key and certificates for client host 513 string client host name expressed as the FQDN in US-ASCII 514 string user name on the client host in ISO-10646 UTF-8 encoding 515 string signature 517 Public key algorithm names for use in "public key algorithm for host 518 key" are defined in the transport layer specification. The "public 519 host key for client host" may include certificates. 521 Signature is a signature with the private host key of the following 522 data, in this order: 524 string session identifier 525 byte SSH_MSG_USERAUTH_REQUEST 526 string user name 527 string service 528 string "hostbased" 529 string public key algorithm for host key 530 string public host key and certificates for client host 531 string client host name expressed as the FQDN in US-ASCII 532 string user name on the client host in ISO-10646 UTF-8 encoding 534 The server MUST verify that the host key actually belongs to the 535 client host named in the message, that the given user on that host is 536 allowed to log in, and that the signature is a valid signature on the 537 appropriate value by the given host key. The server MAY ignore the 538 client user name, if it wants to authenticate only the client host. 540 It is RECOMMENDED that whenever possible, the server perform 541 additional checks to verify that the network address obtained from 542 the (untrusted) network matches the given client host name. This 543 makes exploiting compromised host keys more difficult. Note that 544 this may require special handling for connections coming through a 545 firewall. 547 4. IANA Considerations 549 This document is part of a set. The IANA considerations for the SSH 550 protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and 551 this document, are detailed in [SSH-NUMBERS]. 553 5. Security Considerations 555 The purpose of this protocol is to perform client user 556 authentication. It assumed that this runs over a secure transport 557 layer protocol, which has already authenticated the server machine, 558 established an encrypted communications channel, and computed a 559 unique session identifier for this session. The transport layer 560 provides forward secrecy for password authentication and other 561 methods that rely on secret data. 563 Full security considerations for this protocol are provided in 564 [SSH-ARCH]. 566 6. References 568 6.1 Normative 570 [SSH-ARCH] 571 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 572 I-D draft-ietf-architecture-16.txt, May 2004. 574 [SSH-CONNECT] 575 Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D 576 draft-ietf-connect-19.txt, May 2004. 578 [SSH-TRANS] 579 Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", 580 I-D draft-ietf-transport-18.txt, May 2004. 582 [SSH-NUMBERS] 583 Ylonen, T. and C. Lonvick, "SSH Protocol Assigned 584 Numbers", I-D draft-ietf-assignednumbers-06.txt, May 2004. 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 6.2 Informative 591 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 592 10646", RFC 2279, January 1998. 594 [RFC3066] Alvestrand, H., "Tags for the Identification of 595 Languages", BCP 47, RFC 3066, January 2001. 597 Authors' Addresses 599 Tatu Ylonen 600 SSH Communications Security Corp 601 Fredrikinkatu 42 602 HELSINKI FIN-00100 603 Finland 605 EMail: ylo@ssh.com 607 Chris Lonvick (editor) 608 Cisco Systems, Inc 609 12515 Research Blvd. 610 Austin 78759 611 USA 613 EMail: clonvick@cisco.com 615 Intellectual Property Statement 617 The IETF takes no position regarding the validity or scope of any 618 intellectual property or other rights that might be claimed to 619 pertain to the implementation or use of the technology described in 620 this document or the extent to which any license under such rights 621 might or might not be available; neither does it represent that it 622 has made any effort to identify any such rights. Information on the 623 IETF's procedures with respect to rights in standards-track and 624 standards-related documentation can be found in BCP-11. Copies of 625 claims of rights made available for publication and any assurances of 626 licenses to be made available, or the result of an attempt made to 627 obtain a general license or permission for the use of such 628 proprietary rights by implementors or users of this specification can 629 be obtained from the IETF Secretariat. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights which may cover technology that may be required to practice 634 this standard. Please address the information to the IETF Executive 635 Director. 637 The IETF has been notified of intellectual property rights claimed in 638 regard to some or all of the specification contained in this 639 document. For more information consult the online list of claimed 640 rights. 642 Full Copyright Statement 644 Copyright (C) The Internet Society (2004). All Rights Reserved. 646 This document and translations of it may be copied and furnished to 647 others, and derivative works that comment on or otherwise explain it 648 or assist in its implementation may be prepared, copied, published 649 and distributed, in whole or in part, without restriction of any 650 kind, provided that the above copyright notice and this paragraph are 651 included on all such copies and derivative works. However, this 652 document itself may not be modified in any way, such as by removing 653 the copyright notice or references to the Internet Society or other 654 Internet organizations, except as needed for the purpose of 655 developing Internet standards in which case the procedures for 656 copyrights defined in the Internet Standards process must be 657 followed, or as required to translate it into languages other than 658 English. 660 The limited permissions granted above are perpetual and will not be 661 revoked by the Internet Society or its successors or assignees. 663 This document and the information contained herein is provided on an 664 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 665 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 666 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 667 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 668 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 670 Acknowledgment 672 Funding for the RFC Editor function is currently provided by the 673 Internet Society.