idnits 2.17.1 draft-ietf-secsh-userauth-12.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...' (63 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 (November 9, 2001) is 8201 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 566, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 569, 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: May 10, 2002 SSH Communications Security Corp 5 M. Saarinen 6 University of Jyvaskyla 7 T. Rinne 8 S. Lehtinen 9 SSH Communications Security Corp 10 November 9, 2001 12 SSH Authentication Protocol 13 draft-ietf-secsh-userauth-12.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 May 10, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2001). 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 . . . . . . . . . . . . . . 5 59 2.4 Completion of User Authentication . . . . . . . . . . . . . . 6 60 2.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Authentication Protocol Message Numbers . . . . . . . . . . . 6 62 4. Public Key Authentication Method: publickey . . . . . . . . . 7 63 5. Password Authentication Method: password . . . . . . . . . . . 9 64 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . 10 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 12 67 9. Additional Information . . . . . . . . . . . . . . . . . . . . 12 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 acknowledge 201 any failed requests with a SSH_MSG_USERAUTH_FAILURE message. 202 However, SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once 203 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 204 requests received after that SHOULD be silently ignored. 206 Any non-authentication messages sent by the client after the request 207 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed 208 to the service being run on top of this protocol. Such messages can 209 be identified by their message numbers (see Section Message Numbers 210 (Section 3)). 212 2.3 The "none" Authentication Request 214 A client may request a list of authentication methods that may 215 continue by using the "none" authentication method. 217 If no authentication at all is needed for the user, the server MUST 218 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 219 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of 220 authentication methods that can continue. 222 This method MUST NOT be listed as supported by the server. 224 2.4 Completion of User Authentication 226 Authentication is complete when the server has responded with 227 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages 228 received after sending this message SHOULD be silently ignored. 230 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the 231 requested service. 233 2.5 Banner Message 235 In some jurisdictions, sending a warning message before 236 authentication may be relevant for getting legal protection. Many 237 UNIX machines, for example, normally display text from `/etc/issue', 238 or use "tcp wrappers" or similar software to display a banner before 239 issuing a login prompt. 241 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 242 before authentication is successful. This message contains text to 243 be displayed to the client user before authentication is attempted. 244 The format is as follows: 246 byte SSH_MSG_USERAUTH_BANNER 247 string message (ISO-10646 UTF-8) 248 string language tag (as defined in [RFC1766]) 250 The client SHOULD by default display the message on the screen. 251 However, since the message is likely to be sent for every login 252 attempt, and since some client software will need to open a separate 253 window for this warning, the client software may allow the user to 254 explicitly disable the display of banners from the server. The 255 message may consist of multiple lines. 257 If the message string is displayed, control character filtering 258 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 259 terminal control characters. 261 3. Authentication Protocol Message Numbers 263 All message numbers used by this authentication protocol are in the 264 range from 50 to 79, which is part of the range reserved for 265 protocols running on top of the SSH transport layer protocol. 267 Message numbers of 80 and higher are reserved for protocols running 268 after this authentication protocol, so receiving one of them before 269 authentication is complete is an error, to which the server MUST 270 respond by disconnecting (preferably with a proper disconnect message 271 sent first to ease troubleshooting). 273 After successful authentication, such messages are passed to the 274 higher-level service. 276 These are the general authentication message codes: 278 #define SSH_MSG_USERAUTH_REQUEST 50 279 #define SSH_MSG_USERAUTH_FAILURE 51 280 #define SSH_MSG_USERAUTH_SUCCESS 52 281 #define SSH_MSG_USERAUTH_BANNER 53 283 In addition to the above, there is a range of message numbers 284 (60..79) reserved for method-specific messages. These messages are 285 only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST 286 messages). Different authentication methods reuse the same message 287 numbers. 289 4. Public Key Authentication Method: publickey 291 The only REQUIRED authentication method is public key authentication. 292 All implementations MUST support this method; however, not all users 293 need to have public keys, and most local policies are not likely to 294 require public key authentication for all users in the near future. 296 With this method, the possession of a private key serves as 297 authentication. This method works by sending a signature created 298 with a private key of the user. The server MUST check that the key 299 is a valid authenticator for the user, and MUST check that the 300 signature is valid. If both hold, the authentication request MUST be 301 accepted; otherwise it MUST be rejected. (Note that the server MAY 302 require additional authentications after successful authentication.) 304 Private keys are often stored in an encrypted form at the client 305 host, and the user must supply a passphrase before the signature can 306 be generated. Even if they are not, the signing operation involves 307 some expensive computation. To avoid unnecessary processing and user 308 interaction, the following message is provided for querying whether 309 authentication using the key would be acceptable. 311 byte SSH_MSG_USERAUTH_REQUEST 312 string user name 313 string service 314 string "publickey" 315 boolean FALSE 316 string public key algorithm name 317 string public key blob 319 Public key algorithms are defined in the transport layer 320 specification [SSH-TRANS]. The public key blob may contain 321 certificates. 323 Any public key algorithm may be offered for use in authentication. 324 In particular, the list is not constrained by what was negotiated 325 during key exchange. If the server does not support some algorithm, 326 it MUST simply reject the request. 328 The server MUST respond to this message with either 329 SSH_MSG_USERAUTH_FAILURE or with the following: 331 byte SSH_MSG_USERAUTH_PK_OK 332 string public key algorithm name from the request 333 string public key blob from the request 335 To perform actual authentication, the client MAY then send a 336 signature generated using the private key. The client MAY send the 337 signature directly without first verifying whether the key is 338 acceptable. The signature is sent using the following packet: 340 byte SSH_MSG_USERAUTH_REQUEST 341 string user name 342 string service 343 string "publickey" 344 boolean TRUE 345 string public key algorithm name 346 string public key to be used for authentication 347 string signature 349 Signature is a signature by the corresponding private key over the 350 following data, in the following order: 352 string session identifier 353 byte SSH_MSG_USERAUTH_REQUEST 354 string user name 355 string service 356 string "publickey" 357 boolean TRUE 358 string public key algorithm name 359 string public key to be used for authentication 361 When the server receives this message, it MUST check whether the 362 supplied key is acceptable for authentication, and if so, it MUST 363 check whether the signature is correct. 365 If both checks succeed, this method is successful. Note that the 366 server may require additional authentications. The server MUST 367 respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are 368 needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more 369 authentications are needed). 371 The following method-specific message numbers are used by the 372 publickey authentication method. 374 /* Key-based */ 375 #define SSH_MSG_USERAUTH_PK_OK 60 377 5. Password Authentication Method: password 379 Password authentication uses the following packets. Note that a 380 server MAY request the user to change the password. All 381 implementations SHOULD support password authentication. 383 byte SSH_MSG_USERAUTH_REQUEST 384 string user name 385 string service 386 string "password" 387 boolean FALSE 388 string plaintext password (ISO-10646 UTF-8) 390 Note that the password is encoded in ISO-10646 UTF-8. It is up to 391 the server how it interprets the password and validates it against 392 the password database. However, if the client reads the password in 393 some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert 394 the password to ISO-10646 UTF-8 before transmitting, and the server 395 MUST convert the password to the encoding used on that system for 396 passwords. 398 Note that even though the cleartext password is transmitted in the 399 packet, the entire packet is encrypted by the transport layer. Both 400 the server and the client should check whether the underlying 401 transport layer provides confidentiality (i.e., if encryption is 402 being used). If no confidentiality is provided (none cipher), 403 password authentication SHOULD be disabled. If there is no 404 confidentiality or no MAC, password change SHOULD be disabled. 406 Normally, the server responds to this message with success or 407 failure. However, the server MAY also respond with 408 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 410 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 411 string prompt (ISO-10646 UTF-8) 412 string language tag (as defined in [RFC1766]) 414 In this case, the software client SHOULD request a new password from 415 the user, and send a new request using the following message. The 416 client may also send this message instead of the normal password 417 authentication request without the server asking for it. 419 byte SSH_MSG_USERAUTH_REQUEST 420 string user name 421 string service 422 string "password" 423 boolean TRUE 424 string plaintext old password (ISO-10646 UTF-8) 425 string plaintext new password (ISO-10646 UTF-8) 427 The server must reply to request message with 428 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 429 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as 430 follows: 431 SSH_MSG_USERAUTH_SUCCESS The password has been changed, and 432 authentication has been successfully completed. 433 SSH_MSG_USERAUTH_FAILURE with partial success The password has 434 been changed, but more authentications are needed. 435 SSH_MSG_USERAUTH_FAILURE without partial success The password has 436 not been changed. Either password changing was not supported, or 437 the old password was bad. Note that if the server has already 438 sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports 439 changing the password. 440 SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because 441 the new password was not acceptable (e.g. too easy to guess). 443 The following method-specific message numbers are used by the 444 password authentication method. 446 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 448 6. Host-Based Authentication: hostbased 450 Some sites wish to allow authentication based on the host where the 451 user is coming from, and the user name on the remote host. While 452 this form of authentication is not suitable for high-security sites, 453 it can be very convenient in many environments. This form of 454 authentication is OPTIONAL. When used, special care SHOULD be taken 455 to prevent a regular user from obtaining the private host key. 457 The client requests this form of authentication by sending the 458 following message. It is similar to the UNIX "rhosts" and 459 "hosts.equiv" styles of authentication, except that the identity of 460 the client host is checked more rigorously. 462 This method works by having the client send a signature created with 463 the private key of the client host, which the server checks with that 464 host's public key. Once the client host's identity is established, 465 authorization (but no further authentication) is performed based on 466 the user names on the server and the client, and the client host 467 name. 469 byte SSH_MSG_USERAUTH_REQUEST 470 string user name 471 string service 472 string "hostbased" 473 string public key algorithm for host key 474 string public host key and certificates for client host 475 string client host name (FQDN; US-ASCII) 476 string user name on the client host (ISO-10646 UTF-8) 477 string signature 479 Public key algorithm names for use in "public key algorithm for host 480 key" are defined in the transport layer specification. The "public 481 host key for client host" may include certificates. 483 Signature is a signature with the private host key of the following 484 data, in this order: 486 string session identifier 487 byte SSH_MSG_USERAUTH_REQUEST 488 string user name 489 string service 490 string "hostbased" 491 string public key algorithm for host key 492 string public host key and certificates for client host 493 string client host name (FQDN; US-ASCII) 494 string user name on the client host(ISO-10646 UTF-8) 496 The server MUST verify that the host key actually belongs to the 497 client host named in the message, that the given user on that host is 498 allowed to log in, and that the signature is a valid signature on the 499 appropriate value by the given host key. The server MAY ignore the 500 client user name, if it wants to authenticate only the client host. 502 It is RECOMMENDED that whenever possible, the server perform 503 additional checks to verify that the network address obtained from 504 the (untrusted) network matches the given client host name. This 505 makes exploiting compromised host keys more difficult. Note that 506 this may require special handling for connections coming through a 507 firewall. 509 7. Security Considerations 511 The purpose of this protocol is to perform client user 512 authentication. It assumed that this runs over a secure transport 513 layer protocol, which has already authenticated the server machine, 514 established an encrypted communications channel, and computed a 515 unique session identifier for this session. The transport layer 516 provides forward secrecy for password authentication and other 517 methods that rely on secret data. 519 The server may go into a "sleep" period after repeated unsuccessful 520 authentications to make key search harder. 522 If the transport layer does not provide encryption, authentication 523 methods that rely on secret data SHOULD be disabled. If it does not 524 provide MAC protection, requests to change authentication data (e.g. 525 password change) SHOULD be disabled to avoid an attacker from 526 modifying the ciphertext without being noticed, rendering the new 527 authentication data unusable (denial of service). 529 Several authentication methods with different security 530 characteristics are allowed. It is up to the server's local policy 531 to decide which methods (or combinations of methods) it is willing to 532 accept for each user. Authentication is no stronger than the weakest 533 combination allowed. 535 Special care should be taken when designing debug messages. These 536 messages may reveal surprising amounts of information about the host 537 if not properly designed. Debug messages can be disabled (during 538 user authentication phase) if high security is required. 540 8. Trademark Issues 542 As of this writing, SSH Communications Security Oy claims ssh as its 543 trademark. As with all IPR claims the IETF takes no position 544 regarding the validity or scope of this trademark claim. 546 9. Additional Information 548 The current document editor is: Darren.Moffat@Sun.COM. Comments on 549 this internet draft should be sent to the IETF SECSH working group, 550 details at: http://ietf.org/html.charters/secsh-charter.html 552 References 554 [RFC1766] Alvestrand, H., "Tags for the Identification of 555 Languages", RFC 1766, March 1995. 557 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 558 10646", RFC 2279, January 1998. 560 [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- 561 ietf-architecture-09.txt, July 2001. 563 [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D 564 draft-ietf-transport-11.txt, July 2001. 566 [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- 567 ietf-userauth-11.txt, July 2001. 569 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- 570 ietf-connect-11.txt, July 2001. 572 Authors' Addresses 574 Tatu Ylonen 575 SSH Communications Security Corp 576 Fredrikinkatu 42 577 HELSINKI FIN-00100 578 Finland 580 EMail: ylo@ssh.com 582 Tero Kivinen 583 SSH Communications Security Corp 584 Fredrikinkatu 42 585 HELSINKI FIN-00100 586 Finland 588 EMail: kivinen@ssh.com 590 Markku-Juhani O. Saarinen 591 University of Jyvaskyla 592 Timo J. Rinne 593 SSH Communications Security Corp 594 Fredrikinkatu 42 595 HELSINKI FIN-00100 596 Finland 598 EMail: tri@ssh.com 600 Sami Lehtinen 601 SSH Communications Security Corp 602 Fredrikinkatu 42 603 HELSINKI FIN-00100 604 Finland 606 EMail: sjl@ssh.com 608 Full Copyright Statement 610 Copyright (C) The Internet Society (2001). All Rights Reserved. 612 This document and translations of it may be copied and furnished to 613 others, and derivative works that comment on or otherwise explain it 614 or assist in its implementation may be prepared, copied, published 615 and distributed, in whole or in part, without restriction of any 616 kind, provided that the above copyright notice and this paragraph are 617 included on all such copies and derivative works. However, this 618 document itself may not be modified in any way, such as by removing 619 the copyright notice or references to the Internet Society or other 620 Internet organizations, except as needed for the purpose of 621 developing Internet standards in which case the procedures for 622 copyrights defined in the Internet Standards process must be 623 followed, or as required to translate it into languages other than 624 English. 626 The limited permissions granted above are perpetual and will not be 627 revoked by the Internet Society or its successors or assigns. 629 This document and the information contained herein is provided on an 630 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 631 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 632 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 633 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 634 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Acknowledgement 638 Funding for the RFC Editor function is currently provided by the 639 Internet Society.