Added: mina/sshd/trunk/src/docs/rfc4252.txt URL: http://svn.apache.org/viewvc/mina/sshd/trunk/src/docs/rfc4252.txt?rev=723396&view=auto ============================================================================== --- mina/sshd/trunk/src/docs/rfc4252.txt (added) +++ mina/sshd/trunk/src/docs/rfc4252.txt Thu Dec 4 10:59:31 2008 @@ -0,0 +1,955 @@ + + + + + + +Network Working Group T. Ylonen +Request for Comments: 4252 SSH Communications Security Corp +Category: Standards Track C. Lonvick, Ed. + Cisco Systems, Inc. + January 2006 + + + The Secure Shell (SSH) Authentication Protocol + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Secure Shell Protocol (SSH) is a protocol for secure remote login + and other secure network services over an insecure network. This + document describes the SSH authentication protocol framework and + public key, password, and host-based client authentication methods. + Additional authentication methods are described in separate + documents. The SSH authentication protocol runs on top of the SSH + transport layer protocol and provides a single authenticated tunnel + for the SSH connection protocol. + + + + + + + + + + + + + + + + + + + + +Ylonen & Lonvick Standards Track [Page 1] + +RFC 4252 SSH Authentication Protocol January 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Contributors ....................................................3 + 3. Conventions Used in This Document ...............................3 + 4. The Authentication Protocol Framework ...........................4 + 5. Authentication Requests .........................................4 + 5.1. Responses to Authentication Requests .......................5 + 5.2. The "none" Authentication Request ..........................7 + 5.3. Completion of User Authentication ..........................7 + 5.4. Banner Message .............................................7 + 6. Authentication Protocol Message Numbers .........................8 + 7. Public Key Authentication Method: "publickey" ...................8 + 8. Password Authentication Method: "password" .....................10 + 9. Host-Based Authentication: "hostbased" .........................12 + 10. IANA Considerations ...........................................14 + 11. Security Considerations .......................................14 + 12. References ....................................................15 + 12.1. Normative References .....................................15 + 12.2. Informative References ...................................15 + Authors' Addresses ................................................16 + Trademark Notice ..................................................16 + +1. Introduction + + The SSH authentication protocol is a general-purpose user + authentication protocol. It is intended to be run over the SSH + transport layer protocol [SSH-TRANS]. This protocol assumes that the + underlying protocols provide integrity and confidentiality + protection. + + This document should be read only after reading the SSH architecture + document [SSH-ARCH]. This document freely uses terminology and + notation from the architecture document without reference or further + explanation. + + The 'service name' for this protocol is "ssh-userauth". + + When this protocol starts, it receives the session identifier from + the lower-level protocol (this is the exchange hash H from the first + key exchange). The session identifier uniquely identifies this + session and is suitable for signing in order to prove ownership of a + private key. This protocol also needs to know whether the lower- + level protocol provides confidentiality protection. + + + + + + + +Ylonen & Lonvick Standards Track [Page 2] + +RFC 4252 SSH Authentication Protocol January 2006 + + +2. Contributors + + The major original contributors of this set of documents have been: + Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH + Communications Security Corp), and Markku-Juhani O. Saarinen + (University of Jyvaskyla). Darren Moffat was the original editor of + this set of documents and also made very substantial contributions. + + Many people contributed to the development of this document over the + years. People who should be acknowledged include Mats Andersson, Ben + Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, + Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff + Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph + Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas + Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon + Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and + Tadayoshi Kohno. Listing their names here does not mean that they + endorse this document, but that they have contributed to it. + +3. Conventions Used in This Document + + All documents related to the SSH protocols shall use the keywords + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe + requirements. These keywords are to be interpreted as described in + [RFC2119]. + + The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME + FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG + APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in + this document when used to describe namespace allocation are to be + interpreted as described in [RFC2434]. + + Protocol fields and possible values to fill them are defined in this + set of documents. Protocol fields will be defined in the message + definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as + follows. + + byte SSH_MSG_CHANNEL_DATA + uint32 recipient channel + string data + + Throughout these documents, when the fields are referenced, they will + appear within single quotes. When values to fill those fields are + referenced, they will appear within double quotes. Using the above + example, possible values for 'data' are "foo" and "bar". + + + + + +Ylonen & Lonvick Standards Track [Page 3] + +RFC 4252 SSH Authentication Protocol January 2006 + + +4. The Authentication Protocol Framework + + The server drives the authentication by telling the client which + authentication methods can be used to continue the exchange at any + given time. The client has the freedom to try the methods listed by + the server in any order. This gives the server complete control over + the authentication process if desired, but also gives enough + flexibility for the client to use the methods it supports or that are + most convenient for the user, when multiple methods are offered by + the server. + + Authentication methods are identified by their name, as defined in + [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as + supported. However, it MAY be sent by the client. The server MUST + always reject this request, unless the client is to be granted access + without any authentication, in which case, the server MUST accept + this request. The main purpose of sending this request is to get the + list of supported methods from the server. + + The server SHOULD have a timeout for authentication and disconnect if + the authentication has not been accepted within the timeout period. + The RECOMMENDED timeout period is 10 minutes. Additionally, the + implementation SHOULD limit the number of failed authentication + attempts a client may perform in a single session (the RECOMMENDED + limit is 20 attempts). If the threshold is exceeded, the server + SHOULD disconnect. + + Additional thoughts about authentication timeouts and retries may be + found in [ssh-1.2.30]. + +5. Authentication Requests + + All authentication requests MUST use the following message format. + Only the first few fields are defined; the remaining fields depend on + the authentication method. + + byte SSH_MSG_USERAUTH_REQUEST + string user name in ISO-10646 UTF-8 encoding [RFC3629] + string service name in US-ASCII + string method name in US-ASCII + .... method specific fields + + The 'user name' and 'service name' are repeated in every new + authentication attempt, and MAY change. The server implementation + MUST carefully check them in every message, and MUST flush any + accumulated authentication states if they change. If it is unable to + + + + + +Ylonen & Lonvick Standards Track [Page 4] + +RFC 4252 SSH Authentication Protocol January 2006 + + + flush an authentication state, it MUST disconnect if the 'user name' + or 'service name' changes. + + The 'service name' specifies the service to start after + authentication. There may be several different authenticated + services provided. If the requested service is not available, the + server MAY disconnect immediately or at any later time. Sending a + proper disconnect message is RECOMMENDED. In any case, if the + service does not exist, authentication MUST NOT be accepted. + + If the requested 'user name' does not exist, the server MAY + disconnect, or MAY send a bogus list of acceptable authentication + 'method name' values, but never accept any. This makes it possible + for the server to avoid disclosing information on which accounts + exist. In any case, if the 'user name' does not exist, the + authentication request MUST NOT be accepted. + + While there is usually little point for clients to send requests that + the server does not list as acceptable, sending such requests is not + an error, and the server SHOULD simply reject requests that it does + not recognize. + + An authentication request MAY result in a further exchange of + messages. All such messages depend on the authentication 'method + name' used, and the client MAY at any time continue with a new + SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST + abandon the previous authentication attempt and continue with the new + one. + + The following 'method name' values are defined. + + "publickey" REQUIRED + "password" OPTIONAL + "hostbased" OPTIONAL + "none" NOT RECOMMENDED + + Additional 'method name' values may be defined as specified in + [SSH-ARCH] and [SSH-NUMBERS]. + +5.1. Responses to Authentication Requests + + If the server rejects the authentication request, it MUST respond + with the following: + + byte SSH_MSG_USERAUTH_FAILURE + name-list authentications that can continue + boolean partial success + + + + +Ylonen & Lonvick Standards Track [Page 5] + +RFC 4252 SSH Authentication Protocol January 2006 + + + The 'authentications that can continue' is a comma-separated name- + list of authentication 'method name' values that may productively + continue the authentication dialog. + + It is RECOMMENDED that servers only include those 'method name' + values in the name-list that are actually useful. However, it is not + illegal to include 'method name' values that cannot be used to + authenticate the user. + + Already successfully completed authentications SHOULD NOT be included + in the name-list, unless they should be performed again for some + reason. + + The value of 'partial success' MUST be TRUE if the authentication + request to which this is a response was successful. It MUST be FALSE + if the request was not successfully processed. + + When the server accepts authentication, it MUST respond with the + following: + + byte SSH_MSG_USERAUTH_SUCCESS + + Note that this is not sent after each step in a multi-method + authentication sequence, but only when the authentication is + complete. + + The client MAY send several authentication requests without waiting + for responses from previous requests. The server MUST process each + request completely and acknowledge any failed requests with a + SSH_MSG_USERAUTH_FAILURE message before processing the next request. + + A request that requires further messages to be exchanged will be + aborted by a subsequent request. A client MUST NOT send a subsequent + request if it has not received a response from the server for a + previous request. A SSH_MSG_USERAUTH_FAILURE message MUST NOT be + sent for an aborted method. + + SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When + SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication + requests received after that SHOULD be silently ignored. + + Any non-authentication messages sent by the client after the request + that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed + to the service being run on top of this protocol. Such messages can + be identified by their message numbers (see Section 6). + + + + + + +Ylonen & Lonvick Standards Track [Page 6] + +RFC 4252 SSH Authentication Protocol January 2006 + + +5.2. The "none" Authentication Request + + A client may request a list of authentication 'method name' values + that may continue by using the "none" authentication 'method name'. + + If no authentication is needed for the user, the server MUST return + SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return + SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods + that may continue in its 'authentications that can continue' value. + + This 'method name' MUST NOT be listed as supported by the server. + +5.3. Completion of User Authentication + + Authentication is complete when the server has responded with + SSH_MSG_USERAUTH_SUCCESS. All authentication related messages + received after sending this message SHOULD be silently ignored. + + After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the + requested service. + +5.4. Banner Message + + In some jurisdictions, sending a warning message before + authentication may be relevant for getting legal protection. Many + UNIX machines, for example, normally display text from /etc/issue, + use TCP wrappers, or similar software to display a banner before + issuing a login prompt. + + The SSH server may send an SSH_MSG_USERAUTH_BANNER message at any + time after this authentication protocol starts and before + authentication is successful. This message contains text to be + displayed to the client user before authentication is attempted. The + format is as follows: + + byte SSH_MSG_USERAUTH_BANNER + string message in ISO-10646 UTF-8 encoding [RFC3629] + string language tag [RFC3066] + + By default, the client SHOULD display the 'message' on the screen. + However, since the 'message' is likely to be sent for every login + attempt, and since some client software will need to open a separate + window for this warning, the client software may allow the user to + explicitly disable the display of banners from the server. The + 'message' may consist of multiple lines, with line breaks indicated + by CRLF pairs. + + + + + +Ylonen & Lonvick Standards Track [Page 7] + +RFC 4252 SSH Authentication Protocol January 2006 + + + If the 'message' string is displayed, control character filtering, + discussed in [SSH-ARCH], SHOULD be used to avoid attacks by sending + terminal control characters. + +6. Authentication Protocol Message Numbers + + All message numbers used by this authentication protocol are in the + range from 50 to 79, which is part of the range reserved for + protocols running on top of the SSH transport layer protocol. + + Message numbers of 80 and higher are reserved for protocols running + after this authentication protocol, so receiving one of them before + authentication is complete is an error, to which the server MUST + respond by disconnecting, preferably with a proper disconnect message + sent to ease troubleshooting. + + After successful authentication, such messages are passed to the + higher-level service. + + These are the general authentication message codes: + + SSH_MSG_USERAUTH_REQUEST 50 + SSH_MSG_USERAUTH_FAILURE 51 + SSH_MSG_USERAUTH_SUCCESS 52 + SSH_MSG_USERAUTH_BANNER 53 + + In addition to the above, there is a range of message numbers (60 to + 79) reserved for method-specific messages. These messages are only + sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST + messages). Different authentication methods reuse the same message + numbers. + +7. Public Key Authentication Method: "publickey" + + The only REQUIRED authentication 'method name' is "publickey" + authentication. All implementations MUST support this method; + however, not all users need to have public keys, and most local + policies are not likely to require public key authentication for all + users in the near future. + + With this method, the possession of a private key serves as + authentication. This method works by sending a signature created + with a private key of the user. The server MUST check that the key + is a valid authenticator for the user, and MUST check that the + signature is valid. If both hold, the authentication request MUST be + accepted; otherwise, it MUST be rejected. Note that the server MAY + require additional authentications after successful authentication. + + + + +Ylonen & Lonvick Standards Track [Page 8] + +RFC 4252 SSH Authentication Protocol January 2006 + + + Private keys are often stored in an encrypted form at the client + host, and the user must supply a passphrase before the signature can + be generated. Even if they are not, the signing operation involves + some expensive computation. To avoid unnecessary processing and user + interaction, the following message is provided for querying whether + authentication using the "publickey" method would be acceptable. + + byte SSH_MSG_USERAUTH_REQUEST + string user name in ISO-10646 UTF-8 encoding [RFC3629] + string service name in US-ASCII + string "publickey" + boolean FALSE + string public key algorithm name + string public key blob + + Public key algorithms are defined in the transport layer + specification [SSH-TRANS]. The 'public key blob' may contain + certificates. + + Any public key algorithm may be offered for use in authentication. + In particular, the list is not constrained by what was negotiated + during key exchange. If the server does not support some algorithm, + it MUST simply reject the request. + + The server MUST respond to this message with either + SSH_MSG_USERAUTH_FAILURE or with the following: + + byte SSH_MSG_USERAUTH_PK_OK + string public key algorithm name from the request + string public key blob from the request + + To perform actual authentication, the client MAY then send a + signature generated using the private key. The client MAY send the + signature directly without first verifying whether the key is + acceptable. The signature is sent using the following packet: + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service name + string "publickey" + boolean TRUE + string public key algorithm name + string public key to be used for authentication + string signature + + + + + + + +Ylonen & Lonvick Standards Track [Page 9] + +RFC 4252 SSH Authentication Protocol January 2006 + + + The value of 'signature' is a signature by the corresponding private + key over the following data, in the following order: + + string session identifier + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service name + string "publickey" + boolean TRUE + string public key algorithm name + string public key to be used for authentication + + When the server receives this message, it MUST check whether the + supplied key is acceptable for authentication, and if so, it MUST + check whether the signature is correct. + + If both checks succeed, this method is successful. Note that the + server may require additional authentications. The server MUST + respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are + needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more + authentications are needed). + + The following method-specific message numbers are used by the + "publickey" authentication method. + + SSH_MSG_USERAUTH_PK_OK 60 + +8. Password Authentication Method: "password" + + Password authentication uses the following packets. Note that a + server MAY request that a user change the password. All + implementations SHOULD support password authentication. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service name + string "password" + boolean FALSE + string plaintext password in ISO-10646 UTF-8 encoding [RFC3629] + + Note that the 'plaintext password' value is encoded in ISO-10646 + UTF-8. It is up to the server how to interpret the password and + validate it against the password database. However, if the client + reads the password in some other encoding (e.g., ISO 8859-1 - ISO + Latin1), it MUST convert the password to ISO-10646 UTF-8 before + transmitting, and the server MUST convert the password to the + encoding used on that system for passwords. + + + + +Ylonen & Lonvick Standards Track [Page 10] + +RFC 4252 SSH Authentication Protocol January 2006 + + + From an internationalization standpoint, it is desired that if a user + enters their password, the authentication process will work + regardless of what OS and client software the user is using. Doing + so requires normalization. Systems supporting non-ASCII passwords + SHOULD always normalize passwords and user names whenever they are + added to the database, or compared (with or without hashing) to + existing entries in the database. SSH implementations that both + store the passwords and compare them SHOULD use [RFC4013] for + normalization. + + Note that even though the cleartext password is transmitted in the + packet, the entire packet is encrypted by the transport layer. Both + the server and the client should check whether the underlying + transport layer provides confidentiality (i.e., if encryption is + being used). If no confidentiality is provided ("none" cipher), + password authentication SHOULD be disabled. If there is no + confidentiality or no MAC, password change SHOULD be disabled. + + Normally, the server responds to this message with success or + failure. However, if the password has expired, the server SHOULD + indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. + In any case, the server MUST NOT allow an expired password to be used + for authentication. + + byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ + string prompt in ISO-10646 UTF-8 encoding [RFC3629] + string language tag [RFC3066] + + In this case, the client MAY continue with a different authentication + method, or request a new password from the user and retry password + authentication using the following message. The client MAY also send + this message instead of the normal password authentication request + without the server asking for it. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service name + string "password" + boolean TRUE + string plaintext old password in ISO-10646 UTF-8 encoding + [RFC3629] + string plaintext new password in ISO-10646 UTF-8 encoding + [RFC3629] + + + + + + + + +Ylonen & Lonvick Standards Track [Page 11] + +RFC 4252 SSH Authentication Protocol January 2006 + + + The server must reply to each request message with + SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another + SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as + follows: + + SSH_MSG_USERAUTH_SUCCESS - The password has been changed, and + authentication has been successfully completed. + + SSH_MSG_USERAUTH_FAILURE with partial success - The password has + been changed, but more authentications are needed. + + SSH_MSG_USERAUTH_FAILURE without partial success - The password + has not been changed. Either password changing was not supported, + or the old password was bad. Note that if the server has already + sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports + changing the password. + + SSH_MSG_USERAUTH_CHANGEREQ - The password was not changed because + the new password was not acceptable (e.g., too easy to guess). + + The following method-specific message numbers are used by the + password authentication method. + + SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 + +9. Host-Based Authentication: "hostbased" + + Some sites wish to allow authentication based on the host that the + user is coming from and the user name on the remote host. While this + form of authentication is not suitable for high-security sites, it + can be very convenient in many environments. This form of + authentication is OPTIONAL. When used, special care SHOULD be taken + to prevent a regular user from obtaining the private host key. + + The client requests this form of authentication by sending the + following message. It is similar to the UNIX "rhosts" and + "hosts.equiv" styles of authentication, except that the identity of + the client host is checked more rigorously. + + This method works by having the client send a signature created with + the private key of the client host, which the server checks with that + host's public key. Once the client host's identity is established, + authorization (but no further authentication) is performed based on + the user names on the server and the client, and the client host + name. + + + + + + +Ylonen & Lonvick Standards Track [Page 12] + +RFC 4252 SSH Authentication Protocol January 2006 + + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service name + string "hostbased" + string public key algorithm for host key + string public host key and certificates for client host + string client host name expressed as the FQDN in US-ASCII + string user name on the client host in ISO-10646 UTF-8 encoding + [RFC3629] + string signature + + Public key algorithm names for use in 'public key algorithm for host + key' are defined in the transport layer specification [SSH-TRANS]. + The 'public host key and certificates for client host' may include + certificates. + + The value of 'signature' is a signature with the private host key of + the following data, in this order: + + string session identifier + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service name + string "hostbased" + string public key algorithm for host key + string public host key and certificates for client host + string client host name expressed as the FQDN in US-ASCII + string user name on the client host in ISO-10646 UTF-8 encoding + [RFC3629] + + The server MUST verify that the host key actually belongs to the + client host named in the message, that the given user on that host is + allowed to log in, and that the 'signature' value is a valid + signature on the appropriate value by the given host key. The server + MAY ignore the client 'user name', if it wants to authenticate only + the client host. + + Whenever possible, it is RECOMMENDED that the server perform + additional checks to verify that the network address obtained from + the (untrusted) network matches the given client host name. This + makes exploiting compromised host keys more difficult. Note that + this may require special handling for connections coming through a + firewall. + + + + + + + + +Ylonen & Lonvick Standards Track [Page 13] + +RFC 4252 SSH Authentication Protocol January 2006 + + +10. IANA Considerations + + This document is part of a set. The IANA considerations for the SSH + protocol, as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and + this document, are detailed in [SSH-NUMBERS]. + +11. Security Considerations + + The purpose of this protocol is to perform client user + authentication. It assumed that this runs over a secure transport + layer protocol, which has already authenticated the server machine, + established an encrypted communications channel, and computed a + unique session identifier for this session. The transport layer + provides forward secrecy for password authentication and other + methods that rely on secret data. + + Full security considerations for this protocol are provided in + [SSH-ARCH]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lonvick Standards Track [Page 14] + +RFC 4252 SSH Authentication Protocol January 2006 + + +12. References + +12.1. Normative References + + [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Protocol Architecture", RFC 4251, January 2006. + + [SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Connection Protocol", RFC 4254, January 2006. + + [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Transport Layer Protocol", RFC 4253, January 2006. + + [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell + (SSH) Protocol Assigned Numbers", RFC 4250, January + 2006. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User + Names and Passwords", RFC 4013, February 2005. + +12.2. Informative References + + [ssh-1.2.30] Ylonen, T., "ssh-1.2.30/RFC", File within compressed + tarball ftp://ftp.funet.fi/pub/unix/security/login/ + ssh/ssh-1.2.30.tar.gz, November 1995. + + + + + + + + + + + + + +Ylonen & Lonvick Standards Track [Page 15] + +RFC 4252 SSH Authentication Protocol January 2006 + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Valimotie 17 + 00380 Helsinki + Finland + + EMail: [EMAIL PROTECTED] + + + Chris Lonvick (editor) + Cisco Systems, Inc. + 12515 Research Blvd. + Austin 78759 + USA + + EMail: [EMAIL PROTECTED] + +Trademark Notice + + "ssh" is a registered trademark in the United States and/or other + countries. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lonvick Standards Track [Page 16] + +RFC 4252 SSH Authentication Protocol January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + [EMAIL PROTECTED] + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Ylonen & Lonvick Standards Track [Page 17] +
