idnits 2.17.1 draft-ietf-secsh-userauth-15.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 : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 106: '... [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as...' RFC 2119 keyword, line 107: '...ed. However, it MAY be sent by the cl...' RFC 2119 keyword, line 109: '...which case the server MUST accept this...' RFC 2119 keyword, line 113: '... The server SHOULD have a timeout fo...' RFC 2119 keyword, line 115: '... period. The RECOMMENDED timeout pe...' (65 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 128 has weird spacing: '... string use...' == Line 129 has weird spacing: '... string ser...' == Line 130 has weird spacing: '... string met...' == Line 171 has weird spacing: '... string aut...' == Line 172 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 (February 28, 2002) is 8085 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) == Unused Reference: 'SSH-USERAUTH' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 584, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) -- 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-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' -- No information found for draft-ietf-userauth - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-USERAUTH' -- No information found for draft-ietf-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-CONNECT' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ylonen 3 Internet-Draft T. Kivinen 4 Expires: August 29, 2002 SSH Communications Security Corp 5 M. Saarinen 6 University of Jyvaskyla 7 T. Rinne 8 S. Lehtinen 9 SSH Communications Security Corp 10 February 28, 2002 12 SSH Authentication Protocol 13 draft-ietf-secsh-userauth-15.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 29, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 SSH is a protocol for secure remote login and other secure network 45 services over an insecure network. This document describes the SSH 46 authentication protocol framework and public key, password, and host- 47 based client authentication methods. Additional authentication 48 methods are described in separate documents. The SSH authentication 49 protocol runs on top of the SSH transport layer protocol and provides 50 a single authenticated tunnel for the SSH connection protocol. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. The Authentication Protocol Framework . . . . . . . . . . . . 3 56 2.1 Authentication Requests . . . . . . . . . . . . . . . . . . . 4 57 2.2 Responses to Authentication Requests . . . . . . . . . . . . . 4 58 2.3 The "none" Authentication Request . . . . . . . . . . . . . . 6 59 2.4 Completion of User Authentication . . . . . . . . . . . . . . 6 60 2.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Authentication Protocol Message Numbers . . . . . . . . . . . 7 62 4. Public Key Authentication Method: publickey . . . . . . . . . 7 63 5. Password Authentication Method: password . . . . . . . . . . . 9 64 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . 11 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. Additional Information . . . . . . . . . . . . . . . . . . . . 13 68 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 70 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 The SSH authentication protocol is a general-purpose user 75 authentication protocol. It is intended to be run over the SSH 76 transport layer protocol [SSH-TRANS]. This protocol assumes that the 77 underlying protocols provide integrity and confidentiality 78 protection. 80 This document should be read only after reading the SSH architecture 81 document [SSH-ARCH]. This document freely uses terminology and 82 notation from the architecture document without reference or further 83 explanation. 85 The service name for this protocol is "ssh-userauth". 87 When this protocol starts, it receives the session identifier from 88 the lower-level protocol (this is the exchange hash H from the first 89 key exchange). The session identifier uniquely identifies this 90 session and is suitable for signing in order to prove ownership of a 91 private key. This protocol also needs to know whether the lower- 92 level protocol provides confidentiality protection. 94 2. The Authentication Protocol Framework 96 The server drives the authentication by telling the client which 97 authentication methods can be used to continue the exchange at any 98 given time. The client has the freedom to try the methods listed by 99 the server in any order. This gives the server complete control over 100 the authentication process if desired, but also gives enough 101 flexibility for the client to use the methods it supports or that are 102 most convenient for the user, when multiple methods are offered by 103 the server. 105 Authentication methods are identified by their name, as defined in 106 [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as 107 supported. However, it MAY be sent by the client. The server MUST 108 always reject this request, unless the client is to be allowed in 109 without any authentication, in which case the server MUST accept this 110 request. The main purpose of sending this request is to get the list 111 of supported methods from the server. 113 The server SHOULD have a timeout for authentication, and disconnect 114 if the authentication has not been accepted within the timeout 115 period. The RECOMMENDED timeout period is 10 minutes. Additionally, 116 the implementation SHOULD limit the number of failed authentication 117 attempts a client may perform in a single session (the RECOMMENDED 118 limit is 20 attempts). If the threshold is exceeded, the server 119 SHOULD disconnect. 121 2.1 Authentication Requests 123 All authentication requests MUST use the following message format. 124 Only the first few fields are defined; the remaining fields depend on 125 the authentication method. 127 byte SSH_MSG_USERAUTH_REQUEST 128 string user name (in ISO-10646 UTF-8 encoding [RFC2279]) 129 string service name (in US-ASCII) 130 string method name (US-ASCII) 131 The rest of the packet is method-specific. 133 The user name and service are repeated in every new authentication 134 attempt, and MAY change. The server implementation MUST carefully 135 check them in every message, and MUST flush any accumulated 136 authentication states if they change. If it is unable to flush some 137 authentication state, it MUST disconnect if the user or service name 138 changes. 140 The service name specifies the service to start after authentication. 141 There may be several different authenticated services provided. If 142 the requested service is not available, the server MAY disconnect 143 immediately or at any later time. Sending a proper disconnect 144 message is RECOMMENDED. In any case, if the service does not exist, 145 authentication MUST NOT be accepted. 147 If the requested user does not exist, the server MAY disconnect, or 148 MAY send a bogus list of acceptable authentication methods, but never 149 accept any. This makes it possible for the server to avoid 150 disclosing information on which accounts exist. In any case, if the 151 user does not exist, the authentication request MUST NOT be accepted. 153 While there is usually little point for clients to send requests that 154 the server does not list as acceptable, sending such requests is not 155 an error, and the server SHOULD simply reject requests that it does 156 not recognize. 158 An authentication request MAY result in a further exchange of 159 messages. All such messages depend on the authentication method 160 used, and the client MAY at any time continue with a new 161 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 162 abandon the previous authentication attempt and continue with the new 163 one. 165 2.2 Responses to Authentication Requests 167 If the server rejects the authentication request, it MUST respond 168 with the following: 170 byte SSH_MSG_USERAUTH_FAILURE 171 string authentications that can continue 172 boolean partial success 174 "Authentications that can continue" is a comma-separated list of 175 authentication method names that may productively continue the 176 authentication dialog. 178 It is RECOMMENDED that servers only include those methods in the list 179 that are actually useful. However, it is not illegal to include 180 methods that cannot be used to authenticate the user. 182 Already successfully completed authentications SHOULD NOT be included 183 in the list, unless they really should be performed again for some 184 reason. 186 "Partial success" MUST be TRUE if the authentication request to which 187 this is a response was successful. It MUST be FALSE if the request 188 was not successfully processed. 190 When the server accepts authentication, it MUST respond with the 191 following: 193 byte SSH_MSG_USERAUTH_SUCCESS 195 Note that this is not sent after each step in a multi-method 196 authentication sequence, but only when the authentication is 197 complete. 199 The client MAY send several authentication requests without waiting 200 for responses from previous requests. The server MUST process each 201 request completely and acknowledge any failed requests with a 202 SSH_MSG_USERAUTH_FAILURE message before processing the next request. 204 A request that results in further exchange of messages will be 205 aborted by a second request. It is not possible to send a second 206 request without waiting for a response from the server, if the first 207 request will result in further exchange of messages. No 208 SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. 210 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When 211 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 212 requests received after that SHOULD be silently ignored. 214 Any non-authentication messages sent by the client after the request 215 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed 216 to the service being run on top of this protocol. Such messages can 217 be identified by their message numbers (see Section Message Numbers 218 (Section 3)). 220 2.3 The "none" Authentication Request 222 A client may request a list of authentication methods that may 223 continue by using the "none" authentication method. 225 If no authentication at all is needed for the user, the server MUST 226 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 227 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of 228 authentication methods that can continue. 230 This method MUST NOT be listed as supported by the server. 232 2.4 Completion of User Authentication 234 Authentication is complete when the server has responded with 235 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages 236 received after sending this message SHOULD be silently ignored. 238 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the 239 requested service. 241 2.5 Banner Message 243 In some jurisdictions, sending a warning message before 244 authentication may be relevant for getting legal protection. Many 245 UNIX machines, for example, normally display text from `/etc/issue', 246 or use "tcp wrappers" or similar software to display a banner before 247 issuing a login prompt. 249 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 250 before authentication is successful. This message contains text to 251 be displayed to the client user before authentication is attempted. 252 The format is as follows: 254 byte SSH_MSG_USERAUTH_BANNER 255 string message (ISO-10646 UTF-8) 256 string language tag (as defined in [RFC1766]) 258 The client SHOULD by default display the message on the screen. 259 However, since the message is likely to be sent for every login 260 attempt, and since some client software will need to open a separate 261 window for this warning, the client software may allow the user to 262 explicitly disable the display of banners from the server. The 263 message may consist of multiple lines. 265 If the message string is displayed, control character filtering 266 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 267 terminal control characters. 269 3. Authentication Protocol Message Numbers 271 All message numbers used by this authentication protocol are in the 272 range from 50 to 79, which is part of the range reserved for 273 protocols running on top of the SSH transport layer protocol. 275 Message numbers of 80 and higher are reserved for protocols running 276 after this authentication protocol, so receiving one of them before 277 authentication is complete is an error, to which the server MUST 278 respond by disconnecting (preferably with a proper disconnect message 279 sent first to ease troubleshooting). 281 After successful authentication, such messages are passed to the 282 higher-level service. 284 These are the general authentication message codes: 286 #define SSH_MSG_USERAUTH_REQUEST 50 287 #define SSH_MSG_USERAUTH_FAILURE 51 288 #define SSH_MSG_USERAUTH_SUCCESS 52 289 #define SSH_MSG_USERAUTH_BANNER 53 291 In addition to the above, there is a range of message numbers 292 (60..79) reserved for method-specific messages. These messages are 293 only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST 294 messages). Different authentication methods reuse the same message 295 numbers. 297 4. Public Key Authentication Method: publickey 299 The only REQUIRED authentication method is public key authentication. 300 All implementations MUST support this method; however, not all users 301 need to have public keys, and most local policies are not likely to 302 require public key authentication for all users in the near future. 304 With this method, the possession of a private key serves as 305 authentication. This method works by sending a signature created 306 with a private key of the user. The server MUST check that the key 307 is a valid authenticator for the user, and MUST check that the 308 signature is valid. If both hold, the authentication request MUST be 309 accepted; otherwise it MUST be rejected. (Note that the server MAY 310 require additional authentications after successful authentication.) 312 Private keys are often stored in an encrypted form at the client 313 host, and the user must supply a passphrase before the signature can 314 be generated. Even if they are not, the signing operation involves 315 some expensive computation. To avoid unnecessary processing and user 316 interaction, the following message is provided for querying whether 317 authentication using the key would be acceptable. 319 byte SSH_MSG_USERAUTH_REQUEST 320 string user name 321 string service 322 string "publickey" 323 boolean FALSE 324 string public key algorithm name 325 string public key blob 327 Public key algorithms are defined in the transport layer 328 specification [SSH-TRANS]. The public key blob may contain 329 certificates. 331 Any public key algorithm may be offered for use in authentication. 332 In particular, the list is not constrained by what was negotiated 333 during key exchange. If the server does not support some algorithm, 334 it MUST simply reject the request. 336 The server MUST respond to this message with either 337 SSH_MSG_USERAUTH_FAILURE or with the following: 339 byte SSH_MSG_USERAUTH_PK_OK 340 string public key algorithm name from the request 341 string public key blob from the request 343 To perform actual authentication, the client MAY then send a 344 signature generated using the private key. The client MAY send the 345 signature directly without first verifying whether the key is 346 acceptable. The signature is sent using the following packet: 348 byte SSH_MSG_USERAUTH_REQUEST 349 string user name 350 string service 351 string "publickey" 352 boolean TRUE 353 string public key algorithm name 354 string public key to be used for authentication 355 string signature 357 Signature is a signature by the corresponding private key over the 358 following data, in the following order: 360 string session identifier 361 byte SSH_MSG_USERAUTH_REQUEST 362 string user name 363 string service 364 string "publickey" 365 boolean TRUE 366 string public key algorithm name 367 string public key to be used for authentication 369 When the server receives this message, it MUST check whether the 370 supplied key is acceptable for authentication, and if so, it MUST 371 check whether the signature is correct. 373 If both checks succeed, this method is successful. Note that the 374 server may require additional authentications. The server MUST 375 respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are 376 needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more 377 authentications are needed). 379 The following method-specific message numbers are used by the 380 publickey authentication method. 382 /* Key-based */ 383 #define SSH_MSG_USERAUTH_PK_OK 60 385 5. Password Authentication Method: password 387 Password authentication uses the following packets. Note that a 388 server MAY request the user to change the password. All 389 implementations SHOULD support password authentication. 391 byte SSH_MSG_USERAUTH_REQUEST 392 string user name 393 string service 394 string "password" 395 boolean FALSE 396 string plaintext password (ISO-10646 UTF-8) 398 Note that the password is encoded in ISO-10646 UTF-8. It is up to 399 the server how it interprets the password and validates it against 400 the password database. However, if the client reads the password in 401 some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert 402 the password to ISO-10646 UTF-8 before transmitting, and the server 403 MUST convert the password to the encoding used on that system for 404 passwords. 406 Note that even though the cleartext password is transmitted in the 407 packet, the entire packet is encrypted by the transport layer. Both 408 the server and the client should check whether the underlying 409 transport layer provides confidentiality (i.e., if encryption is 410 being used). If no confidentiality is provided (none cipher), 411 password authentication SHOULD be disabled. If there is no 412 confidentiality or no MAC, password change SHOULD be disabled. 414 Normally, the server responds to this message with success or 415 failure. However, if the password has expired the server SHOULD 416 indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 417 In anycase the server MUST NOT allow an expired password to be used 418 for authentication. 420 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 421 string prompt (ISO-10646 UTF-8) 422 string language tag (as defined in [RFC1766]) 424 In this case, the client MAY continue with a different authentication 425 method, or request a new password from the user and retry password 426 authentication using the following message. The client MAY also send 427 this message instead of the normal password authentication request 428 without the server asking for it. 430 byte SSH_MSG_USERAUTH_REQUEST 431 string user name 432 string service 433 string "password" 434 boolean TRUE 435 string plaintext old password (ISO-10646 UTF-8) 436 string plaintext new password (ISO-10646 UTF-8) 438 The server must reply to request message with 439 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 440 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as 441 follows: 443 SSH_MSG_USERAUTH_SUCCESS The password has been changed, and 444 authentication has been successfully completed. 446 SSH_MSG_USERAUTH_FAILURE with partial success The password has 447 been changed, but more authentications are needed. 449 SSH_MSG_USERAUTH_FAILURE without partial success The password has 450 not been changed. Either password changing was not supported, or 451 the old password was bad. Note that if the server has already 452 sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports 453 changing the password. 455 SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because 456 the new password was not acceptable (e.g. too easy to guess). 458 The following method-specific message numbers are used by the 459 password authentication method. 461 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 463 6. Host-Based Authentication: hostbased 465 Some sites wish to allow authentication based on the host where the 466 user is coming from, and the user name on the remote host. While 467 this form of authentication is not suitable for high-security sites, 468 it can be very convenient in many environments. This form of 469 authentication is OPTIONAL. When used, special care SHOULD be taken 470 to prevent a regular user from obtaining the private host key. 472 The client requests this form of authentication by sending the 473 following message. It is similar to the UNIX "rhosts" and 474 "hosts.equiv" styles of authentication, except that the identity of 475 the client host is checked more rigorously. 477 This method works by having the client send a signature created with 478 the private key of the client host, which the server checks with that 479 host's public key. Once the client host's identity is established, 480 authorization (but no further authentication) is performed based on 481 the user names on the server and the client, and the client host 482 name. 484 byte SSH_MSG_USERAUTH_REQUEST 485 string user name 486 string service 487 string "hostbased" 488 string public key algorithm for host key 489 string public host key and certificates for client host 490 string client host name (FQDN; US-ASCII) 491 string user name on the client host (ISO-10646 UTF-8) 492 string signature 494 Public key algorithm names for use in "public key algorithm for host 495 key" are defined in the transport layer specification. The "public 496 host key for client host" may include certificates. 498 Signature is a signature with the private host key of the following 499 data, in this order: 501 string session identifier 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) 511 The server MUST verify that the host key actually belongs to the 512 client host named in the message, that the given user on that host is 513 allowed to log in, and that the signature is a valid signature on the 514 appropriate value by the given host key. The server MAY ignore the 515 client user name, if it wants to authenticate only the client host. 517 It is RECOMMENDED that whenever possible, the server perform 518 additional checks to verify that the network address obtained from 519 the (untrusted) network matches the given client host name. This 520 makes exploiting compromised host keys more difficult. Note that 521 this may require special handling for connections coming through a 522 firewall. 524 7. Security Considerations 526 The purpose of this protocol is to perform client user 527 authentication. It assumed that this runs over a secure transport 528 layer protocol, which has already authenticated the server machine, 529 established an encrypted communications channel, and computed a 530 unique session identifier for this session. The transport layer 531 provides forward secrecy for password authentication and other 532 methods that rely on secret data. 534 The server may go into a "sleep" period after repeated unsuccessful 535 authentications to make key search harder. 537 If the transport layer does not provide encryption, authentication 538 methods that rely on secret data SHOULD be disabled. If it does not 539 provide MAC protection, requests to change authentication data (e.g. 540 password change) SHOULD be disabled to avoid an attacker from 541 modifying the ciphertext without being noticed, rendering the new 542 authentication data unusable (denial of service). 544 Several authentication methods with different security 545 characteristics are allowed. It is up to the server's local policy 546 to decide which methods (or combinations of methods) it is willing to 547 accept for each user. Authentication is no stronger than the weakest 548 combination allowed. 550 Special care should be taken when designing debug messages. These 551 messages may reveal surprising amounts of information about the host 552 if not properly designed. Debug messages can be disabled (during 553 user authentication phase) if high security is required. 555 8. Trademark Issues 557 As of this writing, SSH Communications Security Oy claims ssh as its 558 trademark. As with all IPR claims the IETF takes no position 559 regarding the validity or scope of this trademark claim. 561 9. Additional Information 563 The current document editor is: Darren.Moffat@Sun.COM. Comments on 564 this internet draft should be sent to the IETF SECSH working group, 565 details at: http://ietf.org/html.charters/secsh-charter.html 567 References 569 [RFC1766] Alvestrand, H., "Tags for the Identification of 570 Languages", RFC 1766, March 1995. 572 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 573 10646", RFC 2279, January 1998. 575 [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- 576 ietf-architecture-12.txt, July 2001. 578 [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D 579 draft-ietf-transport-13.txt, July 2001. 581 [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- 582 ietf-userauth-15.txt, July 2001. 584 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- 585 ietf-connect-15.txt, July 2001. 587 Authors' Addresses 589 Tatu Ylonen 590 SSH Communications Security Corp 591 Fredrikinkatu 42 592 HELSINKI FIN-00100 593 Finland 595 EMail: ylo@ssh.com 596 Tero Kivinen 597 SSH Communications Security Corp 598 Fredrikinkatu 42 599 HELSINKI FIN-00100 600 Finland 602 EMail: kivinen@ssh.com 604 Markku-Juhani O. Saarinen 605 University of Jyvaskyla 607 Timo J. Rinne 608 SSH Communications Security Corp 609 Fredrikinkatu 42 610 HELSINKI FIN-00100 611 Finland 613 EMail: tri@ssh.com 615 Sami Lehtinen 616 SSH Communications Security Corp 617 Fredrikinkatu 42 618 HELSINKI FIN-00100 619 Finland 621 EMail: sjl@ssh.com 623 Full Copyright Statement 625 Copyright (C) The Internet Society (2002). All Rights Reserved. 627 This document and translations of it may be copied and furnished to 628 others, and derivative works that comment on or otherwise explain it 629 or assist in its implementation may be prepared, copied, published 630 and distributed, in whole or in part, without restriction of any 631 kind, provided that the above copyright notice and this paragraph are 632 included on all such copies and derivative works. However, this 633 document itself may not be modified in any way, such as by removing 634 the copyright notice or references to the Internet Society or other 635 Internet organizations, except as needed for the purpose of 636 developing Internet standards in which case the procedures for 637 copyrights defined in the Internet Standards process must be 638 followed, or as required to translate it into languages other than 639 English. 641 The limited permissions granted above are perpetual and will not be 642 revoked by the Internet Society or its successors or assigns. 644 This document and the information contained herein is provided on an 645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 648 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 649 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 651 Acknowledgement 653 Funding for the RFC Editor function is currently provided by the 654 Internet Society.