aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt
diff options
context:
space:
mode:
authorErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
committerErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
commit84adefa331c4159d432d22840663c38f155cd4c1 (patch)
treebff9a9c66adda4df2106dfd0e5c053ab182a12bd /lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt
downloadotp-84adefa331c4159d432d22840663c38f155cd4c1.tar.gz
otp-84adefa331c4159d432d22840663c38f155cd4c1.tar.bz2
otp-84adefa331c4159d432d22840663c38f155cd4c1.zip
The R13B03 release.OTP_R13B03
Diffstat (limited to 'lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt')
-rw-r--r--lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt896
1 files changed, 896 insertions, 0 deletions
diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt
new file mode 100644
index 0000000000..9dae578a35
--- /dev/null
+++ b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt
@@ -0,0 +1,896 @@
+
+
+
+Network Working Group T. Ylonen
+Internet-Draft SSH Communications Security Corp
+Expires: March 2, 2003 D. Moffat, Ed.
+ Sun Microsystems, Inc
+ September 2002
+
+
+ SSH Authentication Protocol
+ draft-ietf-secsh-userauth-18.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on March 2, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ 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 & Moffat Expires March 2, 2003 [Page 1]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+Table of Contents
+
+ 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Conventions Used in This Document . . . . . . . . . . . . . 3
+ 3.1 The Authentication Protocol Framework . . . . . . . . . . . 3
+ 3.1.1 Authentication Requests . . . . . . . . . . . . . . . . . . 4
+ 3.1.2 Responses to Authentication Requests . . . . . . . . . . . . 5
+ 3.1.3 The "none" Authentication Request . . . . . . . . . . . . . 6
+ 3.1.4 Completion of User Authentication . . . . . . . . . . . . . 6
+ 3.1.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2 Authentication Protocol Message Numbers . . . . . . . . . . 7
+ 3.3 Public Key Authentication Method: publickey . . . . . . . . 8
+ 3.4 Password Authentication Method: password . . . . . . . . . . 10
+ 3.5 Host-Based Authentication: hostbased . . . . . . . . . . . . 11
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . 12
+ Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Informative . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
+ Intellectual Property and Copyright Statements . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 2]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+1. Contributors
+
+ The major original contributors of this document were: Tatu Ylonen,
+ Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications
+ Security Corp), and Markku-Juhani O. Saarinen (University of
+ Jyvaskyla)
+
+ The document editor is: [email protected]. Comments on this
+ internet draft should be sent to the IETF SECSH working group,
+ details at: http://ietf.org/html.charters/secsh-charter.html
+
+2. 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.
+
+3. Conventions Used in This Document
+
+ The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+ and "MAY" that appear in this document are to be interpreted as
+ described in [RFC2119]
+
+ The used data types and terminology are specified in the architecture
+ document [SSH-ARCH]
+
+ The architecture document also discusses the algorithm naming
+ conventions that MUST be used with the SSH protocols.
+
+3.1 The Authentication Protocol Framework
+
+ The server drives the authentication by telling the client which
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 3]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ 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 allowed in
+ 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.
+
+3.1.1 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 [RFC2279])
+ string service name (in US-ASCII)
+ string method name (US-ASCII)
+ The rest of the packet is method-specific.
+
+ The user name and service 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 flush some
+ authentication state, it MUST disconnect if the user 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,
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 4]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ authentication MUST NOT be accepted.
+
+ If the requested user does not exist, the server MAY disconnect, or
+ MAY send a bogus list of acceptable authentication methods, 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 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
+ 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.
+
+3.1.2 Responses to Authentication Requests
+
+ If the server rejects the authentication request, it MUST respond
+ with the following:
+
+ byte SSH_MSG_USERAUTH_FAILURE
+ string authentications that can continue
+ boolean partial success
+
+ "Authentications that can continue" is a comma-separated list of
+ authentication method names that may productively continue the
+ authentication dialog.
+
+ It is RECOMMENDED that servers only include those methods in the list
+ that are actually useful. However, it is not illegal to include
+ methods that cannot be used to authenticate the user.
+
+ Already successfully completed authentications SHOULD NOT be included
+ in the list, unless they really should be performed again for some
+ reason.
+
+ "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:
+
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 5]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ 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 results in further exchange of messages will be
+ aborted by a second request. It is not possible to send a second
+ request without waiting for a response from the server, if the first
+ request will result in further exchange of messages. No
+ SSH_MSG_USERAUTH_FAILURE message will be sent for the 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 Message Numbers
+ (Section 3.2)).
+
+3.1.3 The "none" Authentication Request
+
+ A client may request a list of authentication methods that may
+ continue by using the "none" authentication method.
+
+ If no authentication at all 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
+ authentication methods that can continue.
+
+ This method MUST NOT be listed as supported by the server.
+
+3.1.4 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.
+
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 6]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+3.1.5 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',
+ or use "tcp wrappers" or similar software to display a banner before
+ issuing a login prompt.
+
+ The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time
+ 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 (ISO-10646 UTF-8)
+ string language tag (as defined in [RFC3066])
+
+ The client SHOULD by default 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.
+
+ If the message string is displayed, control character filtering
+ discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending
+ terminal control characters.
+
+3.2 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 first to ease troubleshooting).
+
+ After successful authentication, such messages are passed to the
+ higher-level service.
+
+ These are the general authentication message codes:
+
+ #define SSH_MSG_USERAUTH_REQUEST 50
+ #define SSH_MSG_USERAUTH_FAILURE 51
+ #define SSH_MSG_USERAUTH_SUCCESS 52
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 7]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ #define SSH_MSG_USERAUTH_BANNER 53
+
+ In addition to the above, there is a range of message numbers
+ (60..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.
+
+3.3 Public Key Authentication Method: publickey
+
+ The only REQUIRED authentication method is public key 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.)
+
+ 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 key would be acceptable.
+
+ byte SSH_MSG_USERAUTH_REQUEST
+ string user name
+ string service
+ 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
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 8]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ 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
+ string "publickey"
+ boolean TRUE
+ string public key algorithm name
+ string public key to be used for authentication
+ string signature
+
+ 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
+ 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.
+
+ /* Key-based */
+ #define SSH_MSG_USERAUTH_PK_OK 60
+
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 9]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+3.4 Password Authentication Method: password
+
+ Password authentication uses the following packets. Note that a
+ server MAY request the user to change the password. All
+ implementations SHOULD support password authentication.
+
+ byte SSH_MSG_USERAUTH_REQUEST
+ string user name
+ string service
+ string "password"
+ boolean FALSE
+ string plaintext password (ISO-10646 UTF-8)
+
+ Note that the password is encoded in ISO-10646 UTF-8. It is up to
+ the server how it interprets the password and validates 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.
+
+ 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 anycase the server MUST NOT allow an expired password to be used
+ for authentication.
+
+ byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
+ string prompt (ISO-10646 UTF-8)
+ string language tag (as defined in [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
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 10]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ string "password"
+ boolean TRUE
+ string plaintext old password (ISO-10646 UTF-8)
+ string plaintext new password (ISO-10646 UTF-8)
+
+ The server must reply to 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.
+
+ #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60
+
+
+3.5 Host-Based Authentication: hostbased
+
+ Some sites wish to allow authentication based on the host where 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,
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 11]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ authorization (but no further authentication) is performed based on
+ the user names on the server and the client, and the client host
+ name.
+
+ byte SSH_MSG_USERAUTH_REQUEST
+ string user name
+ string service
+ string "hostbased"
+ string public key algorithm for host key
+ string public host key and certificates for client host
+ string client host name (FQDN; US-ASCII)
+ string user name on the client host (ISO-10646 UTF-8)
+ string signature
+
+ Public key algorithm names for use in "public key algorithm for host
+ key" are defined in the transport layer specification. The "public
+ host key for client host" may include certificates.
+
+ 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
+ string "hostbased"
+ string public key algorithm for host key
+ string public host key and certificates for client host
+ string client host name (FQDN; US-ASCII)
+ string user name on the client host(ISO-10646 UTF-8)
+
+ 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 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.
+
+ It is RECOMMENDED that whenever possible, 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.
+
+4. Security Considerations
+
+ The purpose of this protocol is to perform client user
+ authentication. It assumed that this runs over a secure transport
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 12]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ 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
+ Section 8 of [SSH-ARCH]
+
+Normative
+
+ [SSH-ARCH]
+ Ylonen, T., "SSH Protocol Architecture", I-D
+ draft-ietf-architecture-15.txt, Oct 2003.
+
+ [SSH-TRANS]
+ Ylonen, T., "SSH Transport Layer Protocol", I-D
+ draft-ietf-transport-17.txt, Oct 2003.
+
+ [SSH-USERAUTH]
+ Ylonen, T., "SSH Authentication Protocol", I-D
+ draft-ietf-userauth-18.txt, Oct 2003.
+
+ [SSH-CONNECT]
+ Ylonen, T., "SSH Connection Protocol", I-D
+ draft-ietf-connect-18.txt, Oct 2003.
+
+ [SSH-NUMBERS]
+ Lehtinen, S. and D. Moffat, "SSH Protocol Assigned
+ Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct
+ 2003.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+Informative
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of
+ Languages", BCP 47, RFC 3066, January 2001.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 13]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+Authors' Addresses
+
+ Tatu Ylonen
+ SSH Communications Security Corp
+ Fredrikinkatu 42
+ HELSINKI FIN-00100
+ Finland
+
+
+
+ Darren J. Moffat (editor)
+ Sun Microsystems, Inc
+ 17 Network Circle
+ Menlo Park 95025
+ USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 14]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+ The IETF has been notified of intellectual property rights claimed in
+ regard to some or all of the specification contained in this
+ document. For more information consult the online list of claimed
+ rights.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 15]
+
+Internet-Draft SSH Authentication Protocol September 2002
+
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Moffat Expires March 2, 2003 [Page 16] \ No newline at end of file