idnits 2.17.1 draft-ietf-secsh-userauth-19.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 155 has weird spacing: '... string use...' == Line 156 has weird spacing: '... string ser...' == Line 157 has weird spacing: '... string met...' == Line 198 has weird spacing: '... string aut...' == Line 199 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 (May 19, 2004) is 7282 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 3066 (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 2279 (Obsoleted by RFC 3629) 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: November 17, 2004 C. Lonvick, Ed. 5 Cisco Systems, Inc 6 May 19, 2004 8 SSH Authentication Protocol 9 draft-ietf-secsh-userauth-19.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 November 17, 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 . . . . . . . . . . . . . . . . . . . . . 13 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. 154 byte SSH_MSG_USERAUTH_REQUEST 155 string user name (in ISO-10646 UTF-8 encoding [RFC2279]) 156 string service name (in US-ASCII) 157 string method name (US-ASCII) 158 The rest of the packet is method-specific. 160 The user name and service are repeated in every new authentication 161 attempt, and MAY change. The server implementation MUST carefully 162 check them in every message, and MUST flush any accumulated 163 authentication states if they change. If it is unable to flush some 164 authentication state, it MUST disconnect if the user or service name 165 changes. 167 The service name specifies the service to start after authentication. 168 There may be several different authenticated services provided. If 169 the requested service is not available, the server MAY disconnect 170 immediately or at any later time. Sending a proper disconnect 171 message is RECOMMENDED. In any case, if the service does not exist, 172 authentication MUST NOT be accepted. 174 If the requested user does not exist, the server MAY disconnect, or 175 MAY send a bogus list of acceptable authentication methods, but never 176 accept any. This makes it possible for the server to avoid 177 disclosing information on which accounts exist. In any case, if the 178 user does not exist, the authentication request MUST NOT be accepted. 180 While there is usually little point for clients to send requests that 181 the server does not list as acceptable, sending such requests is not 182 an error, and the server SHOULD simply reject requests that it does 183 not recognize. 185 An authentication request MAY result in a further exchange of 186 messages. All such messages depend on the authentication method 187 used, and the client MAY at any time continue with a new 188 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 189 abandon the previous authentication attempt and continue with the new 190 one. 192 3.1.2 Responses to Authentication Requests 194 If the server rejects the authentication request, it MUST respond 195 with the following: 197 byte SSH_MSG_USERAUTH_FAILURE 198 string authentications that can continue 199 boolean partial success 201 "Authentications that can continue" is a comma-separated list of 202 authentication method names that may productively continue the 203 authentication dialog. 205 It is RECOMMENDED that servers only include those methods in the list 206 that are actually useful. However, it is not illegal to include 207 methods that cannot be used to authenticate the user. 209 Already successfully completed authentications SHOULD NOT be included 210 in the list, unless they really should be performed again for some 211 reason. 213 "Partial success" MUST be TRUE if the authentication request to which 214 this is a response was successful. It MUST be FALSE if the request 215 was not successfully processed. 217 When the server accepts authentication, it MUST respond with the 218 following: 220 byte SSH_MSG_USERAUTH_SUCCESS 222 Note that this is not sent after each step in a multi-method 223 authentication sequence, but only when the authentication is 224 complete. 226 The client MAY send several authentication requests without waiting 227 for responses from previous requests. The server MUST process each 228 request completely and acknowledge any failed requests with a 229 SSH_MSG_USERAUTH_FAILURE message before processing the next request. 231 A request that results in further exchange of messages will be 232 aborted by a second request. It is not possible to send a second 233 request without waiting for a response from the server, if the first 234 request will result in further exchange of messages. No 235 SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. 237 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When 238 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 239 requests received after that SHOULD be silently ignored. 241 Any non-authentication messages sent by the client after the request 242 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed 243 to the service being run on top of this protocol. Such messages can 244 be identified by their message numbers (see Section Message Numbers 245 (Section 3.2)). 247 3.1.3 The "none" Authentication Request 249 A client may request a list of authentication methods that may 250 continue by using the "none" authentication method. 252 If no authentication at all is needed for the user, the server MUST 253 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 254 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of 255 authentication methods that can continue. 257 This method MUST NOT be listed as supported by the server. 259 3.1.4 Completion of User Authentication 261 Authentication is complete when the server has responded with 262 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages 263 received after sending this message SHOULD be silently ignored. 265 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the 266 requested service. 268 3.1.5 Banner Message 270 In some jurisdictions, sending a warning message before 271 authentication may be relevant for getting legal protection. Many 272 UNIX machines, for example, normally display text from `/etc/issue', 273 or use "tcp wrappers" or similar software to display a banner before 274 issuing a login prompt. 276 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 277 before authentication is successful. This message contains text to 278 be displayed to the client user before authentication is attempted. 279 The format is as follows: 281 byte SSH_MSG_USERAUTH_BANNER 282 string message (ISO-10646 UTF-8) 283 string language tag (as defined in [RFC3066]) 285 The client SHOULD by default display the message on the screen. 286 However, since the message is likely to be sent for every login 287 attempt, and since some client software will need to open a separate 288 window for this warning, the client software may allow the user to 289 explicitly disable the display of banners from the server. The 290 message may consist of multiple lines. 292 If the message string is displayed, control character filtering 293 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 294 terminal control characters. 296 3.2 Authentication Protocol Message Numbers 298 All message numbers used by this authentication protocol are in the 299 range from 50 to 79, which is part of the range reserved for 300 protocols running on top of the SSH transport layer protocol. 302 Message numbers of 80 and higher are reserved for protocols running 303 after this authentication protocol, so receiving one of them before 304 authentication is complete is an error, to which the server MUST 305 respond by disconnecting (preferably with a proper disconnect message 306 sent first to ease troubleshooting). 308 After successful authentication, such messages are passed to the 309 higher-level service. 311 These are the general authentication message codes: 313 #define SSH_MSG_USERAUTH_REQUEST 50 314 #define SSH_MSG_USERAUTH_FAILURE 51 315 #define SSH_MSG_USERAUTH_SUCCESS 52 316 #define SSH_MSG_USERAUTH_BANNER 53 318 In addition to the above, there is a range of message numbers 319 (60..79) reserved for method-specific messages. These messages are 320 only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST 321 messages). Different authentication methods reuse the same message 322 numbers. 324 3.3 Public Key Authentication Method: publickey 326 The only REQUIRED authentication method is public key authentication. 327 All implementations MUST support this method; however, not all users 328 need to have public keys, and most local policies are not likely to 329 require public key authentication for all users in the near future. 331 With this method, the possession of a private key serves as 332 authentication. This method works by sending a signature created 333 with a private key of the user. The server MUST check that the key 334 is a valid authenticator for the user, and MUST check that the 335 signature is valid. If both hold, the authentication request MUST be 336 accepted; otherwise it MUST be rejected. (Note that the server MAY 337 require additional authentications after successful authentication.) 339 Private keys are often stored in an encrypted form at the client 340 host, and the user must supply a passphrase before the signature can 341 be generated. Even if they are not, the signing operation involves 342 some expensive computation. To avoid unnecessary processing and user 343 interaction, the following message is provided for querying whether 344 authentication using the key would be acceptable. 346 byte SSH_MSG_USERAUTH_REQUEST 347 string user name 348 string service 349 string "publickey" 350 boolean FALSE 351 string public key algorithm name 352 string public key blob 354 Public key algorithms are defined in the transport layer 355 specification [SSH-TRANS]. The public key blob may contain 356 certificates. 358 Any public key algorithm may be offered for use in authentication. 360 In particular, the list is not constrained by what was negotiated 361 during key exchange. If the server does not support some algorithm, 362 it MUST simply reject the request. 364 The server MUST respond to this message with either 365 SSH_MSG_USERAUTH_FAILURE or with the following: 367 byte SSH_MSG_USERAUTH_PK_OK 368 string public key algorithm name from the request 369 string public key blob from the request 371 To perform actual authentication, the client MAY then send a 372 signature generated using the private key. The client MAY send the 373 signature directly without first verifying whether the key is 374 acceptable. The signature is sent using the following packet: 376 byte SSH_MSG_USERAUTH_REQUEST 377 string user name 378 string service 379 string "publickey" 380 boolean TRUE 381 string public key algorithm name 382 string public key to be used for authentication 383 string signature 385 Signature is a signature by the corresponding private key over the 386 following data, in the following order: 388 string session identifier 389 byte SSH_MSG_USERAUTH_REQUEST 390 string user name 391 string service 392 string "publickey" 393 boolean TRUE 394 string public key algorithm name 395 string public key to be used for authentication 397 When the server receives this message, it MUST check whether the 398 supplied key is acceptable for authentication, and if so, it MUST 399 check whether the signature is correct. 401 If both checks succeed, this method is successful. Note that the 402 server may require additional authentications. The server MUST 403 respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are 404 needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more 405 authentications are needed). 407 The following method-specific message numbers are used by the 408 publickey authentication method. 410 /* Key-based */ 411 #define SSH_MSG_USERAUTH_PK_OK 60 413 3.4 Password Authentication Method: password 415 Password authentication uses the following packets. Note that a 416 server MAY request the user to change the password. All 417 implementations SHOULD support password authentication. 419 byte SSH_MSG_USERAUTH_REQUEST 420 string user name 421 string service 422 string "password" 423 boolean FALSE 424 string plaintext password (ISO-10646 UTF-8) 426 Note that the password is encoded in ISO-10646 UTF-8. It is up to 427 the server how it interprets the password and validates it against 428 the password database. However, if the client reads the password in 429 some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert 430 the password to ISO-10646 UTF-8 before transmitting, and the server 431 MUST convert the password to the encoding used on that system for 432 passwords. 434 Note that even though the cleartext password is transmitted in the 435 packet, the entire packet is encrypted by the transport layer. Both 436 the server and the client should check whether the underlying 437 transport layer provides confidentiality (i.e., if encryption is 438 being used). If no confidentiality is provided (none cipher), 439 password authentication SHOULD be disabled. If there is no 440 confidentiality or no MAC, password change SHOULD be disabled. 442 Normally, the server responds to this message with success or 443 failure. However, if the password has expired the server SHOULD 444 indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 445 In anycase the server MUST NOT allow an expired password to be used 446 for authentication. 448 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 449 string prompt (ISO-10646 UTF-8) 450 string language tag (as defined in [RFC3066]) 452 In this case, the client MAY continue with a different authentication 453 method, or request a new password from the user and retry password 454 authentication using the following message. The client MAY also send 455 this message instead of the normal password authentication request 456 without the server asking for it. 458 byte SSH_MSG_USERAUTH_REQUEST 459 string user name 460 string service 461 string "password" 462 boolean TRUE 463 string plaintext old password (ISO-10646 UTF-8) 464 string plaintext new password (ISO-10646 UTF-8) 466 The server must reply to request message with 467 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 468 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as 469 follows: 471 SSH_MSG_USERAUTH_SUCCESS The password has been changed, and 472 authentication has been successfully completed. 474 SSH_MSG_USERAUTH_FAILURE with partial success The password has 475 been changed, but more authentications are needed. 477 SSH_MSG_USERAUTH_FAILURE without partial success The password has 478 not been changed. Either password changing was not supported, or 479 the old password was bad. Note that if the server has already 480 sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports 481 changing the password. 483 SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because 484 the new password was not acceptable (e.g. too easy to guess). 486 The following method-specific message numbers are used by the 487 password authentication method. 489 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 491 3.5 Host-Based Authentication: hostbased 493 Some sites wish to allow authentication based on the host where the 494 user is coming from, and the user name on the remote host. While 495 this form of authentication is not suitable for high-security sites, 496 it can be very convenient in many environments. This form of 497 authentication is OPTIONAL. When used, special care SHOULD be taken 498 to prevent a regular user from obtaining the private host key. 500 The client requests this form of authentication by sending the 501 following message. It is similar to the UNIX "rhosts" and 502 "hosts.equiv" styles of authentication, except that the identity of 503 the client host is checked more rigorously. 505 This method works by having the client send a signature created with 506 the private key of the client host, which the server checks with that 507 host's public key. Once the client host's identity is established, 508 authorization (but no further authentication) is performed based on 509 the user names on the server and the client, and the client host 510 name. 512 byte SSH_MSG_USERAUTH_REQUEST 513 string user name 514 string service 515 string "hostbased" 516 string public key algorithm for host key 517 string public host key and certificates for client host 518 string client host name (FQDN; US-ASCII) 519 string user name on the client host (ISO-10646 UTF-8) 520 string signature 522 Public key algorithm names for use in "public key algorithm for host 523 key" are defined in the transport layer specification. The "public 524 host key for client host" may include certificates. 526 Signature is a signature with the private host key of the following 527 data, in this order: 529 string session identifier 530 byte SSH_MSG_USERAUTH_REQUEST 531 string user name 532 string service 533 string "hostbased" 534 string public key algorithm for host key 535 string public host key and certificates for client host 536 string client host name (FQDN; US-ASCII) 537 string user name on the client host(ISO-10646 UTF-8) 539 The server MUST verify that the host key actually belongs to the 540 client host named in the message, that the given user on that host is 541 allowed to log in, and that the signature is a valid signature on the 542 appropriate value by the given host key. The server MAY ignore the 543 client user name, if it wants to authenticate only the client host. 545 It is RECOMMENDED that whenever possible, the server perform 546 additional checks to verify that the network address obtained from 547 the (untrusted) network matches the given client host name. This 548 makes exploiting compromised host keys more difficult. Note that 549 this may require special handling for connections coming through a 550 firewall. 552 4. IANA Considerations 554 This document is part of a set, the IANA considerations for the SSH 555 protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and 556 this document, are detailed in [SSH-NUMBERS]. 558 5. Security Considerations 560 The purpose of this protocol is to perform client user 561 authentication. It assumed that this runs over a secure transport 562 layer protocol, which has already authenticated the server machine, 563 established an encrypted communications channel, and computed a 564 unique session identifier for this session. The transport layer 565 provides forward secrecy for password authentication and other 566 methods that rely on secret data. 568 Full security considerations for this protocol are provided in 569 Section 8 of [SSH-ARCH] 571 6. References 573 6.1 Normative 575 [SSH-ARCH] 576 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 577 I-D draft-ietf-architecture-16.txt, May 2004. 579 [SSH-CONNECT] 580 Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D 581 draft-ietf-connect-19.txt, May 2004. 583 [SSH-TRANS] 584 Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", 585 I-D draft-ietf-transport-18.txt, May 2004. 587 [SSH-NUMBERS] 588 Ylonen, T. and C. Lonvick, "SSH Protocol Assigned 589 Numbers", I-D draft-ietf-assignednumbers-06.txt, May 2004. 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 6.2 Informative 596 [RFC3066] Alvestrand, H., "Tags for the Identification of 597 Languages", BCP 47, RFC 3066, January 2001. 599 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 600 10646", RFC 2279, January 1998. 602 Authors' Addresses 604 Tatu Ylonen 605 SSH Communications Security Corp 606 Fredrikinkatu 42 607 HELSINKI FIN-00100 608 Finland 610 EMail: ylo@ssh.com 612 Chris Lonvick (editor) 613 Cisco Systems, Inc 614 12515 Research Blvd. 615 Austin 78759 616 USA 618 EMail: clonvick@cisco.com 620 Intellectual Property Statement 622 The IETF takes no position regarding the validity or scope of any 623 intellectual property or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; neither does it represent that it 627 has made any effort to identify any such rights. Information on the 628 IETF's procedures with respect to rights in standards-track and 629 standards-related documentation can be found in BCP-11. Copies of 630 claims of rights made available for publication and any assurances of 631 licenses to be made available, or the result of an attempt made to 632 obtain a general license or permission for the use of such 633 proprietary rights by implementors or users of this specification can 634 be obtained from the IETF Secretariat. 636 The IETF invites any interested party to bring to its attention any 637 copyrights, patents or patent applications, or other proprietary 638 rights which may cover technology that may be required to practice 639 this standard. Please address the information to the IETF Executive 640 Director. 642 The IETF has been notified of intellectual property rights claimed in 643 regard to some or all of the specification contained in this 644 document. For more information consult the online list of claimed 645 rights. 647 Full Copyright Statement 649 Copyright (C) The Internet Society (2004). All Rights Reserved. 651 This document and translations of it may be copied and furnished to 652 others, and derivative works that comment on or otherwise explain it 653 or assist in its implementation may be prepared, copied, published 654 and distributed, in whole or in part, without restriction of any 655 kind, provided that the above copyright notice and this paragraph are 656 included on all such copies and derivative works. However, this 657 document itself may not be modified in any way, such as by removing 658 the copyright notice or references to the Internet Society or other 659 Internet organizations, except as needed for the purpose of 660 developing Internet standards in which case the procedures for 661 copyrights defined in the Internet Standards process must be 662 followed, or as required to translate it into languages other than 663 English. 665 The limited permissions granted above are perpetual and will not be 666 revoked by the Internet Society or its successors or assignees. 668 This document and the information contained herein is provided on an 669 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 670 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 671 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 672 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 673 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 675 Acknowledgment 677 Funding for the RFC Editor function is currently provided by the 678 Internet Society.