draft-ietf-secsh-gsskeyex-02.txt   draft-ietf-secsh-gsskeyex-03.txt 
Network Working Group J. Hutzelman Network Working Group J. Hutzelman
Internet-Draft CMU Internet-Draft CMU
Expires: January 18, 2002 J. Salowey Expires: July 15, 2002 J. Salowey
Cisco Systems Cisco Systems
J. Galbraith J. Galbraith
Van Dyke Technologies, Inc. Van Dyke Technologies, Inc.
V. Welch V. Welch
U Chicago / ANL U Chicago / ANL
July 20, 2001 January 14, 2002
GSSAPI Authentication and Key Exchange for the Secure Shell Protocol GSSAPI Authentication and Key Exchange for the Secure Shell Protocol
draft-ietf-secsh-gsskeyex-02 draft-ietf-secsh-gsskeyex-03
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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions 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 other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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 January 18, 2002. This Internet-Draft will expire on July 15, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
The Secure Shell protocol (SSH) is a protocol for secure remote The Secure Shell protocol (SSH) is a protocol for secure remote
login and other secure network services over an insecure network. login and other secure network services over an insecure network.
The Generic Security Service Application Program Interface (GSS-API) The Generic Security Service Application Program Interface (GSS-API)
[2] provides security services to callers in a mechanism-independent [2] provides security services to callers in a mechanism-independent
fashion. fashion.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
This section defines a class of key exchange methods which combine This section defines a class of key exchange methods which combine
the Diffie-Hellman key exchange from section 6 of [11] with mutual the Diffie-Hellman key exchange from section 6 of [11] with mutual
authentication using GSSAPI. authentication using GSSAPI.
Since the GSSAPI key exchange methods described in this section do Since the GSSAPI key exchange methods described in this section do
not require the use of public key signature or encryption not require the use of public key signature or encryption
algorithms, they MAY be used with any host key algorithm, including algorithms, they MAY be used with any host key algorithm, including
the "null" algorithm described in Section 5. the "null" algorithm described in Section 5.
2.1 Generic method description 2.1 Generic GSSAPI Key Exchange
The following symbols are used in this description: The following symbols are used in this description:
o C is the client, and S is the server o C is the client, and S is the server
o p is a large safe prime, g is a generator for a subgroup of o p is a large safe prime, g is a generator for a subgroup of
GF(p), and q is the order of the subgroup GF(p), and q is the order of the subgroup
o V_S is S's version string, and V_C is C's version string o V_S is S's version string, and V_C is C's version string
skipping to change at page 5, line 6 skipping to change at page 5, line 6
identity. identity.
* If the resulting major_status code is GSS_S_COMPLETE and the * If the resulting major_status code is GSS_S_COMPLETE and the
mutual_state flag is not true, then mutual authentication has mutual_state flag is not true, then mutual authentication has
not been established, and the key exchange MUST fail. not been established, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and the * If the resulting major_status code is GSS_S_COMPLETE and the
integ_avail flag is not true, then per-message integrity integ_avail flag is not true, then per-message integrity
protection is not available, and the key exchange MUST fail. protection is not available, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and the * If the resulting major_status code is GSS_S_COMPLETE and both
mutual_state flag is true, the resulting output token is sent the mutual_state and integ_avail flags are true, the
to S. resulting output token is sent to S.
* If the resulting major_status code is GSS_S_CONTINUE_NEEDED, * If the resulting major_status code is GSS_S_CONTINUE_NEEDED,
the the output_token is sent to S, which will reply with a the the output_token is sent to S, which will reply with a
new token to be provided to GSS_Init_sec_context. new token to be provided to GSS_Init_sec_context.
* The client MUST also include "e" with the first message it * The client MUST also include "e" with the first message it
sends to the server during this process; if the server sends to the server during this process; if the server
receives more than one "e" or none at all, the key exchange receives more than one "e" or none at all, the key exchange
fails. fails.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
non-zero length to be sent to the server. In this case, the non-zero length to be sent to the server. In this case, the
key exchange MUST fail. key exchange MUST fail.
3. S calls GSS_Accept_sec_context, using the token received from C. 3. S calls GSS_Accept_sec_context, using the token received from C.
* If the resulting major_status code is GSS_S_COMPLETE and the * If the resulting major_status code is GSS_S_COMPLETE and the
mutual_state flag is not true, then mutual authentication has mutual_state flag is not true, then mutual authentication has
not been established, and the key exchange MUST fail. not been established, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and the * If the resulting major_status code is GSS_S_COMPLETE and the
mutual_state flag is true, then the security context has been integ_avail flag is not true, then per-message integrity
established, and processing continues with step 4. protection is not available, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and both
the mutual_state and integ_avail flags are true, then the
security context has been established, and processing
continues with step 4.
* If the resulting major_status code is GSS_S_CONTINUE_NEEDED, * If the resulting major_status code is GSS_S_CONTINUE_NEEDED,
then the output token is sent to C, and processing continues then the output token is sent to C, and processing continues
with step 2. with step 2.
* If the resulting major_status code is GSS_S_COMPLETE, but a * If the resulting major_status code is GSS_S_COMPLETE, but a
non-zero-length reply token is returned, then that token is non-zero-length reply token is returned, then that token is
sent to the client. sent to the client.
4. S generates a random number y (0 < y < q) and computes f = g^y 4. S generates a random number y (0 < y < q) and computes f = g^y
skipping to change at page 6, line 20 skipping to change at page 6, line 25
|| K_S || e || f || K). It then calls GSS_VerifyMIC to verify || K_S || e || f || K). It then calls GSS_VerifyMIC to verify
that the MIC sent by S matches H. that the MIC sent by S matches H.
Either side MUST NOT send or accept e or f values that are not in Either side MUST NOT send or accept e or f values that are not in
the range [1, p-1]. If this condition is violated, the key exchange the range [1, p-1]. If this condition is violated, the key exchange
fails. fails.
If any call to GSS_Init_sec_context or GSS_Accept_sec_context If any call to GSS_Init_sec_context or GSS_Accept_sec_context
returns a major_status other than GSS_S_COMPLETE or returns a major_status other than GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED, or any other GSSAPI call returns a GSS_S_CONTINUE_NEEDED, or any other GSSAPI call returns a
major_status other than GSS_S_COMPLETE, the key exchange fails. major_status other than GSS_S_COMPLETE, the key exchange fails. If
the key exchange fails due to a GSSAPI error on the server, the
server SHOULD send a message informing the client of the details of
the error before terminating the connection as required by [11].
This is implemented with the following messages. The hash algorithm This is implemented with the following messages. The hash algorithm
for computing the exchange hash is defined by the method name, and for computing the exchange hash is defined by the method name, and
is called HASH. The group used for Diffie-Hellman key exchange and is called HASH. The group used for Diffie-Hellman key exchange and
the underlying GSSAPI mechanism are also defined by the method name. the underlying GSSAPI mechanism are also defined by the method name.
After the client's first call to GSS_Init_sec_context, it sends the After the client's first call to GSS_Init_sec_context, it sends the
following: following:
byte SSH_MSG_KEXGSS_INIT byte SSH_MSG_KEXGSS_INIT
skipping to change at page 7, line 4 skipping to change at page 7, line 11
used for any encryption operations, this message is OPTIONAL. If used for any encryption operations, this message is OPTIONAL. If
the "null" host key algorithm described in Section 5 is used, this the "null" host key algorithm described in Section 5 is used, this
message MUST NOT be sent. message MUST NOT be sent.
Each time the server's call to GSS_Accept_sec_context returns a Each time the server's call to GSS_Accept_sec_context returns a
major_status code of GSS_S_CONTINUE_NEEDED, it sends the following major_status code of GSS_S_CONTINUE_NEEDED, it sends the following
reply to the client: reply to the client:
byte SSH_MSG_KEXGSS_CONTINUE byte SSH_MSG_KEXGSS_CONTINUE
string output_token (from GSS_Accept_sec_context) string output_token (from GSS_Accept_sec_context)
If the client receives this message appears after a call to
If the client receives this message after a call to
GSS_Init_sec_context has returned a major_status code of GSS_Init_sec_context has returned a major_status code of
GSS_S_COMPLETE, a protocol error has occurred and the key exchange GSS_S_COMPLETE, a protocol error has occurred and the key exchange
MUST fail. MUST fail.
Each time the client receives the message described above, it makes Each time the client receives the message described above, it makes
another call to GSS_Init_sec_context. It then sends the following: another call to GSS_Init_sec_context. It then sends the following:
byte SSH_MSG_KEXGSS_CONTINUE byte SSH_MSG_KEXGSS_CONTINUE
string output_token (from GSS_Init_sec_context) string output_token (from GSS_Init_sec_context)
skipping to change at page 7, line 31 skipping to change at page 7, line 39
If the server's final call to GSS_Accept_sec_context (resulting in a If the server's final call to GSS_Accept_sec_context (resulting in a
major_status code of GSS_S_COMPLETE) returns a non-zero-length token major_status code of GSS_S_COMPLETE) returns a non-zero-length token
to be sent to the client, it sends the following: to be sent to the client, it sends the following:
byte SSH_MSG_KEXGSS_COMPLETE byte SSH_MSG_KEXGSS_COMPLETE
mpint f mpint f
string per_msg_token (MIC of H) string per_msg_token (MIC of H)
boolean TRUE boolean TRUE
string output_token (from GSS_Accept_sec_context) string output_token (from GSS_Accept_sec_context)
If the client receives this message appears after a call to If the client receives this message after a call to
GSS_Init_sec_context has returned a major_status code of GSS_Init_sec_context has returned a major_status code of
GSS_S_COMPLETE, a protocol error has occurred and the key exchange GSS_S_COMPLETE, a protocol error has occurred and the key exchange
MUST fail. MUST fail.
If the server's final call to GSS_Accept_sec_context (resulting in a If the server's final call to GSS_Accept_sec_context (resulting in a
major_status code of GSS_S_COMPLETE) returns a zero-length token or major_status code of GSS_S_COMPLETE) returns a zero-length token or
no token at all, it sends the following: no token at all, it sends the following:
byte SSH_MSG_KEXGSS_COMPLETE byte SSH_MSG_KEXGSS_COMPLETE
mpint f mpint f
string per_msg_token (MIC of H) string per_msg_token (MIC of H)
boolean FALSE boolean FALSE
If the client receives this message when no call to If the client receives this message when no call to
GSS_Init_sec_context has yet resulted in a major_status code of GSS_Init_sec_context has yet resulted in a major_status code of
GSS_S_COMPLETE, a protocol error has occurred and the key exchange GSS_S_COMPLETE, a protocol error has occurred and the key exchange
MUST fail. MUST fail.
In the event of a GSSAPI error on the server, the server may send
the following message before terminating the connection:
byte SSH_MSG_KEXGSS_ERROR
uint32 major_status
uint32 minor_status
string message
string language tag
The message text MUST be encoded in the UTF-8 encoding described in
[13]. Language tags are those described in [14]. Note that the
message text may contain multiple lines separated by carriage
return-line feed (CRLF) sequences. Application developers should
take this into account when displaying these messages.
The hash H is computed as the HASH hash of the concatenation of the The hash H is computed as the HASH hash of the concatenation of the
following: following:
string V_C, the client's version string (CR and NL excluded) string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key string K_S, the host key
mpint e, exchange value sent by the client mpint e, exchange value sent by the client
mpint f, exchange value sent by the server mpint f, exchange value sent by the server
skipping to change at page 11, line 27 skipping to change at page 12, line 27
it is possible that the client would fail to complete the it is possible that the client would fail to complete the
authentication method, but not be able to retry other methods authentication method, but not be able to retry other methods
because the server had already moved on. because the server had already moved on.
Therefore, the client MUST send the following message when it has Therefore, the client MUST send the following message when it has
successfully called GSS_Init_sec_context() and gotten GSS_S_COMPLETE: successfully called GSS_Init_sec_context() and gotten GSS_S_COMPLETE:
byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
This message MUST be sent if and only if GSS_Init_sec_context() This message MUST be sent if and only if GSS_Init_sec_context()
returned GSS_S_COMPLETE. returned GSS_S_COMPLETE. If a token is returned then the
SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
If GSS_Init_sec_context() failed, the client MUST terminate the If GSS_Init_sec_context() failed, the client MUST terminate the
method by sending a new SSH_MSG_USERAUTH_REQUEST. method by sending a new SSH_MSG_USERAUTH_REQUEST.
3.6 Completion 3.6 Completion
As with all SSH authentication methods, successful completion is As with all SSH authentication methods, successful completion is
indicated by a SSH_MSG_USERAUTH_SUCCESS if no other authentication indicated by a SSH_MSG_USERAUTH_SUCCESS if no other authentication
is required, or a SSH_MSG_USERAUTH_FAILURE with the partial success is required, or a SSH_MSG_USERAUTH_FAILURE with the partial success
flag set if the server requires further authentication. flag set if the server requires further authentication.
This packet should be sent immediately following receipt of the the This packet should be sent immediately following receipt of the the
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet. SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet.
3.7 Error Status
In the event a GSSAPI error occurs on the server during context
establishment, the server SHOULD send the following message to
inform the client of the details of the error before sending a
SSH_MSG_USERAUTH_FAILURE message:
byte SSH_MSG_USERAUTH_GSSAPI_ERROR
uint32 major_status
uint32 minor_status
string message
string language tag
The message text MUST be encoded in the UTF-8 encoding described in
[13]. Language tags are those described in [14]. Note that the
message text may contain multiple lines separated by carriage
return-line feed (CRLF) sequences. Application developers should
take this into account when displaying these messages.
Clients receiving this message MAY log the error details and/or
report them to the user. Any server sending this message MUST
ignore any SSH_MSG_UNIMPLEMENTED sent by the client in response.
4. External Key Exchange User Authentication 4. External Key Exchange User Authentication
This section describes a user authentication method building on the This section describes a user authentication method building on the
framework described in [12]. This method relies upon the key framework described in [12]. This method relies upon the key
exchange to authenticate both the client and the server. If the key exchange to authenticate both the client and the server. If the key
exchange did not successfully perform these functions then the exchange did not successfully perform these functions then the
server MUST always respond to this request with server MUST always respond to this request with
SSH_MSG_USERAUTH_FAILURE with partial success set to false. SSH_MSG_USERAUTH_FAILURE with partial success set to false.
The new mechanism is defined as follows: The new mechanism is defined as follows:
skipping to change at page 13, line 22 skipping to change at page 15, line 22
document are examples of such methods. document are examples of such methods.
This algorithm is used when, as a matter of configuration, the host This algorithm is used when, as a matter of configuration, the host
does not have or does not wish to use a public key. For example, it does not have or does not wish to use a public key. For example, it
can be used when the administrator has decided as a matter of policy can be used when the administrator has decided as a matter of policy
to require that all key exchanges be authenticated using Kerberos to require that all key exchanges be authenticated using Kerberos
[3], and thus the only permitted key exchange method is the [3], and thus the only permitted key exchange method is the
GSSAPI-authenticated Diffie-Hellman exchange described above, with GSSAPI-authenticated Diffie-Hellman exchange described above, with
Kerberos V5 as the underlying GSSAPI mechanism. In such a Kerberos V5 as the underlying GSSAPI mechanism. In such a
configuration, the server implementation supports the "ssh-dss" key configuration, the server implementation supports the "ssh-dss" key
algorithm (as required by [11], but could be prohibited by algorithm (as required by [11]), but could be prohibited by
configuration from using it. In this situation, the server needs configuration from using it. In this situation, the server needs
some key exchange algorithm to advertise; the "null" algorithm fills some key exchange algorithm to advertise; the "null" algorithm fills
this purpose. this purpose.
Note that the use of the "null" algorithm in this way means that the Note that the use of the "null" algorithm in this way means that the
server will not be able to interoperate with clients which do not server will not be able to interoperate with clients which do not
support this algorithm. This is not a significant problem, since in support this algorithm. This is not a significant problem, since in
the configuration described, it will also be unable to interoperate the configuration described, it will also be unable to interoperate
with implementations that do not support the GSSAPI-authenticated with implementations that do not support the GSSAPI-authenticated
key exchange and Kerberos. key exchange and Kerberos.
skipping to change at page 14, line 14 skipping to change at page 16, line 14
6. Summary of Message Numbers 6. Summary of Message Numbers
The following message numbers have been defined for use with The following message numbers have been defined for use with
GSSAPI-based key exchange methods: GSSAPI-based key exchange methods:
#define SSH_MSG_KEXGSS_INIT 30 #define SSH_MSG_KEXGSS_INIT 30
#define SSH_MSG_KEXGSS_CONTINUE 31 #define SSH_MSG_KEXGSS_CONTINUE 31
#define SSH_MSG_KEXGSS_COMPLETE 32 #define SSH_MSG_KEXGSS_COMPLETE 32
#define SSH_MSG_KEXGSS_HOSTKEY 33 #define SSH_MSG_KEXGSS_HOSTKEY 33
#define SSH_MSG_KEXGSS_ERROR 34
The numbers 30-49 are specific to key exchange and may be redefined The numbers 30-49 are specific to key exchange and may be redefined
by other kex methods. by other kex methods.
The following message numbers have been defined for use with the The following message numbers have been defined for use with the
'gssapi' user authentication method: 'gssapi' user authentication method:
#define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60 #define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60
#define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61 #define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61
#define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63 #define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63
#define SSH_MSG_USERAUTH_GSSAPI_ERROR 64
The numbers 60-79 are specific to user authentication and may be The numbers 60-79 are specific to user authentication and may be
redefined by other user auth methods. Note that in the method redefined by other user auth methods. Note that in the method
described in this document, message number 62 is unused. described in this document, message number 62 is unused.
7. GSSAPI Considerations 7. GSSAPI Considerations
7.1 Naming Conventions 7.1 Naming Conventions
In order to establish a GSSAPI security context, the SSH client In order to establish a GSSAPI security context, the SSH client
skipping to change at page 18, line 5 skipping to change at page 19, line 28
authentication and per-message integrity services. If either of authentication and per-message integrity services. If either of
these features is not supported by a particular GSSAPI mechanism, or these features is not supported by a particular GSSAPI mechanism, or
by a particular implementation of a GSSAPI mechanism, then the key by a particular implementation of a GSSAPI mechanism, then the key
exchange is not secure and MUST fail. exchange is not secure and MUST fail.
In order for the "external-keyx" user authentication method to be In order for the "external-keyx" user authentication method to be
used, it MUST have access to user authentication information used, it MUST have access to user authentication information
obtained as a side-effect of the key exchange. If this information obtained as a side-effect of the key exchange. If this information
is unavailable, the authentication MUST fail. is unavailable, the authentication MUST fail.
Revealing information about the reason for an authentication failure
may be considered by some sites to be an unacceptable security risk
for a production environment. However, having that information
available can be invaluable for debugging purposes. Thus, it is
RECOMMENDED that implementations provide a means for controlling, as
a matter of policy, whether the SSH_MSG_KEXGSS_ERROR and/or
SSH_MGS_USERAUTH_GGSAPI_ERROR messages are sent.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Sam Hartman and Simon Wilkinson for The authors would like to thank Sam Hartman and Simon Wilkinson for
their invaluable assistance with this document. their invaluable assistance with this document.
10. Changes the last version 10. Changes the last version
This section lists important changes since the previous version of This section lists important changes since the previous version of
this internet-draft. This section should be removed at the time of this internet-draft. This section should be removed at the time of
publication of this document as an RFC. publication of this document as an RFC.
o Merged user auth and key exchange into one document. o Added the SSH_MSG_KEXGSS_ERROR message to allow reporting of
GSSAPI errors during the key exchange process.
o Dropped host key verification from user auth.
o Changed the key exchange to use the SSH_MSG_KEXGSS_CONTINUE o Added the SSH_MSG_USERAUTH_GSSAPI_ERROR message to allow
message in both directions, and dropped the boolean from the reporting of GSSAPI errors during the user authentication process.
SSH_MSG_KEXGSS_INIT message.
o Added the SSH_MSG_KEXGSS_HOSTKEY message to allow the server to o Clarified the handling of
send its host key during key exchange, even though the key is not GSS_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE when the client has a
required to perform the exchange. final GSSAPI token to send.
o Modified the form of the exchange hash to include the host key, o Added references to RFC2279 (UTF-8) and RFC1176 (language tags).
if one was provided by the server. This allows the GSSAPI key
exchange method to be used to bootstrap a host key which can then
be used with other methods, in the same session or in future
sessions.
o Renamed all SSH_MSG_GSSAPI_* messages to SSH_MSG_KEXGSS_*. The o Added a missing paragraph specifying that a server accepting a
message numbers have not changed. GSSAPI context for key exchange must verify that message
integrity protection is available in that context.
References References
[1] ISO/IEC, "Specification of Abstract Syntax Notation One [1] ISO/IEC, "Specification of Abstract Syntax Notation One
(ASN.1)", ISO/IEC 8824, November 1998. (ASN.1)", ISO/IEC 8824, November 1998.
[2] Linn, J., "Generic Security Service Application Program [2] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[3] Kohl, J. and C. Neuman, "The Kerberos Network Authentication [3] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
skipping to change at page 20, line 33 skipping to change at page 22, line 33
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[7] Bradner, S., "Key words for use in RFCs to Indicate [7] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[8] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API [8] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998. Negotiation Mechanism", RFC 2478, December 1998.
[9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. [9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Protocol Architecture", January 2001. Lehtinen, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-11.txt (work in progress),
November 2001.
[10] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. [10] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Connection Protocol", January 2001. Lehtinen, "SSH Connection Protocol",
draft-ietf-secsh-connect-14.txt (work in progress), November
2001.
[11] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. [11] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Transport Layer Protocol", January 2001. Lehtinen, "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-11.txt (work in progress), November
2001.
[12] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. [12] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Authentication Protocol", January 2001. Lehtinen, "SSH Authentication Protocol",
draft-ietf-secsh-userauth-13.txt (work in progress), November
2001.
[13] Yergeau, , "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[14] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
Authors' Addresses Authors' Addresses
Jeffrey Hutzelman Jeffrey Hutzelman
Carnegie Mellon University Carnegie Mellon University
5000 Forbes Ave 5000 Forbes Ave
Pittsburgh, PA 15213 Pittsburgh, PA 15213
US US
Phone: +1 412 268 7225 Phone: +1 412 268 7225
skipping to change at page 22, line 7 skipping to change at page 24, line 7
University of Chicago & Argonne National Laboratory University of Chicago & Argonne National Laboratory
Distributed Systems Laboratory Distributed Systems Laboratory
701 E. Washington 701 E. Washington
Urbana, IL 61801 Urbana, IL 61801
US US
EMail: welch@mcs.anl.gov EMail: welch@mcs.anl.gov
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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