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