draft-ietf-secsh-auth-kbdinteract-02.txt   draft-ietf-secsh-auth-kbdinteract-03.txt 
Network Working Group M. Forssen Network Working Group F. Cusack
INTERNET-DRAFT Appgate AB INTERNET-DRAFT Google, Inc.
draft-ietf-secsh-auth-kbdinteract-02.txt F. Cusack Expires October 2, 2002 M. Forssen
Expires in six months Qwest Internet Solutions Appgate AB
1 March 2001 April 2, 2002
Generic Message Exchange Authentication For SSH Generic Message Exchange Authentication For SSH
<draft-ietf-secsh-auth-kbdinteract-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. <http://www.ietf.org/ietf/1id-abstracts.txt>.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. <http://www.ietf.org/shadow.html>.
This Internet-Draft will expire on October 2, 2002.
Abstract Abstract
SSH is a protocol for secure remote login and other secure network SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes a general services over an insecure network. This document describes a general
purpose authentication method for the SSH protocol, suitable for purpose authentication method for the SSH protocol, suitable for
interactive authentications where the authentication data should be interactive authentications where the authentication data should be
entered via a keyboard. The major goal of this method is to allow entered via a keyboard. The major goal of this method is to allow
the SSH client to support a whole class of authentication the SSH client to support a whole class of authentication
mechanism(s) without knowing the specifics of the actual mechanism(s) without knowing the specifics of the actual
skipping to change at page 2, line 15 skipping to change at page 2, line 15
1. Introduction 1. Introduction
The SSH authentication protocol is a general-purpose user The SSH authentication protocol is a general-purpose user
authentication protocol. It is intended to be run over the SSH authentication protocol. It is intended to be run over the SSH
transport layer protocol [SSH-TRANS]. The protocol assumes that the transport layer protocol [SSH-TRANS]. The protocol assumes that the
underlying protocols provide integrity and confidentiality underlying protocols provide integrity and confidentiality
protection. protection.
This document describes a general purpose authentication method for This document describes a general purpose authentication method for
the SSH protocol. This method is suitable for interactive the SSH protocol. This method is suitable for interactive
authentication methods which does not need any special software authentication methods which do not need any special software support
support on the client side. Instead all authentication data should be on the client side. Instead all authentication data should be
entered via the keyboard. The major goal of this method is to allow entered via the keyboard. The major goal of this method is to allow
the SSH client to have little or no knowledge of the specifics of the the SSH client to have little or no knowledge of the specifics of the
underlying authentication mechanism(s) used by the SSH server. This underlying authentication mechanism(s) used by the SSH server. This
will allow the server to arbitrarily select or change the underlying will allow the server to arbitrarily select or change the underlying
authentication mechanism(s) without having to update client code. authentication mechanism(s) without having to update client code.
The name for this authentication method is "keyboard-interactive". The name for this authentication method is "keyboard-interactive".
This document should be read only after reading the SSH architecture This document should be read only after reading the SSH architecture
document [SSH-ARCH] and the SSH authentication document [SSH- document [SSH-ARCH] and the SSH authentication document
USERAUTH]. This document freely uses terminology and notation from [SSH-USERAUTH]. This document freely uses terminology and notation
both documents without reference or further explanation. from both documents without reference or further explanation.
This document also describes some of the client interaction with the This document also describes some of the client interaction with the
user in obtaining the authentication information. While this is user in obtaining the authentication information. While this is
somewhat out of the scope of a protocol specification, it is still somewhat out of the scope of a protocol specification, it is still
described here since some aspects of the protocol are specifically described here since some aspects of the protocol are specifically
designed based on user interface issues, and omitting this designed based on user interface issues, and omitting this
information may lead to incompatible or awkward implementations. information may lead to incompatible or awkward implementations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Rationale 2. Rationale
Currently defined authentication methods for SSH are tightly coupled Currently defined authentication methods for SSH are tightly coupled
with the underlying authentication mechanism. This makes it difficult with the underlying authentication mechanism. This makes it
to add new mechanisms for authentication as all clients must be difficult to add new mechanisms for authentication as all clients
updated to support the new mechanism. With the generic method defined must be updated to support the new mechanism. With the generic
here, clients will not require code changes to support further new method defined here, clients will not require code changes to support
authentication mechanisms, provided the mechanism fits the new authentication mechanisms, and if a separate authentication layer
requirements for keyboard-interactive. And if a separate is used, such as [PAM], then the server may not need any code changes
authentication layer is used, such as [PAM], then the server may not either.
need any code changes either.
This presents a significant advantage to other methods, such as the This presents a significant advantage to other methods, such as the
"password" method (defined in [SSH-USERAUTH]), as new (presumably "password" method (defined in [SSH-USERAUTH]), as new (presumably
stronger) methods may be added "at will" and system security can be stronger) methods may be added "at will" and system security can be
transparently enhanced. transparently enhanced.
Challenge-response and One Time Password mechanisms are also easily Challenge-response and One Time Password mechanisms are also easily
supported with this authentication method. supported with this authentication method.
This authentication method is however limited to authentication This authentication method is however limited to authentication
mechanisms which do not require any special code, such as hardware mechanisms which do not require any special code, such as hardware
drivers or password mangling, on the client. drivers or password mangling, on the client.
3. Protocol Exchanges 3. Protocol Exchanges
The client initiates the authentication with a The client initiates the authentication with a
SSH_MSG_USERAUTH_REQUEST message. The server then requests SSH_MSG_USERAUTH_REQUEST message. The server then requests
authentication information from the client with a authentication information from the client with a
SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the
information from the user and then responds with a information from the user and then responds with a
SSH_MSG_USERAUTH_INFO_RESPONSE message. The server MUST not send SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send
another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the
answer from the client. answer from the client.
3.1 Initial Exchange 3.1 Initial Exchange
The authentication starts with the client sending the following The authentication starts with the client sending the following
packet: packet:
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name (ISO-10646 UTF-8) string user name (ISO-10646 UTF-8)
string service name (US-ASCII) string service name (US-ASCII)
string "keyboard-interactive" (US-ASCII) string "keyboard-interactive" (US-ASCII)
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-3066])
string submethods (ISO-10646 UTF-8) string submethods (ISO-10646 UTF-8)
The language tag indicates the client's preferred language. The The language tag is deprecated and SHOULD be the empty string. It
server SHOULD use this language for all text that is to be presented may be removed in a future revision of this specification. The
to the user in the subsequent exchanges. server SHOULD instead select the language used based on the tags
communicated during key exchange [SSH-TRANS].
If the server cannot support the requested language, the language to If the language tag is not the empty string, the server SHOULD use
be used is implementation-dependent. the specified language for any messages sent to the client as part of
this protocol. The language tag SHOULD NOT be used for language
selection for messages outside of this protocol. The language to be
used if the server does not support the requested language is
implementation-dependent.
The submethods field is included so the user can give a hint of which The submethods field is included so the user can give a hint of which
actual methods he wants to use. It is a a comma-separated list of actual methods he wants to use. It is a a comma-separated list of
authentication submethods (software or hardware) which the user authentication submethods (software or hardware) which the user
prefers. If the client has knowledge of the submethods preferred by prefers. If the client has knowledge of the submethods preferred by
the user, presumably through a configuration setting, it MAY use the the user, presumably through a configuration setting, it MAY use the
submethods field to pass this information to the server. Otherwise it submethods field to pass this information to the server. Otherwise
MUST send the empty string. it MUST send the empty string.
The actual names of the submethods is something which the user and The actual names of the submethods is something which the user and
the server needs to agree upon. the server needs to agree upon.
Server interpretation of the submethods field is implementation- Server interpretation of the submethods field is implementation-
dependent. dependent.
One possible implementation strategy of the submethods field on the One possible implementation strategy of the submethods field on the
server is that, unless the user may use multiple different server is that, unless the user may use multiple different
submethods, the server ignores this field. If the user may submethods, the server ignores this field. If the user may
skipping to change at page 4, line 28 skipping to change at page 4, line 36
The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS,
SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.
The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
if the failure is based on the user name or service name; instead it if the failure is based on the user name or service name; instead it
SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just
like the one(s) which would have been sent in cases where like the one(s) which would have been sent in cases where
authentication should proceed, and then send the failure message authentication should proceed, and then send the failure message
(after a suitable delay, as described below). The goal is to make it (after a suitable delay, as described below). The goal is to make it
impossible to find valid user names by just comparing the results impossible to find valid usernames by just comparing the results when
when authenticating as different users. authenticating as different users.
3.2 Information Requests 3.2 Information Requests
Requests are generated from the server using the Requests are generated from the server using the
SSH_MSG_USERAUTH_INFO_REQUEST message. SSH_MSG_USERAUTH_INFO_REQUEST message.
The server may send as many requests as are necessary to authenticate The server may send as many requests as are necessary to authenticate
the client; the client MUST be prepared to handle multiple exchanges. the client; the client MUST be prepared to handle multiple exchanges.
However the server MUST never have more than one However the server MUST NOT ever have more than one
SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is it may not SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may
send another request before the client has answered. not send another request before the client has answered.
The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:
byte SSH_MSG_USERAUTH_INFO_REQUEST byte SSH_MSG_USERAUTH_INFO_REQUEST
string name (ISO-10646 UTF-8) string name (ISO-10646 UTF-8)
string instruction (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8)
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-3066])
int num-prompts int num-prompts
string prompt[1] (ISO-10646 UTF-8) string prompt[1] (ISO-10646 UTF-8)
boolean echo[1] boolean echo[1]
... ...
string prompt[num-prompts] (ISO-10646 UTF-8) string prompt[num-prompts] (ISO-10646 UTF-8)
boolean echo[num-prompts] boolean echo[num-prompts]
The server SHOULD limit the length of the name and prompt fields to The server SHOULD take into consideration that some clients may not
30 characters. No restrictions are placed on the instruction field. be able to properly display a long name or prompt field (see next
section), and limit the lengths of those fields if possible. For
example, instead of an instruction field of "Enter Password" and a
prompt field of "Password for user23@host.domain: ", a better choice
might be an instruction field of
"Password authentication for user23@host.domain" and a prompt field
of "Password: ". It is expected that this authentication method
would typically be backended by [PAM] and so such choices would not
be possible.
The name and instruction fields MAY be empty strings, the client MUST The name and instruction fields MAY be empty strings, the client MUST
be prepared to handle this correctly. be prepared to handle this correctly. The prompt field(s) MUST NOT
be empty strings.
The language tag SHOULD describe the language used in the textual
fields. If the server does not know the language used, or if
multiple languages are used, the language tag MUST be the empty
string.
The num-prompts field may be `0', in which case there will be no The num-prompts field may be `0', in which case there will be no
prompt/echo fields in the message, but the client MUST still display prompt/echo fields in the message, but the client SHOULD still
the name and instruction fields (as described below). display the name and instruction fields (as described below).
3.3 User Interface 3.3 User Interface
Upon receiving a request message, the client SHOULD prompt the user Upon receiving a request message, the client SHOULD prompt the user
as follows: as follows:
A command line interface (CLI) client SHOULD print the name and A command line interface (CLI) client SHOULD print the name and
instruction (if non-empty), adding newlines. Then for each prompt in instruction (if non-empty), adding newlines. Then for each prompt in
turn, the client MUST display the prompt and read the user input. turn, the client SHOULD display the prompt and read the user input.
A graphical user interface (GUI) client SHOULD present a dialog A graphical user interface (GUI) client has many choices on how to
window, using the name (if non-empty) as the title of the window, the prompt the user. One possibility is to use the name field (possibly
instruction (if non-empty) as a text message inside the dialog, and prefixed with the application's name) as the title of a dialog window
the appropriate number of entry fields with the prompts as labels. A in which the prompt(s) are presented. In that dialog window, the
GUI client SHOULD NOT present each prompt in a separate window. instruction field would be a text message, and the prompts would be
labels for text entry fields. All fields SHOULD be presented to the
user, for example an implementation SHOULD NOT discard the name field
because its windows lack titles; it SHOULD instead find another way
to display this information. If prompts are presented in a dialog
window, then the client SHOULD NOT present each prompt in a separate
window.
All clients MUST properly handle an instruction field with embedded All clients MUST properly handle an instruction field with embedded
newlines. They MUST also be able to display at least 30 characters newlines. They SHOULD also be able to display at least 30 characters
for the name and prompts. If the server presents names/prompts for the name and prompts. If the server presents names or prompts
longer than 30 characters, the client MAY truncate these fields to longer than 30 characters, the client MAY truncate these fields to
the length it can display. If the client does truncate any fields, the length it can display. If the client does truncate any fields,
there SHOULD be an obvious indication that such truncation has there MUST be an obvious indication that such truncation has occured.
occurred. The instruction field SHOULD NOT be truncated.
Clients SHOULD use control character filtering as discussed in [SSH- Clients SHOULD use control character filtering as discussed in
ARCH] to avoid attacks by including terminal control characters in [SSH-ARCH] to avoid attacks by including terminal control characters
the fields to be displayed. in the fields to be displayed.
For each prompt, the corresponding echo field indicates whether or For each prompt, the corresponding echo field indicates whether or
not the user input should be echoed or not. Clients SHOULD correctly not the user input should be echoed as characters are typed. Clients
handle echo for each prompt independently of other prompts in the SHOULD correctly echo/mask user input for each prompt independently
request message. Clients SHOULD NOT add any additional characters to of other prompts in the request message. If a client does not honor
the prompt such as ": "; the server is responsible for supplying all the echo field for whatever reason, then the client MUST err on the
text to be displayed to the user. Clients MUST also accept empty side of masking input. A GUI client might like to have a checkbox
responses from the user and pass them on as empty strings. toggling echo/mask. Clients SHOULD NOT add any additional characters
to the prompt such as ": " (colon-space); the server is responsible
for supplying all text to be displayed to the user. Clients MUST
also accept empty responses from the user and pass them on as empty
strings.
3.4 Information Responses 3.4 Information Responses
After obtaining the requested information from the user, the client After obtaining the requested information from the user, the client
MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.
The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
follows: follows:
byte SSH_MSG_USERAUTH_INFO_RESPONSE byte SSH_MSG_USERAUTH_INFO_RESPONSE
skipping to change at page 6, line 40 skipping to change at page 7, line 17
(e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
before transmitting. before transmitting.
If the num-responses field does not match the num-prompts field in If the num-responses field does not match the num-prompts field in
the request message, the server MUST send a failure message. the request message, the server MUST send a failure message.
In the case that the server sends a `0' num-prompts field in the In the case that the server sends a `0' num-prompts field in the
request message, the client MUST send a response message with a `0' request message, the client MUST send a response message with a `0'
num-responses field. num-responses field.
The responses must be ordered as the prompts were ordered. That is,
response[n] must be the answer to prompt[n].
After receiving the response, the server MUST send either a After receiving the response, the server MUST send either a
SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
SSH_MSG_USERAUTH_INFO_REQUEST message. SSH_MSG_USERAUTH_INFO_REQUEST message.
If the server fails to authenticate the user (through the underlying If the server fails to authenticate the user (through the underlying
authentication mechanism(s)), it SHOULD NOT send another request authentication mechanism(s)), it SHOULD NOT send another request
message(s) in an attempt to obtain new authentication data, instead message(s) in an attempt to obtain new authentication data, instead
it SHOULD send a failure message. The only time the server should it SHOULD send a failure message. The only time the server should
send multiple request messages is if additional authentication data send multiple request messages is if additional authentication data
is needed (i.e., because there are multiple underlying authentication is needed (i.e., because there are multiple underlying authentication
mechanisms that must be used to authenticate the user). mechanisms that must be used to authenticate the user).
If the server intends to respond with a failure message, it MAY delay If the server intends to respond with a failure message, it MAY delay
for an implementation dependent time before sending to the client. for an implementation-dependent time before sending to the client.
It is suspected that implementations are likely to make the time It is suspected that implementations are likely to make the time
delay a configurable, a suggested default is 2 seconds. delay a configurable, a suggested default is 2 seconds.
4. Authentication Example 4. Authentication Examples
Here is an example exchange between a client and server: Here are two example exchanges between a client and server. The
first is an example of a challenge/response implementation. This is
an authentication that is not otherwise possible with other
authentication methods.
C: byte SSH_MSG_USERAUTH_REQUEST C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23" C: string "user23"
C: string "ssh-userauth" C: string "ssh-userauth"
C: string "keyboard-interactive" C: string "keyboard-interactive"
C: string "en-US"
C: string "" C: string ""
C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "CryptoCARD Authentication" S: string "CRYPTOCard Authentication"
S: string "The challenge is '14315716'" S: string "The challenge is '14315716'"
S: string "en-US" S: string "en-US"
S: int 1 S: int 1
S: string "Response: " S: string "Response: "
S: boolean TRUE S: boolean TRUE
[Client prompts user for password] [Client prompts user for password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1 C: int 1
C: string "6d757575" C: string "6d757575"
S: byte SSH_MSG_USERAUTH_SUCCESS S: byte SSH_MSG_USERAUTH_SUCCESS
The second example is of a standard password authentication, in
this case the user's password is expired.
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string "en-US"
C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Authentication"
S: string ""
S: string "en-US"
S: int 1
S: string "Password: "
S: boolean FALSE
[Client prompts user for password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "password"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
S: string "Your password has expired."
S: string "en-US"
S: int 2
S: string "Enter new password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
[Client prompts user for new password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 2
C: string "newpass"
C: string "newpass"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password changed"
S: string "Password successfully changed for user23."
S: string "en-US"
S: int 0
[Client displays message to user]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 0
S: byte SSH_MSG_USERAUTH_SUCCESS
5. Protocol constants 5. Protocol constants
The following method-specific constants are used with this The following method-specific constants are used with this
authentication method: authentication method:
SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_REQUEST 60
SSH_MSG_USERAUTH_INFO_RESPONSE 61 SSH_MSG_USERAUTH_INFO_RESPONSE 61
6. References 6. References
[PAM] Samar, V., Schemers, R., "Unified Login With Pluggable [PAM] Samar, V., Schemers, R., "Unified Login With
Authentication Modules (PAM)", OSF RFC 86.0, October 1995 Pluggable Authentication Modules (PAM)", OSF RFC
86.0, October 1995
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC-1766] Alvestrand, H., "Tags for the Identification of [RFC-2279] Yergeau, F., "UTF-8, a transformation format of
Languages", March 1995. Unicode and ISO 10646", RFC 2279, October 1996.
[RFC-2279] Yergeau, F., "UTF-8, a Transformation Format of Unicode [RFC-3066] Alvestrand, H., "Tags for the Identification of
and ISO 10646", October 1996. Languages", BCP 47, RFC 3066, January 2001.
[SSH-ARCH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, "SSH Protocol Architecture", Internet Draft, draft-ietf- Lehtinen, S., "SSH Protocol Architecture", work in
secsh-architecture-06.txt progress, draft-ietf-secsh-architecture-12.txt,
January, 2002.
[SSH-CONNECT] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, "SSH Connection Protocol", Internet Draft, draft-ietf- Lehtinen, S., "SSH Connection Protocol", work in
secsh-connect-08.txt progress, draft-ietf-secsh-connect-15.txt, January,
2002.
[SSH-TRANS] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, "SSH Transport Layer Protocol", Internet Draft, draft- Lehtinen, S., "SSH Transport Layer Protocol", work in
ietf-secsh-transport-08.txt progress, draft-ietf-secsh-transport-14.txt, March,
2002.
[SSH-USERAUTH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, "SSH Authentication Protocol", Internet Draft, draft-ietf- Lehtinen, S., "SSH Authentication Protocol", work in
secsh-userauth-08.txt progress, draft-ietf-secsh-userauth-15.txt, February,
2002.
7. Author's Addresses 7. Author's Addresses
Frank Cusack Frank Cusack
Qwest Internet Solutions Google, Inc.
1200 Harbor Blvd, 8th Fl. 2400 Bayshore Parkway
Weehawken, NJ 07087 Mountain View, CA 94043
Email: fcusack@iconnet.net Email: frank@google.com
Martin Forssen Martin Forssen
Appgate AB Appgate AB
Stora Badhusgatan 18-20 Stora Badhusgatan 18-20
SE-411 21 Gothenburg SE-411 21 Gothenburg
SWEDEN SWEDEN
Email: maf@appgate.com Email: maf@appgate.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/