draft-ietf-secsh-userauth-06.txt   draft-ietf-secsh-userauth-07.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen INTERNET-DRAFT T. Kivinen
draft-ietf-secsh-userauth-06.txt M. Saarinen draft-ietf-secsh-userauth-07.txt M. Saarinen
Expires in six months T. Rinne Expires in six months T. Rinne
S. Lehtinen S. Lehtinen
SSH SSH Communications Security
22 June 1999 11 May 2000
SSH Authentication Protocol SSH Authentication Protocol
Status of This Memo Status of This memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with 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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 6, line 10 skipping to change at page 6, line 10
After successful authentication, such messages are passed to the higher- After successful authentication, such messages are passed to the higher-
level service. level service.
These are the general authentication message codes: These are the general authentication message codes:
#define SSH_MSG_USERAUTH_REQUEST 50 #define SSH_MSG_USERAUTH_REQUEST 50
#define SSH_MSG_USERAUTH_FAILURE 51 #define SSH_MSG_USERAUTH_FAILURE 51
#define SSH_MSG_USERAUTH_SUCCESS 52 #define SSH_MSG_USERAUTH_SUCCESS 52
#define SSH_MSG_USERAUTH_BANNER 53 #define SSH_MSG_USERAUTH_BANNER 53
In addition to the above, there is a range of message numbers (25..29) 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 reserved for method-specific messages. These messages are only sent by
the server (client only sends SSH_MSG_USERAUTH_REQUEST messages). the server (client only sends SSH_MSG_USERAUTH_REQUEST messages).
Different authentication methods reuse the same message numbers. Different authentication methods reuse the same message numbers.
4. Public Key Authentication Method: publickey 4. Public Key Authentication Method: publickey
The only REQUIRED authentication method is public key authentication. The only REQUIRED authentication method is public key authentication.
All implementations MUST support this method; however, not all users All implementations MUST support this method; however, not all users
need to have public keys, and most local policies are not likely to need to have public keys, and most local policies are not likely to
require public key authentication for all users in near future. require public key authentication for all users in near future.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
string service string service
string "publickey" string "publickey"
boolean TRUE boolean TRUE
string public key algorithm name string public key algorithm name
string public key to be used for authentication string public key to be used for authentication
string signature string signature
Signature is a signature by the corresponding private key over the Signature is a signature by the corresponding private key over the
following data, in this order: following data, in this order:
o session identifier, and o session identifier (encoded as string), and
o packet payload without the signature. o packet payload without the signature.
When the server receives this message, it MUST check whether the When the server receives this message, it MUST check whether the
supplied key is acceptable for authentication, and if so, it MUST check supplied key is acceptable for authentication, and if so, it MUST check
whether the signature is correct. whether the signature is correct.
If both checks succeed, this method is successful. Note that the server If both checks succeed, this method is successful. Note that the server
may require additional authentications. The server MUST respond with may require additional authentications. The server MUST respond with
SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or
skipping to change at page 10, line 46 skipping to change at page 10, line 46
allowed. allowed.
Special care should be taken when designing debug messages. These Special care should be taken when designing debug messages. These
messages may reveal surprising amounts of information about the host if messages may reveal surprising amounts of information about the host if
not properly designed. Debug messages can be disabled (during user not properly designed. Debug messages can be disabled (during user
authentication phase) if high security is sought after. authentication phase) if high security is sought after.
8. Trademark Issues 8. Trademark Issues
SSH is a registered trademark and Secure Shell is a trademark of SSH SSH is a registered trademark and Secure Shell is a trademark of SSH
Communications Security Ltd. SSH Communications Security Ltd permits Communications Security Corp. SSH Communications Security Corp permits
the use of these trademarks as the name of this standard and protocol, the use of these trademarks as the name of this standard and protocol,
and permits their use to describe that a product conforms to this and permits their use to describe that a product conforms to this
standard, provided that the following acknowledgement is included standard, provided that the following acknowledgement is included where
where the trademarks are used: ``SSH is a registered trademark and the trademarks are used: ``SSH is a registered trademark and Secure
Secure Shell is a trademark of SSH Communications Security Ltd Shell is a trademark of SSH Communications Security Corp
(www.ssh.fi)''. These trademarks may not be used as part of a product (www.ssh.com)''. These trademarks may not be used as part of a product
name or in otherwise confusing manner without prior written permission name or in otherwise confusing manner without prior written permission
of SSH Communications Security Ltd. of SSH Communications Security Corp.
9. References 9. References
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages",
March 1995. March 1995.
[RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and
ISO 10646", October 1996. ISO 10646", October 1996.
[SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet
Draft, draft-secsh-architecture-04.txt Draft, draft-secsh-architecture-05.txt
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet
Draft, draft-secsh-transport-06.txt Draft, draft-secsh-transport-07.txt
[SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet [SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet
Draft, draft-secsh-connect-06.txt Draft, draft-secsh-connect-07.txt
10. Author's Address 10. Author's Address
Tatu Ylonen Tatu Ylonen
SSH Communications Security Ltd. SSH Communications Security Corp
Tekniikantie 12 Fredrikinkatu 42
FIN-02150 ESPOO FIN-00100 HELSINKI
Finland Finland
E-mail: ylo@ssh.fi E-mail: ylo@ssh.com
Tero Kivinen Tero Kivinen
SSH Communications Security Ltd. SSH Communications Security Corp
Tekniikantie 12 Fredrikinkatu 42
FIN-02150 ESPOO FIN-00100 HELSINKI
Finland Finland
E-mail: kivinen@ssh.fi E-mail: kivinen@ssh.com
Markku-Juhani O. Saarinen Markku-Juhani O. Saarinen
SSH Communications Security Ltd. University of Jyvaskyla
Tekniikantie 12
FIN-02150 ESPOO
Finland
E-mail: mjos@ssh.fi
Timo J. Rinne Timo J. Rinne
SSH Communications Security Ltd. SSH Communications Security Corp
Tekniikantie 12 Fredrikinkatu 42
FIN-02150 ESPOO FIN-00100 HELSINKI
Finland Finland
E-mail: tri@ssh.fi E-mail: tri@ssh.com
Sami Lehtinen Sami Lehtinen
SSH Communications Security Ltd. SSH Communications Security Corp
Tekniikantie 12 Fredrikinkatu 42
FIN-02150 ESPOO FIN-00100 HELSINKI
Finland Finland
E-mail: sjl@ssh.fi E-mail: sjl@ssh.com
 End of changes. 

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