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