Ethereal-dev: [Ethereal-dev] SSH dissector - can anyone complete?
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: "Yaniv Kaul" <ykaul@xxxxxxxxxxxxxxxx>
Date: Wed, 16 Oct 2002 15:14:20 +0200
I've began writing a SSH dissector. Unfortunately, I seem not have enough time to complete it (at least not before Ethereal 1.0). As someone already in the past asked about it, I'll be happy if someone is willing to take it from here and finish it up. It dissects somewhat reasonably the first 2-3 SSH messages. I've also attached the drafts for the protocol... :-( Y.
Attachment:
packet-ssh.c
Description: Binary data
Network Working Group T. Ylonen
Internet-Draft T. Kivinen
Expires: March 21, 2003 SSH Communications Security Corp
M. Saarinen
University of Jyvaskyla
T. Rinne
S. Lehtinen
SSH Communications Security Corp
September 20, 2002
SSH Protocol Architecture
draft-ietf-secsh-architecture-13.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 21, 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
architecture of the SSH protocol, as well as the notation and
terminology used in SSH protocol documents. It also discusses the
SSH algorithm naming system that allows local extensions. The SSH
protocol consists of three major components: The Transport Layer
Ylonen, et. al. Expires March 21, 2003 [Page 1]
Internet-Draft SSH Protocol Architecture September 2002
Protocol provides server authentication, confidentiality, and
integrity with perfect forward secrecy. The User Authentication
Protocol authenticates the client to the server. The Connection
Protocol multiplexes the encrypted tunnel into several logical
channels. Details of these protocols are described in separate
documents.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Security Properties . . . . . . . . . . . . . . . . . . . . . 6
3.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . . 6
3.6 Localization and Character Set Support . . . . . . . . . . . . 7
4. Data Type Representations Used in the SSH Protocols . . . . . 8
5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . . 10
6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Intellectual Property . . . . . . . . . . . . . . . . . . . . 12
10. Additional Information . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
Ylonen, et. al. Expires March 21, 2003 [Page 2]
Internet-Draft SSH Protocol Architecture September 2002
1. Introduction
SSH is a protocol for secure remote login and other secure network
services over an insecure network. It consists of three major
components:
o The Transport Layer Protocol [SSH-TRANS] provides server
authentication, confidentiality, and integrity. It may optionally
also provide compression. The transport layer will typically be
run over a TCP/IP connection, but might also be used on top of any
other reliable data stream.
o The User Authentication Protocol [SSH-USERAUTH] authenticates the
client-side user to the server. It runs over the transport layer
protocol.
o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted
tunnel into several logical channels. It runs over the user
authentication protocol.
The client sends a service request once a secure transport layer
connection has been established. A second service request is sent
after user authentication is complete. This allows new protocols to
be defined and coexist with the protocols listed above.
The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up
secure interactive shell sessions and for forwarding ("tunneling")
arbitrary TCP/IP ports and X11 connections.
2. Specification of Requirements
All documents related to the SSH protocols shall use the keywords
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. They are to be interpreted as described in [RFC-2119].
3. Architecture
3.1 Host Keys
Each server host SHOULD have a host key. Hosts MAY have multiple
host keys using multiple different algorithms. Multiple hosts MAY
share the same host key. If a host has keys at all, it MUST have at
least one key using each REQUIRED public key algorithm (currently DSS
[FIPS-186]).
The server host key is used during key exchange to verify that the
client is really talking to the correct server. For this to be
possible, the client must have a priori knowledge of the server's
public host key.
Ylonen, et. al. Expires March 21, 2003 [Page 3]
Internet-Draft SSH Protocol Architecture September 2002
Two different trust models can be used:
o The client has a local database that associates each host name (as
typed by the user) with the corresponding public host key. This
method requires no centrally administered infrastructure, and no
third-party coordination. The downside is that the database of
name-to-key associations may become burdensome to maintain.
o The host name-to-key association is certified by some trusted
certification authority. The client only knows the CA root key,
and can verify the validity of all host keys certified by accepted
CAs.
The second alternative eases the maintenance problem, since
ideally only a single CA key needs to be securely stored on the
client. On the other hand, each host key must be appropriately
certified by a central authority before authorization is possible.
Also, a lot of trust is placed on the central infrastructure.
The protocol provides the option that the server name - host key
association is not checked when connecting to the host for the first
time. This allows communication without prior communication of host
keys or certification. The connection still provides protection
against passive listening; however, it becomes vulnerable to active
man-in-the-middle attacks. Implementations SHOULD NOT normally allow
such connections by default, as they pose a potential security
problem. However, as there is no widely deployed key infrastructure
available on the Internet yet, this option makes the protocol much
more usable during the transition time until such an infrastructure
emerges, while still providing a much higher level of security than
that offered by older solutions (e.g. telnet [RFC-854] and rlogin
[RFC-1282]).
Implementations SHOULD try to make the best effort to check host
keys. An example of a possible strategy is to only accept a host key
without checking the first time a host is connected, save the key in
a local database, and compare against that key on all future
connections to that host.
Implementations MAY provide additional methods for verifying the
correctness of host keys, e.g. a hexadecimal fingerprint derived
from the SHA-1 hash of the public key. Such fingerprints can easily
be verified by using telephone or other external communication
channels.
All implementations SHOULD provide an option to not accept host keys
that cannot be verified.
We believe that ease of use is critical to end-user acceptance of
security solutions, and no improvement in security is gained if the
Ylonen, et. al. Expires March 21, 2003 [Page 4]
Internet-Draft SSH Protocol Architecture September 2002
new solutions are not used. Thus, providing the option not to check
the server host key is believed to improve the overall security of
the Internet, even though it reduces the security of the protocol in
configurations where it is allowed.
3.2 Extensibility
We believe that the protocol will evolve over time, and some
organizations will want to use their own encryption, authentication
and/or key exchange methods. Central registration of all extensions
is cumbersome, especially for experimental or classified features.
On the other hand, having no central registration leads to conflicts
in method identifiers, making interoperability difficult.
We have chosen to identify algorithms, methods, formats, and
extension protocols with textual names that are of a specific format.
DNS names are used to create local namespaces where experimental or
classified extensions can be defined without fear of conflicts with
other implementations.
One design goal has been to keep the base protocol as simple as
possible, and to require as few algorithms as possible. However, all
implementations MUST support a minimal set of algorithms to ensure
interoperability (this does not imply that the local policy on all
hosts would necessary allow these algorithms). The mandatory
algorithms are specified in the relevant protocol documents.
Additional algorithms, methods, formats, and extension protocols can
be defined in separate drafts. See Section Algorithm Naming (Section
5) for more information.
3.3 Policy Issues
The protocol allows full negotiation of encryption, integrity, key
exchange, compression, and public key algorithms and formats.
Encryption, integrity, public key, and compression algorithms can be
different for each direction.
The following policy issues SHOULD be addressed in the configuration
mechanisms of each implementation:
o Encryption, integrity, and compression algorithms, separately for
each direction. The policy MUST specify which is the preferred
algorithm (e.g. the first algorithm listed in each category).
o Public key algorithms and key exchange method to be used for host
authentication. The existence of trusted host keys for different
public key algorithms also affects this choice.
o The authentication methods that are to be required by the server
for each user. The server's policy MAY require multiple
Ylonen, et. al. Expires March 21, 2003 [Page 5]
Internet-Draft SSH Protocol Architecture September 2002
authentication for some or all users. The required algorithms MAY
depend on the location where the user is trying to log in from.
o The operations that the user is allowed to perform using the
connection protocol. Some issues are related to security; for
example, the policy SHOULD NOT allow the server to start sessions
or run commands on the client machine, and MUST NOT allow
connections to the authentication agent unless forwarding such
connections has been requested. Other issues, such as which
TCP/IP ports can be forwarded and by whom, are clearly issues of
local policy. Many of these issues may involve traversing or
bypassing firewalls, and are interrelated with the local security
policy.
3.4 Security Properties
The primary goal of the SSH protocol is improved security on the
Internet. It attempts to do this in a way that is easy to deploy,
even at the cost of absolute security.
o All encryption, integrity, and public key algorithms used are
well-known, well-established algorithms.
o All algorithms are used with cryptographically sound key sizes
that are believed to provide protection against even the strongest
cryptanalytic attacks for decades.
o All algorithms are negotiated, and in case some algorithm is
broken, it is easy to switch to some other algorithm without
modifying the base protocol.
Specific concessions were made to make wide-spread fast deployment
easier. The particular case where this comes up is verifying that
the server host key really belongs to the desired host; the protocol
allows the verification to be left out (but this is NOT RECOMMENDED).
This is believed to significantly improve usability in the short
term, until widespread Internet public key infrastructures emerge.
3.5 Packet Size and Overhead
Some readers will worry about the increase in packet size due to new
headers, padding, and MAC. The minimum packet size is in the order
of 28 bytes (depending on negotiated algorithms). The increase is
negligible for large packets, but very significant for one-byte
packets (telnet-type sessions). There are, however, several factors
that make this a non-issue in almost all cases:
o The minimum size of a TCP/IP header is 32 bytes. Thus, the
increase is actually from 33 to 51 bytes (roughly).
o The minimum size of the data field of an Ethernet packet is 46
bytes [RFC-894]. Thus, the increase is no more than 5 bytes.
When Ethernet headers are considered, the increase is less than 10
percent.
Ylonen, et. al. Expires March 21, 2003 [Page 6]
Internet-Draft SSH Protocol Architecture September 2002
o The total fraction of telnet-type data in the Internet is
negligible, even with increased packet sizes.
The only environment where the packet size increase is likely to have
a significant effect is PPP [RFC-1134] over slow modem lines (PPP
compresses the TCP/IP headers, emphasizing the increase in packet
size). However, with modern modems, the time needed to transfer is
in the order of 2 milliseconds, which is a lot faster than people can
type.
There are also issues related to the maximum packet size. To
minimize delays in screen updates, one does not want excessively
large packets for interactive sessions. The maximum packet size is
negotiated separately for each channel.
3.6 Localization and Character Set Support
For the most part, the SSH protocols do not directly pass text that
would be displayed to the user. However, there are some places where
such data might be passed. When applicable, the character set for
the data MUST be explicitly specified. In most places, ISO 10646
with UTF-8 encoding is used [RFC-2279]. When applicable, a field is
also provided for a language tag [RFC-1766].
One big issue is the character set of the interactive session. There
is no clear solution, as different applications may display data in
different formats. Different types of terminal emulation may also be
employed in the client, and the character set to be used is
effectively determined by the terminal emulation. Thus, no place is
provided for directly specifying the character set or encoding for
terminal session data. However, the terminal emulation type (e.g.
"vt100") is transmitted to the remote site, and it implicitly
specifies the character set and encoding. Applications typically use
the terminal type to determine what character set they use, or the
character set is determined using some external means. The terminal
emulation may also allow configuring the default character set. In
any case, the character set for the terminal session is considered
primarily a client local issue.
Internal names used to identify algorithms or protocols are normally
never displayed to users, and must be in US-ASCII.
The client and server user names are inherently constrained by what
the server is prepared to accept. They might, however, occasionally
be displayed in logs, reports, etc. They MUST be encoded using ISO
10646 UTF-8, but other encodings may be required in some cases. It
is up to the server to decide how to map user names to accepted user
names. Straight bit-wise binary comparison is RECOMMENDED.
Ylonen, et. al. Expires March 21, 2003 [Page 7]
Internet-Draft SSH Protocol Architecture September 2002
For localization purposes, the protocol attempts to minimize the
number of textual messages transmitted. When present, such messages
typically relate to errors, debugging information, or some externally
configured data. For data that is normally displayed, it SHOULD be
possible to fetch a localized message instead of the transmitted
message by using a numerical code. The remaining messages SHOULD be
configurable.
4. Data Type Representations Used in the SSH Protocols
byte
A byte represents an arbitrary 8-bit value (octet) [RFC-1700].
Fixed length data is sometimes represented as an array of bytes,
written byte[n], where n is the number of bytes in the array.
boolean
A boolean value is stored as a single byte. The value 0
represents FALSE, and the value 1 represents TRUE. All non-zero
values MUST be interpreted as TRUE; however, applications MUST NOT
store values other than 0 and 1.
uint32
Represents a 32-bit unsigned integer. Stored as four bytes in the
order of decreasing significance (network byte order). For
example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4
aa.
uint64
Represents a 64-bit unsigned integer. Stored as eight bytes in
the order of decreasing significance (network byte order).
string
Arbitrary length binary string. Strings are allowed to contain
arbitrary binary data, including null characters and 8-bit
characters. They are stored as a uint32 containing its length
(number of bytes that follow) and zero (= empty string) or more
bytes that are the value of the string. Terminating null
characters are not used.
Strings are also used to store text. In that case, US-ASCII is
used for internal names, and ISO-10646 UTF-8 for text that might
be displayed to the user. The terminating null character SHOULD
NOT normally be stored in the string.
Ylonen, et. al. Expires March 21, 2003 [Page 8]
Internet-Draft SSH Protocol Architecture September 2002
For example, the US-ASCII string "testing" is represented as 00 00
00 07 t e s t i n g. The UTF8 mapping does not alter the encoding
of US-ASCII characters.
mpint
Represents multiple precision integers in two's complement format,
stored as a string, 8 bits per byte, MSB first. Negative numbers
have the value 1 as the most significant bit of the first byte of
the data partition. If the most significant bit would be set for
a positive number, the number MUST be preceded by a zero byte.
Unnecessary leading bytes with the value 0 or 255 MUST NOT be
included. The value zero MUST be stored as a string with zero
bytes of data.
By convention, a number that is used in modular computations in
Z_n SHOULD be represented in the range 0 <= x < n.
Examples:
value (hex) representation (hex)
---------------------------------------------------------------
0 00 00 00 00
9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
80 00 00 00 02 00 80
-1234 00 00 00 02 ed cc
-deadbeef 00 00 00 05 ff 21 52 41 11
name-list
A string containing a comma separated list of names. A name list
is represented as a uint32 containing its length (number of bytes
that follow) followed by a comma-separated list of zero or more
names. A name MUST be non-zero length, and it MUST NOT contain a
comma (','). Context may impose additional restrictions on the
names; for example, the names in a list may have to be valid
algorithm identifier (see Algorithm Naming below), or [RFC-1766]
language tags. The order of the names in a list may or may not be
significant, also depending on the context where the list is is
used. Terminating NUL characters are not used, neither for the
individual names, nor for the list as a whole.
Examples:
value representation (hex)
---------------------------------------
(), the empty list 00 00 00 00
("zlib") 00 00 00 04 7a 6c 69 62
Ylonen, et. al. Expires March 21, 2003 [Page 9]
Internet-Draft SSH Protocol Architecture September 2002
("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
5. Algorithm Naming
The SSH protocols refer to particular hash, encryption, integrity,
compression, and key exchange algorithms or protocols by names.
There are some standard algorithms that all implementations MUST
support. There are also algorithms that are defined in the protocol
specification but are OPTIONAL. Furthermore, it is expected that
some organizations will want to use their own algorithms.
In this protocol, all algorithm identifiers MUST be printable US-
ASCII non-empty strings no longer than 64 characters. Names MUST be
case-sensitive.
There are two formats for algorithm names:
o Names that do not contain an at-sign (@) are reserved to be
assigned by IETF consensus (RFCs). Examples include `3des-cbc',
`sha-1', `hmac-sha1', and `zlib' (the quotes are not part of the
name). Names of this format MUST NOT be used without first
registering them. Registered names MUST NOT contain an at-sign
(@) or a comma (,).
o Anyone can define additional algorithms by using names in the
format name@domainname, e.g. "ourcipher-cbc@xxxxxxx". The format
of the part preceding the at sign is not specified; it MUST
consist of US-ASCII characters except at-sign and comma. The part
following the at-sign MUST be a valid fully qualified internet
domain name [RFC-1034] controlled by the person or organization
defining the name. It is up to each domain how it manages its
local namespace.
6. Message Numbers
SSH packets have message numbers in the range 1 to 255. These
numbers have been allocated as follows:
Transport layer protocol:
1 to 19 Transport layer generic (e.g. disconnect, ignore, debug,
etc.)
20 to 29 Algorithm negotiation
30 to 49 Key exchange method specific (numbers can be reused for
different authentication methods)
Ylonen, et. al. Expires March 21, 2003 [Page 10]
Internet-Draft SSH Protocol Architecture September 2002
User authentication protocol:
50 to 59 User authentication generic
60 to 79 User authentication method specific (numbers can be
reused for different authentication methods)
Connection protocol:
80 to 89 Connection protocol generic
90 to 127 Channel related messages
Reserved for client protocols:
128 to 191 Reserved
Local extensions:
192 to 255 Local extensions
7. IANA Considerations
Allocation of the following types of names in the SSH protocols is
assigned by IETF consensus:
o encryption algorithm names,
o MAC algorithm names,
o public key algorithm names (public key algorithm also implies
encoding and signature/encryption capability),
o key exchange method names, and
o protocol (service) names.
These names MUST be printable US-ASCII strings, and MUST NOT contain
the characters at-sign ('@'), comma (','), or whitespace or control
characters (ASCII codes 32 or less). Names are case-sensitive, and
MUST NOT be longer than 64 characters.
Names with the at-sign ('@') in them are allocated by the owner of
DNS name after the at-sign (hierarchical allocation in [RFC-2343]),
otherwise the same restrictions as above.
Each category of names listed above has a separate namespace.
However, using the same name in multiple categories SHOULD be avoided
to minimize confusion.
Message numbers (see Section Message Numbers (Section 6)) in the
range of 0..191 should be allocated via IETF consensus; message
numbers in the 192..255 range (the "Local extensions" set) are
Ylonen, et. al. Expires March 21, 2003 [Page 11]
Internet-Draft SSH Protocol Architecture September 2002
reserved for private use.
8. Security Considerations
Special care should be taken to ensure that all of the random numbers
are of good quality. The random numbers SHOULD be produced with safe
mechanisms discussed in [RFC-1750].
When displaying text, such as error or debug messages to the user,
the client software SHOULD replace any control characters (except
tab, carriage return and newline) with safe sequences to avoid
attacks by sending terminal control characters.
Not using MAC or encryption SHOULD be avoided. The user
authentication protocol is subject to man-in-the-middle attacks if
the encryption is disabled. The SSH protocol does not protect
against message alteration if no MAC is used.
9. Intellectual Property
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 implementers or users of this specification can
be obtained from the IETF Secretariat.
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.
10. Additional Information
The current document editor is: Darren.Moffat@xxxxxxx. Comments on
this internet draft should be sent to the IETF SECSH working group,
details at: http://ietf.org/html.charters/secsh-charter.html
References
[FIPS-186] Federal Information Processing Standards Publication,
Ylonen, et. al. Expires March 21, 2003 [Page 12]
Internet-Draft SSH Protocol Architecture September 2002
., "FIPS PUB 186, Digital Signature Standard", May
1994.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC0894] Hornig, C., "Standard for the transmission of IP
datagrams over Ethernet networks", STD 41, RFC 894,
Apr 1984.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, Nov 1987.
[RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for
multi-protocol transmission of datagrams over Point-
to-Point links", RFC 1134, Nov 1989.
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD
2, RFC 1700, October 1994.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-
ietf-architecture-13.txt, September 2002.
[SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-15.txt, September 2002.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-
ietf-userauth-16.txt, September 2002.
Ylonen, et. al. Expires March 21, 2003 [Page 13]
Internet-Draft SSH Protocol Architecture September 2002
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-
ietf-connect-16.txt, September 2002.
Authors' Addresses
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: ylo@xxxxxxx
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: kivinen@xxxxxxx
Markku-Juhani O. Saarinen
University of Jyvaskyla
Timo J. Rinne
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: tri@xxxxxxx
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: sjl@xxxxxxx
Ylonen, et. al. Expires March 21, 2003 [Page 14]
Internet-Draft SSH Protocol Architecture September 2002
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 assigns.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ylonen, et. al. Expires March 21, 2003 [Page 15]
Network Working Group S. Lehtinen
Internet-Draft SSH Communications Security Corp
Expires: March 31, 2003 D. Moffat
Sun Microsystems
September 30, 2002
SSH Protocol Assigned Numbers
draft-ietf-secsh-assignednumbers-01.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 31, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines the initial state of the IANA assigned numbers
for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-
CONNECT], [SSH-USERAUTH]. This document does not define any new
protocols or any number ranges not already defined in the above
referenced documents. It is intended only for initalization of the
IANA databases referenced in those documents.
Lehtinen & Moffat Expires March 31, 2003 [Page 1]
Internet-Draft SSH Protocol Assigned Numbers September 2002
Table of Contents
1. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Disconnect Codes . . . . . . . . . . . . . . . . . . . . . . 4
2. Service Names . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Authentication Method Names . . . . . . . . . . . . . . . . 5
2.2 Connection Protocol Assigned Names . . . . . . . . . . . . . 6
2.2.1 Connection Protocol Channel Types . . . . . . . . . . . . . 6
2.2.2 Connection Protocol Global Request Names . . . . . . . . . . 6
2.2.3 Connection Protocol Channel Request Names . . . . . . . . . 6
3. Key Exchange Method Names . . . . . . . . . . . . . . . . . 7
4. Assigned Algorithm Names . . . . . . . . . . . . . . . . . . 7
4.1 Encryption Algorithm Names . . . . . . . . . . . . . . . . . 7
4.2 MAC Algorithm Names . . . . . . . . . . . . . . . . . . . . 8
4.3 Public Key Algorithm Names . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
Lehtinen & Moffat Expires March 31, 2003 [Page 2]
Internet-Draft SSH Protocol Assigned Numbers September 2002
1. Message Numbers
The Message Number is an 8-bit value, which describes the payload of
a packet.
Protocol packets have message numbers in the range 1 to 255. These
numbers have been allocated as follows in [SSH-ARCH]:
Transport layer protocol:
1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, etc.)
20 to 29 Algorithm negotiation
30 to 49 Key exchange method specific (numbers can be reused for
different authentication methods)
User authentication protocol:
50 to 59 User authentication generic
60 to 79 User authentication method specific (numbers can be
reused for different authentication methods)
Connection protocol:
80 to 89 Connection protocol generic
90 to 127 Channel related messages
Reserved for client protocols:
128 to 191 Reserved
Local extensions:
192 to 255 Local extensions
Requests for assignments of new message numbers must be accompanied
by an RFC which describes the new packet type. If the RFC is not on
the standards-track (i.e. it is an informational or experimental
RFC), it must be explicitly reviewed and approved by the IESG before
the RFC is published and the message number is assigned.
Message ID Value Reference
----------- ----- ---------
SSH_MSG_DISCONNECT 1 [SSH-TRANS]
SSH_MSG_IGNORE 2 [SSH-TRANS]
SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS]
SSH_MSG_DEBUG 4 [SSH-TRANS]
SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS]
Lehtinen & Moffat Expires March 31, 2003 [Page 3]
Internet-Draft SSH Protocol Assigned Numbers September 2002
SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS]
SSH_MSG_KEXINIT 20 [SSH-TRANS]
SSH_MSG_NEWKEYS 21 [SSH-TRANS]
SSH_MSG_KEXDH_INIT 30 [SSH-TRANS]
SSH_MSG_KEXDH_REPLY 31 [SSH-TRANS]
SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH]
SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH]
SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH]
SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH]
SSH_MSG_USERAUTH_PK_OK 60 [SSH-USERAUTH]
SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT]
SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT]
SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT]
SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT]
SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT]
SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT]
SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT]
SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT]
SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT]
SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT]
SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT]
1.1 Disconnect Codes
The Disconnect code is an 8-bit value, which describes the disconnect
reason. Requests for assignments of new disconnect codes must be
accompanied by an RFC which describes the new disconnect reason code.
Disconnect code Value Reference
---------------- ----- ---------
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 [SSH-TRANS]
SSH_DISCONNECT_PROTOCOL_ERROR 2 [SSH-TRANS]
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 [SSH-TRANS]
SSH_DISCONNECT_RESERVED 4 [SSH-TRANS]
SSH_DISCONNECT_MAC_ERROR 5 [SSH-TRANS]
SSH_DISCONNECT_COMPRESSION_ERROR 6 [SSH-TRANS]
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 [SSH-TRANS]
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 [SSH-TRANS]
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 [SSH-TRANS]
SSH_DISCONNECT_CONNECTION_LOST 10 [SSH-TRANS]
SSH_DISCONNECT_BY_APPLICATION 11 [SSH-TRANS]
SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 [SSH-TRANS]
SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 [SSH-TRANS]
Lehtinen & Moffat Expires March 31, 2003 [Page 4]
Internet-Draft SSH Protocol Assigned Numbers September 2002
SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 [SSH-TRANS]
SSH_DISCONNECT_ILLEGAL_USER_NAME 15 [SSH-TRANS]
2. Service Names
The Service Name is used to describe a protocol layer. These names
MUST be printable US-ASCII strings, and MUST NOT contain the
characters at-sign ('@'), comma (','), or whitespace or control
characters (ASCII codes 32 or less). Names are case-sensitive, and
MUST NOT be longer than 64 characters.
Requests for assignments of new service names must be accompanied by
an RFC which describes the interpretation for the service name. If
the RFC is not on the standards-track (i.e. it is an informational
or experimental RFC), it must be explicitly reviewed and approved by
the IESG before the RFC is published and the service name is
assigned.
Service name Reference
------------- ---------
ssh-userauth [SSH-USERAUTH]
ssh-connection [SSH-CONNECT]
2.1 Authentication Method Names
The Authentication Method Name is used to describe an authentication
method for the "ssh-userauth" service [SSH-USERAUTH]. These names
MUST be printable US-ASCII strings, and MUST NOT contain the
characters at-sign ('@'), comma (','), or whitespace or control
characters (ASCII codes 32 or less). Names are case-sensitive, and
MUST NOT be longer than 64 characters.
Requests for assignments of new authentication method names must be
accompanied by an RFC which describes the interpretation for the
authentication method.
Method name Reference
------------ ---------
publickey [SSH-USERAUTH, Section 4]
password [SSH-USERAUTH, Section 5]
hostbased [SSH-USERAUTH, Section 6]
none [SSH-USERAUTH, Section 2.3]
Lehtinen & Moffat Expires March 31, 2003 [Page 5]
Internet-Draft SSH Protocol Assigned Numbers September 2002
2.2 Connection Protocol Assigned Names
The following request and type names MUST be printable US-ASCII
strings, and MUST NOT contain the characters at-sign ('@'), comma
(','), or whitespace or control characters (ASCII codes 32 or less).
Names are case-sensitive, and MUST NOT be longer than 64 characters.
Requests for assignments of new assigned names must be accompanied by
an RFC which describes the interpretation for the type or request.
2.2.1 Connection Protocol Channel Types
Channel type Reference
------------ ---------
session [SSH-CONNECT, Section 4.1]
x11 [SSH-CONNECT, Section 4.3.2]
forwarded-tcpip [SSH-CONNECT, Section 5.2]
direct-tcpip [SSH-CONNECT, Section 5.2]
2.2.2 Connection Protocol Global Request Names
Request type Reference
------------ ---------
tcpip-forward [SSH-CONNECT, Section 5.1]
cancel-tcpip-forward [SSH-CONNECT, Section 5.1]
2.2.3 Connection Protocol Channel Request Names
Request type Reference
------------ ---------
pty-req [SSH-CONNECT, Section 4.2]
x11-req [SSH-CONNECT, Section 4.3.1]
env [SSH-CONNECT, Section 4.4]
shell [SSH-CONNECT, Section 4.5]
exec [SSH-CONNECT, Section 4.5]
subsystem [SSH-CONNECT, Section 4.5]
window-change [SSH-CONNECT, Section 4.7]
xon-xoff [SSH-CONNECT, Section 4.8]
signal [SSH-CONNECT, Section 4.9]
exit-status [SSH-CONNECT, Section 4.10]
exit-signal [SSH-CONNECT, Section 4.10]
Lehtinen & Moffat Expires March 31, 2003 [Page 6]
Internet-Draft SSH Protocol Assigned Numbers September 2002
3. Key Exchange Method Names
The Key Exchange Method Name describes a key-exchange method for the
protocol [SSH-TRANS]. The names MUST be printable US-ASCII strings,
and MUST NOT contain the characters at-sign ('@'), comma (','), or
whitespace or control characters (ASCII codes 32 or less). Names are
case-sensitive, and MUST NOT be longer than 64 characters.
Requests for assignment of new key-exchange method names must be
accompanied by a reference to a standards-track or Informational RFC
which describes this method.
Method name Reference
------------ ---------
diffie-hellman-group1-sha1 [SSH-TRANS, Section 4.5]
4. Assigned Algorithm Names
The following identifiers (names) MUST be printable US-ASCII strings,
and MUST NOT contain the characters at-sign ('@'), comma (','), or
whitespace or control characters (ASCII codes 32 or less). Names are
case-sensitive, and MUST NOT be longer than 64 characters.
Requests for assignment of new algorithm names must be accompanied by
a reference to a standards-track or Informational RFC or a reference
to published cryptographic literature which describes the algorithm.
4.1 Encryption Algorithm Names
Cipher name Reference
------------ ---------
3des-cbc [SSH-TRANS, Section 4.3]
blowfish-cbc [SSH-TRANS, Section 4.3]
twofish256-cbc [SSH-TRANS, Section 4.3]
twofish-cbc [SSH-TRANS, Section 4.3]
twofish192-cbc [SSH-TRANS, Section 4.3]
twofish128-cbc [SSH-TRANS, Section 4.3]
aes256-cbc [SSH-TRANS, Section 4.3]
aes192-cbc [SSH-TRANS, Section 4.3]
aes128-cbc [SSH-TRANS, Section 4.3]
serpent256-cbc [SSH-TRANS, Section 4.3]
serpent192-cbc [SSH-TRANS, Section 4.3]
serpent128-cbc [SSH-TRANS, Section 4.3]
arcfour [SSH-TRANS, Section 4.3]
idea-cbc [SSH-TRANS, Section 4.3]
cast128-cbc [SSH-TRANS, Section 4.3]
none [SSH-TRANS, Section 4.3]
Lehtinen & Moffat Expires March 31, 2003 [Page 7]
Internet-Draft SSH Protocol Assigned Numbers September 2002
des-cbc [FIPS-46-3] HISTORIC; See page 4 of [FIPS 46-3]
4.2 MAC Algorithm Names
MAC name Reference
--------- ---------
hmac-sha1 [SSH-TRANS, Section 4.4]
hmac-sha1-96 [SSH-TRANS, Section 4.4]
hmac-md5 [SSH-TRANS, Section 4.4]
hmac-md5-96 [SSH-TRANS, Section 4.4]
none [SSH-TRANS, Section 4.4]
4.3 Public Key Algorithm Names
Algorithm name Reference
--------------- ---------
ssh-dss [SSH-TRANS, Section 4.6]
ssh-rsa [SSH-TRANS, Section 4.6]
x509v3-sign-rsa [SSH-TRANS, Section 4.6]
x509v3-sign-dss [SSH-TRANS, Section 4.6]
spki-sign-rsa [SSH-TRANS, Section 4.6]
spki-sign-dss [SSH-TRANS, Section 4.6]
pgp-sign-rsa [SSH-TRANS, Section 4.6]
pgp-sign-dss [SSH-TRANS, Section 4.6]
References
[SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-
ietf-architecture-13.txt, September 2002.
[SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-15.txt, September 2002.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-
ietf-userauth-16.txt, September 2002.
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-
ietf-connect-16.txt, September 2002.
[FIPS-46-3] U.S. Dept. of Commerce, ., "FIPS PUB 46-3, Data
Encryption Standard (DES)", October 1999.
Lehtinen & Moffat Expires March 31, 2003 [Page 8]
Internet-Draft SSH Protocol Assigned Numbers September 2002
Authors' Addresses
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: sjl@xxxxxxx
Darren J Moffat
Sun Microsystems
901 San Antonio Road
Palo Alto 94303
USA
EMail: Darren.Moffat@xxxxxxx
Lehtinen & Moffat Expires March 31, 2003 [Page 9]
Internet-Draft SSH Protocol Assigned Numbers September 2002
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 assigns.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lehtinen & Moffat Expires March 31, 2003 [Page 10]
Network Working Group J. Hutzelman
Internet-Draft CMU
Expires: January 3, 2003 J. Salowey
Cisco Systems
J. Galbraith
Van Dyke Technologies, Inc.
V. Welch
U Chicago / ANL
July 5, 2002
GSSAPI Authentication and Key Exchange for the Secure Shell Protocol
draft-ietf-secsh-gsskeyex-04
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 January 3, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The Secure Shell protocol (SSH) is a protocol for secure remote
login and other secure network services over an insecure network.
The Generic Security Service Application Program Interface (GSS-API)
[2] provides security services to callers in a mechanism-independent
fashion.
Hutzelman, et. al. Expires January 3, 2003 [Page 1]
Internet-Draft SSH GSSAPI Methods July 2002
This memo describes methods for using the GSS-API for authentication
and key exchange in SSH. It defines an SSH user authentication
method which uses a specified GSSAPI mechanism to authenticate a
user, and a family of SSH key exchange methods which use GSSAPI to
authenticate the Diffie-Hellman exchange described in [11].
This memo also defines a new host public key algorithm which can be
used when no operations are needed using a host's public key, and a
new user authentication method which allows an authorization name to
be used in conjunction with any authentication which has already
occurred as a side-effect of key exchange.
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 [7].
Hutzelman, et. al. Expires January 3, 2003 [Page 2]
Internet-Draft SSH GSSAPI Methods July 2002
1. Introduction
This document describes the methods used to perform key exchange and
user authentication in the Secure Shell protocol using the GSSAPI.
To do this, it defines a family of key exchange methods, two user
authentication methods, and a new host key algorithm. These
definitions allow any GSSAPI mechanism to be used with the Secure
Shell protocol.
This document should be read only after reading the documents
describing the SSH protocol architecture [9], transport layer
protocol [11], and user authentication protocol [12]. This document
freely uses terminology and notation from the architecture document
without reference or further explanation.
1.1 SSH terminology
The data types used in the packets are defined in the SSH
architecture document [9]. It is particularly important to note the
definition of string allows binary content.
The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this
service name is an SSH service name, and has no relationship to
GSSAPI service names. Currently, the only defined service name is
"ssh-connection", which refers to the SSH connection protocol [10].
Hutzelman, et. al. Expires January 3, 2003 [Page 3]
Internet-Draft SSH GSSAPI Methods July 2002
2. GSSAPI Authenticated Diffie-Hellman Key Exchange
This section defines a class of key exchange methods which combine
the Diffie-Hellman key exchange from section 6 of [11] with mutual
authentication using GSSAPI.
Since the GSSAPI key exchange methods described in this section do
not require the use of public key signature or encryption
algorithms, they MAY be used with any host key algorithm, including
the "null" algorithm described in Section 5.
2.1 Generic GSSAPI Key Exchange
The following symbols are used in this description:
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
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 I_C is C's KEXINIT message, and I_S is S's KEXINIT message
1. C generates a random number x (1 < x < q) and computes e = g^x
mod p.
2. C calls GSS_Init_sec_context, using the most recent reply token
received from S during this exchange, if any. For this call,
the client MUST set the mutual_req_flag to "true" to request
that mutual authentication be performed. It also MUST set the
integ_req_flag to "true" to request that per-message integrity
protection be supported for this context. In addition, the
deleg_req_flag MAY be set to "true" to request access
delegation, if requested by the user. Since the key exchange
process authenticates only the host, the setting of the
anon_req_flag is immaterial to this process. If the client does
not support the "external-keyx" user authentication method
described in Section 4, or does not intend to use that method,
then the anon_req_flag SHOULD be set to "true". Otherwise, this
flag MAY be set to true if the client wishes to hide its
identity.
* If the resulting major_status code is GSS_S_COMPLETE and the
mutual_state flag is not true, then mutual authentication has
not been established, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and the
integ_avail flag is not true, then per-message integrity
Hutzelman, et. al. Expires January 3, 2003 [Page 4]
Internet-Draft SSH GSSAPI Methods July 2002
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, the
resulting output token is sent to S.
* If the resulting major_status code is GSS_S_CONTINUE_NEEDED,
the the output_token is sent to S, which will reply with a
new token to be provided to GSS_Init_sec_context.
* The client MUST also include "e" with the first message it
sends to the server during this process; if the server
receives more than one "e" or none at all, the key exchange
fails.
* It is an error if the call does not produce a token of
non-zero length to be sent to the server. In this case, the
key exchange MUST fail.
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
mutual_state flag is not true, then mutual authentication has
not been established, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and the
integ_avail flag is not true, then per-message integrity
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,
then the output token is sent to C, and processing continues
with step 2.
* If the resulting major_status code is GSS_S_COMPLETE, but a
non-zero-length reply token is returned, then that token is
sent to the client.
4. S generates a random number y (0 < y < q) and computes f = g^y
mod p. It computes K = e ^ y mod p, and H = hash(V_C || V_S ||
I_C || I_S || K_S || e || f || K). It then calls GSS_GetMIC to
obtain a GSSAPI message integrity code for H. S then sends f
and the MIC to C.
5. This step is performed only if the server's final call to
Hutzelman, et. al. Expires January 3, 2003 [Page 5]
Internet-Draft SSH GSSAPI Methods July 2002
GSS_Accept_sec_context produced a non-zero-length final reply
token to be sent to the client _and_ no previous call by the
client to GSS_Init_sec_context has resulted in a major_status of
GSS_S_COMPLETE. Under these conditions, the client makes an
additional call to GSS_Init_sec_context to process the final
reply token. This call is made exactly as described above.
However, if the resulting major_status is anything other than
GSS_S_COMPLETE, or a non-zero-length token is returned, it is an
error and the key exchange MUST fail.
6. C computes K = f^x mod p, and H = hash(V_C || V_S || I_C || I_S
|| K_S || e || f || K). It then calls GSS_VerifyMIC to verify
that the MIC sent by S matches H.
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
fails.
If any call to GSS_Init_sec_context or GSS_Accept_sec_context
returns a major_status other than GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED, or any other GSSAPI call returns a
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
for computing the exchange hash is defined by the method name, and
is called HASH. The group used for Diffie-Hellman key exchange and
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
following:
byte SSH_MSG_KEXGSS_INIT
string output_token (from GSS_Init_sec_context)
mpint e
Upon receiving the SSH_MSG_KEXGSS_INIT message, the server MAY send
the following message, prior to any other messages, to inform the
client of its host key.
byte SSH_MSG_KEXGSS_HOSTKEY
string server public host key and certificates (K_S)
Since this key exchange method does not require the host key to be
used for any encryption operations, this message is OPTIONAL. If
the "null" host key algorithm described in Section 5 is used, this
message MUST NOT be sent. If this message is sent, the server
Hutzelman, et. al. Expires January 3, 2003 [Page 6]
Internet-Draft SSH GSSAPI Methods July 2002
public host key(s) and/or certificate(s) in this message are encoded
as a single string, in the format specified by the public key type
in use (see [11], section 4.6).
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
reply to the client:
byte SSH_MSG_KEXGSS_CONTINUE
string output_token (from GSS_Accept_sec_context)
If the client receives this message after a call to
GSS_Init_sec_context has returned a major_status code of
GSS_S_COMPLETE, a protocol error has occurred and the key exchange
MUST fail.
Each time the client receives the message described above, it makes
another call to GSS_Init_sec_context. It then sends the following:
byte SSH_MSG_KEXGSS_CONTINUE
string output_token (from GSS_Init_sec_context)
The server and client continue to trade these two messages as long
as the server's calls to GSS_Accept_sec_context result in
major_status codes of GSS_S_CONTINUE_NEEDED. When a call results in
a major_status code of GSS_S_COMPLETE, it sends one of two final
messages.
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
to be sent to the client, it sends the following:
byte SSH_MSG_KEXGSS_COMPLETE
mpint f
string per_msg_token (MIC of H)
boolean TRUE
string output_token (from GSS_Accept_sec_context)
If the client receives this message after a call to
GSS_Init_sec_context has returned a major_status code of
GSS_S_COMPLETE, a protocol error has occurred and the key exchange
MUST fail.
Hutzelman, et. al. Expires January 3, 2003 [Page 7]
Internet-Draft SSH GSSAPI Methods July 2002
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
no token at all, it sends the following:
byte SSH_MSG_KEXGSS_COMPLETE
mpint f
string per_msg_token (MIC of H)
boolean FALSE
If the client receives this message when no call to
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
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
following:
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 I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
This value is called the exchange hash, and it is used to
authenticate the key exchange. The exchange hash SHOULD be kept
secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the
server or received by the client, then the empty string is used in
place of K_S when computing the exchange hash.
The GSS_GetMIC call MUST be applied over H, not the original data.
Hutzelman, et. al. Expires January 3, 2003 [Page 8]
Internet-Draft SSH GSSAPI Methods July 2002
2.2 gss-group1-sha1-*
Each of these methods specifies GSSAPI authenticated Diffie-Hellman
key exchange as described in Section 2.1 with SHA-1 as HASH, and the
group defined in section 6.1 of [11]. The method name for each
method is the concatenation of the string "gss-group1-sha1-" with
the Base64 encoding of the MD5 hash [5] of the ASN.1 DER encoding
[1] of the underlying GSSAPI mechanism's OID. Base64 encoding is
described in section 6.8 of [6].
Each and every such key exchange method is implicitly registered by
this specification. The IESG is considered to be the owner of all
such key exchange methods; this does NOT imply that the IESG is
considered to be the owner of the underlying GSSAPI mechanism.
2.3 Other GSSAPI key exchange methods
Key exchange method names starting with "gss-" are reserved for key
exchange methods which conform to this document; in particular, for
those methods which use the GSSAPI authenticated Diffie-Hellman key
exchange algorithm described in Section 2.1, including any future
methods which use different groups and/or hash functions. The
intent is that the names for any such future methods methods be
defined in a similar manner to that used in Section 2.2.
Hutzelman, et. al. Expires January 3, 2003 [Page 9]
Internet-Draft SSH GSSAPI Methods July 2002
3. GSSAPI User Authentication
This section describes a general-purpose user authentication method
based on [2]. It is intended to be run over the SSH user
authentication protocol [12].
The authentication method name for this protocol is "gssapi".
3.1 GSSAPI Authentication Overview
GSSAPI authentication must maintain a context. Authentication
begins when the client sends a SSH_MSG_USERAUTH_REQUEST, which
specifies the mechanism OIDs the client supports.
If the server supports any of the requested mechanism OIDs, the
server sends a SSH_MSG_USERAUTH_GSSAPI_RESPONSE message containing
the mechanism OID.
After the client receives SSH_MSG_USERAUTH_GSSAPI_RESPONSE, the
client and server exchange SSH_MSG_USERAUTH_GSSAPI_TOKEN packets
until the authentication mechanism either succeeds or fails.
If at any time during the exchange, the client sends a new
SSH_MSG_USERAUTH_REQUEST packet, the GSSAPI context is completely
discarded and destroyed, and any further GSSAPI authentication MUST
restart from the beginning.
3.2 Initiating GSSAPI authentication
The GSSAPI authentication method is initiated when the client sends
a SSH_MSG_USERAUTH_REQUEST:
byte SSH_MSG_USERAUTH_REQUEST
string user name (in ISO-10646 UTF-8 encoding)
string service name (in US-ASCII)
string "gssapi" (US-ASCII method name)
uint32 n, the number of mechanism OIDs client supports
string[n] mechanism OIDs
Mechanism OIDs are encoded according to the ASN.1 basic encoding
rules (BER), as described in [1] and in section 3.1 of [2]. The
mechanism OIDs MUST be listed in order of preference, and the server
must choose the first mechanism OID on the list that it supports.
The client SHOULD NOT send more then one gssapi mechanism OID unless
there are no non-GSSAPI authentication methods between the GSSAPI
mechanisms in the order of preference, otherwise, authentication
methods may be executed out of order.
Hutzelman, et. al. Expires January 3, 2003 [Page 10]
Internet-Draft SSH GSSAPI Methods July 2002
If the server does not support any of the specified OIDs, the server
MUST fail the request by sending a SSH_MSG_USERAUTH_FAILURE packet.
The user name may be an empty string if it can be deduced from the
results of the gssapi authentication. If the user name is not
empty, and the requested user does not exist, the server MAY
disconnect, or MAY send a bogus list of acceptable authentications
but never accept any. This makes it possible for the server to
avoid disclosing information about which accounts exist. In any
case, if the user does not exist, the authentication request MUST
NOT be accepted.
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.3 Initial server response
The server responds to the SSH_MSG_USERAUTH_REQUEST with either a
SSH_MSG_USERAUTH_FAILURE if none of the mechanisms are supported, or
with SSH_MSG_USERAUTH_GSSAPI_RESPONSE as follows:
byte SSH_MSG_USERAUTH_GSSAPI_RESPONSE
string selected mechanism OID
The mechanism OID must be one of the OIDs sent by the client in the
SSH_MSG_USERAUTH_REQUEST packet.
3.4 GSSAPI session
Once the mechanism OID has been selected, the client will then
initiate an exchange of one or more pairs of
SSH_MSG_USERAUTH_GSSAPI_TOKEN packets. These packets contain the
tokens produced from the 'GSS_Init_sec_context()' and
'GSS_Accept_sec_context()' calls. The actual number of packets
exchanged is determined by the underlying GSSAPI mechanism.
byte SSH_MSG_USERAUTH_GSSAPI_TOKEN
string data returned from either GSS_Init_sec_context()
or GSS_Accept_sec_context()
If an error occurs during this exchange on server side, the server
can terminate the method by sending a SSH_MSG_USERAUTH_FAILURE
packet. If an error occurs on client side, the client can terminate
the method by sending a new SSH_MSG_USERAUTH_REQUEST packet.
The client MAY use the deleg_req_flag in calls to
GSS_Init_sec_context() to request credential delegation.
Hutzelman, et. al. Expires January 3, 2003 [Page 11]
Internet-Draft SSH GSSAPI Methods July 2002
Additional SSH_MSG_USERAUTH_GSSAPI_TOKEN messages are sent if and
only if the calls to the GSSAPI routines produce send tokens of
non-zero length.
Any major status code other than GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED SHOULD be a failure.
3.5 Client acknowledgement
It is possible for the server to successfully complete the GSSAPI
method and the client to fail. If the server simply assumed success
on the part of the client and completed the authentication service,
it is possible that the client would fail to complete the
authentication method, but not be able to retry other methods
because the server had already moved on.
Therefore, the client MUST send the following message when it has
successfully called GSS_Init_sec_context() and gotten GSS_S_COMPLETE:
byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
This message MUST be sent if and only if GSS_Init_sec_context()
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
method by sending a new SSH_MSG_USERAUTH_REQUEST.
3.6 Completion
As with all SSH authentication methods, successful completion is
indicated by a SSH_MSG_USERAUTH_SUCCESS if no other authentication
is required, or a SSH_MSG_USERAUTH_FAILURE with the partial success
flag set if the server requires further authentication.
This packet should be sent immediately following receipt of the the
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet.
Hutzelman, et. al. Expires January 3, 2003 [Page 12]
Internet-Draft SSH GSSAPI Methods July 2002
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.
Hutzelman, et. al. Expires January 3, 2003 [Page 13]
Internet-Draft SSH GSSAPI Methods July 2002
4. External Key Exchange User Authentication
This section describes a user authentication method building on the
framework described in [12]. This method relies upon the key
exchange to authenticate both the client and the server. If the key
exchange did not successfully perform these functions then the
server MUST always respond to this request with
SSH_MSG_USERAUTH_FAILURE with partial success set to false.
The new mechanism is defined as follows:
byte SSH_MSG_USERAUTH_REQUEST
string user name (in ISO-10646 UTF-8 encoding)
string service name (in US-ASCII)
string "external-keyx" (US-ASCII method name)
If the authentication performed as part of key exchange can be used
to authorize login as the requested user, this method is successful,
and the server responds with SSH_MSG_USERAUTH_SUCCESS if no more
authentications are needed, or with SSH_MSG_USERAUTH_FAILURE with
partial success set to true if more authentications are needed.
If the authentication performed as part of key-exchange cannot be
used to authorize login as the requested user, then
SSH_MSG_USERAUTH_FAILURE is returned with partial success set to
false.
If the user name is not empty, and the requested user does not
exist, the server MAY disconnect, or MAY send a bogus list of
acceptable authentications but never accept any. This makes it
possible for the server to avoid disclosing information about which
accounts exist. In any case, if the user does not exist, the
authentication request MUST NOT be accepted.
Any implementation supporting at least one key exchange method which
conforms to section 1 of this document SHOULD also support the
"external-keyx" user authentication method, in order to allow user
authentication to be performed at the same time as key exchange,
thereby reducing the number of round trips needed for connection
setup.
Hutzelman, et. al. Expires January 3, 2003 [Page 14]
Internet-Draft SSH GSSAPI Methods July 2002
5. Null Host Key Algorithm
The "null" host key algorithm has no associated host key material,
and provides neither signature nor encryption algorithms. Thus, it
can be used only with key exchange methods that do not require any
public-key operations and do not require the use of host public key
material. The key exchange methods described in section 1 of this
document are examples of such methods.
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
can be used when the administrator has decided as a matter of policy
to require that all key exchanges be authenticated using Kerberos
[3], and thus the only permitted key exchange method is the
GSSAPI-authenticated Diffie-Hellman exchange described above, with
Kerberos V5 as the underlying GSSAPI mechanism. In such a
configuration, the server implementation supports the "ssh-dss" key
algorithm (as required by [11]), but could be prohibited by
configuration from using it. In this situation, the server needs
some key exchange algorithm to advertise; the "null" algorithm fills
this purpose.
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
support this algorithm. This is not a significant problem, since in
the configuration described, it will also be unable to interoperate
with implementations that do not support the GSSAPI-authenticated
key exchange and Kerberos.
Any implementation supporting at least one key exchange method which
conforms to section 1 of this document MUST also support the "null"
host key algorithm. Servers MUST NOT advertise the "null" host key
algorithm unless it is the only algorithm advertised.
Hutzelman, et. al. Expires January 3, 2003 [Page 15]
Internet-Draft SSH GSSAPI Methods July 2002
6. Summary of Message Numbers
The following message numbers have been defined for use with
GSSAPI-based key exchange methods:
#define SSH_MSG_KEXGSS_INIT 30
#define SSH_MSG_KEXGSS_CONTINUE 31
#define SSH_MSG_KEXGSS_COMPLETE 32
#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
by other kex methods.
The following message numbers have been defined for use with the
'gssapi' user authentication method:
#define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60
#define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61
#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
redefined by other user auth methods. Note that in the method
described in this document, message number 62 is unused.
Hutzelman, et. al. Expires January 3, 2003 [Page 16]
Internet-Draft SSH GSSAPI Methods July 2002
7. GSSAPI Considerations
7.1 Naming Conventions
In order to establish a GSSAPI security context, the SSH client
needs to determine the appropriate targ_name to use in identifying
the server when calling GSS_Init_sec_context. For this purpose, the
GSSAPI mechanism-independent name form for host-based services is
used, as described in section 4.1 of [2].
In particular, the targ_name to pass to GSS_Init_sec_context is
obtained by calling GSS_Import_name with an input_name_type of
GSS_C_NT_HOSTBASED_SERVICE, and an input_name_string consisting of
the string "host@" concatenated with the hostname of the SSH server.
7.2 Channel Bindings
This document recommends that channel bindings SHOULD NOT be
specified in the calls during context establishment. This document
does not specify any standard data to be used as channel bindings
and the use of network addresses as channel bindings may break SSH
in environments where it is most useful.
7.3 SPNEGO
The use of the Simple and Protected GSS-API Negotiation Mechanism
[8] in conjunction with the authentication and key exchange methods
described in this document is both unnecessary and undesirable. As
a result, mechanisms conforming to this document MUST NOT use SPNEGO
as the underlying GSSAPI mechanism.
Since SSH performs its own negotiation of authentication and key
exchange methods, the negotiation capability of SPNEGO alone does
not provide any added benefit. In fact, as described below, it has
the potential to result in the use of a weaker method than desired.
Normally, SPNEGO provides the added benefit of protecting the GSSAPI
mechanism negotiation. It does this by having the server compute a
MIC of the list of mechanisms proposed by the client, and then
checking that value at the client. In the case of key exchange,
this protection is not needed because the key exchange methods
described here already perform an equivalent operation; namely, they
generate a MIC of the SSH exchange hash, which is a hash of several
items including the lists of key exchange mechanisms supported by
both sides. In the case of user authentication, the protection is
not needed because the negotiation occurs over a secure channel, and
the host's identity has already been proved to the user.
The use of SPNEGO combined with GSSAPI mechanisms used without
Hutzelman, et. al. Expires January 3, 2003 [Page 17]
Internet-Draft SSH GSSAPI Methods July 2002
SPNEGO can lead to interoperability problems. For example, a client
which supports key exchange using the Kerberos V5 GSSAPI mechanism
[4] only underneath SPNEGO will not interoperate with a server which
supports key exchange only using the Kerberos V5 GSSAPI mechanism
directly. As a result, allowing GSSAPI mechanisms to be used both
with and without SPNEGO is undesirable.
If a client's policy is to first prefer GSSAPI-based key exchange
method X, then non-GSSAPI method Y, then GSSAPI-based method Z, and
if a server supports mechanisms Y and Z but not X, then an attempt
to use SPNEGO to negotiate a GSSAPI mechanism might result in the
use of method Z when method Y would have been preferable. As a
result, the use of SPNEGO could result in the subversion of the
negotiation algorithm for key exchange methods as described in
section 5.1 of [11] and/or the negotiation algorithm for user
authentication methods as described in [12].
Hutzelman, et. al. Expires January 3, 2003 [Page 18]
Internet-Draft SSH GSSAPI Methods July 2002
8. Security Considerations
This document describes authentication and key-exchange protocols.
As such, security considerations are discussed throughout.
This protocol depends on the SSH protocol itself, the GSSAPI, any
underlying GSSAPI mechanisms which are used, and any protocols on
which such mechanisms might depend. Each of these components plays
a part in the security of the resulting connection, and each will
have its own security considerations.
The key exchange method described in section 1 of this document
depends on the underlying GSSAPI mechanism to provide both mutual
authentication and per-message integrity services. If either of
these features is not supported by a particular GSSAPI mechanism, or
by a particular implementation of a GSSAPI mechanism, then the key
exchange is not secure and MUST fail.
In order for the "external-keyx" user authentication method to be
used, it MUST have access to user authentication information
obtained as a side-effect of the key exchange. If this information
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.
Hutzelman, et. al. Expires January 3, 2003 [Page 19]
Internet-Draft SSH GSSAPI Methods July 2002
9. Acknowledgements
The authors would like to thank Sam Hartman and Simon Wilkinson for
their invaluable assistance with this document.
Hutzelman, et. al. Expires January 3, 2003 [Page 20]
Internet-Draft SSH GSSAPI Methods July 2002
10. Changes the last version
This section lists important changes since the previous version of
this internet-draft. This section should be removed at the time of
publication of this document as an RFC.
o Clarified the encoding of host keys in SSH_MSG_KEXGSS_HOSTKEY.
o Fixed a wording error in the description of the exchange hash;
the use of the empty string as the host key is dependent on the
SSH_MSG_KEXGSS_HOSTKEY message, which is sent by the server and
received by the client, not the other way around.
Hutzelman, et. al. Expires January 3, 2003 [Page 21]
Internet-Draft SSH GSSAPI Methods July 2002
References
[1] ISO/IEC, "Specification of Abstract Syntax Notation One
(ASN.1)", ISO/IEC 8824, November 1998.
[2] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[3] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[4] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[7] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[8] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
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.
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.
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.
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.
Hutzelman, et. al. Expires January 3, 2003 [Page 22]
Internet-Draft SSH GSSAPI Methods July 2002
[14] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
Authors' Addresses
Jeffrey Hutzelman
Carnegie Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
US
Phone: +1 412 268 7225
EMail: jhutz+@xxxxxxx
URI: http://www.cs.cmu.edu/~jhutz/
Joseph Salowey
Cisco Systems
Bldg 20
725 Alder Drive
Milpitas, CA 95035
US
Phone: +1 408 525 6381
EMail: jsalowey@xxxxxxxxx
Joseph Galbraith
Van Dyke Technologies, Inc.
4848 Tramway Ridge Dr. NE
Suite 101
Albuquerque, NM 87111
US
EMail: galb@xxxxxxxxxxx
Von Welch
University of Chicago & Argonne National Laboratory
Distributed Systems Laboratory
701 E. Washington
Urbana, IL 61801
US
EMail: welch@xxxxxxxxxxx
Hutzelman, et. al. Expires January 3, 2003 [Page 23]
Internet-Draft SSH GSSAPI Methods July 2002
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 assigns.
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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Hutzelman, et. al. Expires January 3, 2003 [Page 24]
Network Working Group T. Ylonen
Internet-Draft T. Kivinen
Expires: March 21, 2003 SSH Communications Security Corp
M. Saarinen
University of Jyvaskyla
T. Rinne
S. Lehtinen
SSH Communications Security Corp
September 20, 2002
SSH Transport Layer Protocol
draft-ietf-secsh-transport-15.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 21, 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 transport layer protocol which
typically runs on top of TCP/IP. The protocol can be used as a basis
for a number of secure network services. It provides strong
Ylonen, et. al. Expires March 21, 2003 [Page 1]
Internet-Draft SSH Transport Layer Protocol September 2002
encryption, server authentication, and integrity protection. It may
also provide compression.
Key exchange method, public key algorithm, symmetric encryption
algorithm, message authentication algorithm, and hash algorithm are
all negotiated.
This document also describes the Diffie-Hellman key exchange method
and the minimal set of algorithms that are needed to implement the
SSH transport layer protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . . 3
3.3 Compatibility With Old SSH Versions . . . . . . . . . . . . . 4
3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . . 4
3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . . 5
4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . 5
4.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . . 6
4.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 10
4.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 10
5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . . 13
5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 16
5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 17
6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 17
6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 19
7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . 19
8. Service Request . . . . . . . . . . . . . . . . . . . . . . . 20
9. Additional Messages . . . . . . . . . . . . . . . . . . . . . 21
9.1 Disconnection Message . . . . . . . . . . . . . . . . . . . . 21
9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 22
9.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . . 22
9.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . . 23
10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 25
13. Additional Information . . . . . . . . . . . . . . . . . . . . 25
References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 28
Ylonen, et. al. Expires March 21, 2003 [Page 2]
Internet-Draft SSH Transport Layer Protocol September 2002
1. Introduction
The SSH transport layer is a secure low level transport protocol. It
provides strong encryption, cryptographic host authentication, and
integrity protection.
Authentication in this protocol level is host-based; this protocol
does not perform user authentication. A higher level protocol for
user authentication can be designed on top of this protocol.
The protocol has been designed to be simple, flexible, to allow
parameter negotiation, and to minimize the number of round-trips.
Key exchange method, public key algorithm, symmetric encryption
algorithm, message authentication algorithm, and hash algorithm are
all negotiated. It is expected that in most environments, only 2
round-trips will be needed for full key exchange, server
authentication, service request, and acceptance notification of
service request. The worst case is 3 round-trips.
2. 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. Connection Setup
SSH works over any 8-bit clean, binary-transparent transport. The
underlying transport SHOULD protect against transmission errors as
such errors cause the SSH connection to terminate.
The client initiates the connection.
3.1 Use over TCP/IP
When used over TCP/IP, the server normally listens for connections on
port 22. This port number has been registered with the IANA, and has
been officially assigned for SSH.
3.2 Protocol Version Exchange
When the connection has been established, both sides MUST send an
Ylonen, et. al. Expires March 21, 2003 [Page 3]
Internet-Draft SSH Transport Layer Protocol September 2002
identification string of the form "SSH-protoversion-softwareversion
comments", followed by carriage return and newline characters (ASCII
13 and 10, respectively). Both sides MUST be able to process
identification strings without carriage return character. No null
character is sent. The maximum length of the string is 255
characters, including the carriage return and newline.
The part of the identification string preceding carriage return and
newline is used in the Diffie-Hellman key exchange (see Section
Section 6).
The server MAY send other lines of data before sending the version
string. Each line SHOULD be terminated by a carriage return and
newline. Such lines MUST NOT begin with "SSH-", and SHOULD be
encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified).
Clients MUST be able to process such lines; they MAY be silently
ignored, or MAY be displayed to the client user; if they are
displayed, control character filtering discussed in [SSH-ARCH] SHOULD
be used. The primary use of this feature is to allow TCP-wrappers to
display an error message before disconnecting.
Version strings MUST consist of printable US-ASCII characters, not
including whitespaces or a minus sign (-). The version string is
primarily used to trigger compatibility extensions and to indicate
the capabilities of an implementation. The comment string should
contain additional information that might be useful in solving user
problems.
The protocol version described in this document is 2.0.
Key exchange will begin immediately after sending this identifier.
All packets following the identification string SHALL use the binary
packet protocol, to be described below.
3.3 Compatibility With Old SSH Versions
During the transition period, it is important to be able to work in a
way that is compatible with the installed SSH clients and servers
that use an older version of the protocol. Information in this
section is only relevant for implementations supporting compatibility
with SSH versions 1.x.
3.4 Old Client, New Server
Server implementations MAY support a configurable "compatibility"
flag that enables compatibility with old versions. When this flag is
on, the server SHOULD identify its protocol version as "1.99".
Clients using protocol 2.0 MUST be able to identify this as identical
Ylonen, et. al. Expires March 21, 2003 [Page 4]
Internet-Draft SSH Transport Layer Protocol September 2002
to "2.0". In this mode the server SHOULD NOT send the carriage
return character (ASCII 13) after the version identification string.
In the compatibility mode the server SHOULD NOT send any further data
after its initialization string until it has received an
identification string from the client. The server can then determine
whether the client is using an old protocol, and can revert to the
old protocol if required. In the compatibility mode, the server MUST
NOT send additional data before the version string.
When compatibility with old clients is not needed, the server MAY
send its initial key exchange data immediately after the
identification string.
3.5 New Client, Old Server
Since the new client MAY immediately send additional data after its
identification string (before receiving server's identification), the
old protocol may already have been corrupted when the client learns
that the server is old. When this happens, the client SHOULD close
the connection to the server, and reconnect using the old protocol.
4. Binary Packet Protocol
Each packet is in the following format:
uint32 packet_length
byte padding_length
byte[n1] payload; n1 = packet_length - padding_length - 1
byte[n2] random padding; n2 = padding_length
byte[m] mac (message authentication code); m = mac_length
packet_length
The length of the packet (bytes), not including MAC or the
packet_length field itself.
padding_length
Length of padding (bytes).
payload
The useful contents of the packet. If compression has been
negotiated, this field is compressed. Initially, compression
MUST be "none".
random padding
Arbitrary-length padding, such that the total length of
(packet_length || padding_length || payload || padding) is a
multiple of the cipher block size or 8, whichever is larger.
Ylonen, et. al. Expires March 21, 2003 [Page 5]
Internet-Draft SSH Transport Layer Protocol September 2002
There MUST be at least four bytes of padding. The padding
SHOULD consist of random bytes. The maximum amount of padding
is 255 bytes.
mac
Message authentication code. If message authentication has
been negotiated, this field contains the MAC bytes. Initially,
the MAC algorithm MUST be "none".
Note that length of the concatenation of packet length, padding
length, payload, and padding MUST be a multiple of the cipher block
size or 8, whichever is larger. This constraint MUST be enforced
even when using stream ciphers. Note that the packet length field is
also encrypted, and processing it requires special care when sending
or receiving packets.
The minimum size of a packet is 16 (or the cipher block size,
whichever is larger) bytes (plus MAC); implementations SHOULD decrypt
the length after receiving the first 8 (or cipher block size,
whichever is larger) bytes of a packet.
4.1 Maximum Packet Length
All implementations MUST be able to process packets with uncompressed
payload length of 32768 bytes or less and total packet size of 35000
bytes or less (including length, padding length, payload, padding,
and MAC.). The maximum of 35000 bytes is an arbitrary chosen value
larger than uncompressed size. Implementations SHOULD support longer
packets, where they might be needed, e.g. if an implementation wants
to send a very large number of certificates. Such packets MAY be
sent if the version string indicates that the other party is able to
process them. However, implementations SHOULD check that the packet
length is reasonable for the implementation to avoid denial-of-
service and/or buffer overflow attacks.
4.2 Compression
If compression has been negotiated, the payload field (and only it)
will be compressed using the negotiated algorithm. The length field
and MAC will be computed from the compressed payload. Encryption
will be done after compression.
Compression MAY be stateful, depending on the method. Compression
MUST be independent for each direction, and implementations MUST
allow independently choosing the algorithm for each direction.
The following compression methods are currently defined:
Ylonen, et. al. Expires March 21, 2003 [Page 6]
Internet-Draft SSH Transport Layer Protocol September 2002
none REQUIRED no compression
zlib OPTIONAL ZLIB (LZ77) compression
The "zlib" compression is described in [RFC1950] and in [RFC1951].
The compression context is initialized after each key exchange, and
is passed from one packet to the next with only a partial flush being
performed at the end of each packet. A partial flush means that the
current compressed block is ended and all data will be output. If
the current block is not a stored block, one or more empty blocks are
added after the current block to ensure that there are at least 8
bits counting from the start of the end-of-block code of the current
block to the end of the packet payload.
Additional methods may be defined as specified in [SSH-ARCH].
4.3 Encryption
An encryption algorithm and a key will be negotiated during the key
exchange. When encryption is in effect, the packet length, padding
length, payload and padding fields of each packet MUST be encrypted
with the given algorithm.
The encrypted data in all packets sent in one direction SHOULD be
considered a single data stream. For example, initialization vectors
SHOULD be passed from the end of one packet to the beginning of the
next packet. All ciphers SHOULD use keys with an effective key
length of 128 bits or more.
The ciphers in each direction MUST run independently of each other,
and implementations MUST allow independently choosing the algorithm
for each direction (if multiple algorithms are allowed by local
policy).
The following ciphers are currently defined:
3des-cbc REQUIRED three-key 3DES in CBC mode
blowfish-cbc RECOMMENDED Blowfish in CBC mode
twofish256-cbc OPTIONAL Twofish in CBC mode,
with 256-bit key
twofish-cbc OPTIONAL alias for "twofish256-cbc" (this
is being retained for
historical reasons)
twofish192-cbc OPTIONAL Twofish with 192-bit key
twofish128-cbc RECOMMENDED Twofish with 128-bit key
aes256-cbc OPTIONAL AES (Rijndael) in CBC mode,
with 256-bit key
aes192-cbc OPTIONAL AES with 192-bit key
aes128-cbc RECOMMENDED AES with 128-bit key
Ylonen, et. al. Expires March 21, 2003 [Page 7]
Internet-Draft SSH Transport Layer Protocol September 2002
serpent256-cbc OPTIONAL Serpent in CBC mode, with
256-bit key
serpent192-cbc OPTIONAL Serpent with 192-bit key
serpent128-cbc OPTIONAL Serpent with 128-bit key
arcfour OPTIONAL the ARCFOUR stream cipher
idea-cbc OPTIONAL IDEA in CBC mode
cast128-cbc OPTIONAL CAST-128 in CBC mode
none OPTIONAL no encryption; NOT RECOMMENDED
The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
encrypt), where the first 8 bytes of the key are used for the first
encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption. This requires 24 bytes of key data
(of which 168 bits are actually used). To implement CBC mode, outer
chaining MUST be used (i.e., there is only one initialization
vector). This is a block cipher with 8 byte blocks. This algorithm
is defined in [SCHNEIER]
The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys
[SCHNEIER]. This is a block cipher with 8 byte blocks.
The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode,
with 256 bit keys as described [TWOFISH]. This is a block cipher
with 16 byte blocks.
The "twofish192-cbc" cipher. Same as above but with 192-bit key.
The "twofish128-cbc" cipher. Same as above but with 128-bit key.
The "aes256-cbc" cipher is AES (Advanced Encryption Standard),
formerly Rijndael, in CBC mode. This version uses 256-bit key.
The "aes192-cbc" cipher. Same as above but with 192-bit key.
The "aes128-cbc" cipher. Same as above but with 128-bit key.
The "serpent256-cbc" cipher in CBC mode, with 256-bit key as
described in the Serpent AES submission.
The "serpent192-cbc" cipher. Same as above but with 192-bit key.
The "serpent128-cbc" cipher. Same as above but with 128-bit key.
The "arcfour" is the Arcfour stream cipher with 128 bit keys. The
Arcfour cipher is believed to be compatible with the RC4 cipher
[SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc.
Arcfour (and RC4) has problems with weak keys, and should be used
with caution.
Ylonen, et. al. Expires March 21, 2003 [Page 8]
Internet-Draft SSH Transport Layer Protocol September 2002
The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].
IDEA is patented by Ascom AG.
The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode
[RFC2144].
The "none" algorithm specifies that no encryption is to be done.
Note that this method provides no confidentiality protection, and it
is not recommended. Some functionality (e.g. password
authentication) may be disabled for security reasons if this cipher
is chosen.
Additional methods may be defined as specified in [SSH-ARCH].
4.4 Data Integrity
Data integrity is protected by including with each packet a message
authentication code (MAC) that is computed from a shared secret,
packet sequence number, and the contents of the packet.
The message authentication algorithm and key are negotiated during
key exchange. Initially, no MAC will be in effect, and its length
MUST be zero. After key exchange, the selected MAC will be computed
before encryption from the concatenation of packet data:
mac = MAC(key, sequence_number || unencrypted_packet)
where unencrypted_packet is the entire packet without MAC (the length
fields, payload and padding), and sequence_number is an implicit
packet sequence number represented as uint32. The sequence number is
initialized to zero for the first packet, and is incremented after
every packet (regardless of whether encryption or MAC is in use). It
is never reset, even if keys/algorithms are renegotiated later. It
wraps around to zero after every 2^32 packets. The packet sequence
number itself is not included in the packet sent over the wire.
The MAC algorithms for each direction MUST run independently, and
implementations MUST allow choosing the algorithm independently for
both directions.
The MAC bytes resulting from the MAC algorithm MUST be transmitted
without encryption as the last part of the packet. The number of MAC
bytes depends on the algorithm chosen.
Ylonen, et. al. Expires March 21, 2003 [Page 9]
Internet-Draft SSH Transport Layer Protocol September 2002
The following MAC algorithms are currently defined:
hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key
length = 20)
hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest
length = 12, key length = 20)
hmac-md5 OPTIONAL HMAC-MD5 (digest length = key
length = 16)
hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest
length = 12, key length = 16)
none OPTIONAL no MAC; NOT RECOMMENDED
The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use
only the first n bits of the resulting value.
The hash algorithms are described in [SCHNEIER].
Additional methods may be defined as specified in [SSH-ARCH].
4.5 Key Exchange Methods
The key exchange method specifies how one-time session keys are
generated for encryption and for authentication, and how the server
authentication is done.
Only one REQUIRED key exchange method has been defined:
diffie-hellman-group1-sha1 REQUIRED
This method is described later in this document.
Additional methods may be defined as specified in [SSH-ARCH].
4.6 Public Key Algorithms
This protocol has been designed to be able to operate with almost any
public key format, encoding, and algorithm (signature and/or
encryption).
There are several aspects that define a public key type:
o Key format: how is the key encoded and how are certificates
represented. The key blobs in this protocol MAY contain
certificates in addition to keys.
o Signature and/or encryption algorithms. Some key types may not
support both signing and encryption. Key usage may also be
restricted by policy statements in e.g. certificates. In this
case, different key types SHOULD be defined for the different
policy alternatives.
Ylonen, et. al. Expires March 21, 2003 [Page 10]
Internet-Draft SSH Transport Layer Protocol September 2002
o Encoding of signatures and/or encrypted data. This includes but
is not limited to padding, byte order, and data formats.
The following public key and/or certificate formats are currently defined:
ssh-dss REQUIRED sign Simple DSS
ssh-rsa RECOMMENDED sign Simple RSA
x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key)
x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key)
spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key)
spki-sign-dss OPTIONAL sign SPKI certificates (DSS key)
pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key)
pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key)
Additional key types may be defined as specified in [SSH-ARCH].
The key type MUST always be explicitly known (from algorithm
negotiation or some other source). It is not normally included in
the key blob.
Certificates and public keys are encoded as follows:
string certificate or public key format identifier
byte[n] key/certificate data
The certificate part may have be a zero length string, but a public
key is required. This is the public key that will be used for
authentication; the certificate sequence contained in the certificate
blob can be used to provide authorization.
Public key / certifcate formats that do not explicitly specify a
signature format identifier MUST use the public key / certificate
format identifier as the signature identifier.
Signatures are encoded as follows:
string signature format identifier (as specified by the
public key / cert format)
byte[n] signature blob in format specific encoding.
The "ssh-dss" key format has the following specific encoding:
string "ssh-dss"
mpint p
mpint q
mpint g
mpint y
Ylonen, et. al. Expires March 21, 2003 [Page 11]
Internet-Draft SSH Transport Layer Protocol September 2002
Here the p, q, g, and y parameters form the signature key blob.
Signing and verifying using this key format is done according to the
Digital Signature Standard [FIPS-186] using the SHA-1 hash. A
description can also be found in [SCHNEIER].
The resulting signature is encoded as follows:
string "ssh-dss"
string dss_signature_blob
dss_signature_blob is encoded as a string containing r followed by s
(which are 160 bits long integers, without lengths or padding,
unsigned and in network byte order).
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
Here the e and n parameters form the signature key blob.
Signing and verifying using this key format is done according to
[SCHNEIER] and [PKCS1] using the SHA-1 hash.
The resulting signature is encoded as follows:
string "ssh-rsa"
string rsa_signature_blob
rsa_signature_blob is encoded as a string containing s (which is an
integer, without lengths or padding, unsigned and in network byte
order).
The "spki-sign-rsa" method indicates that the certificate blob
contains a sequence of SPKI certificates. The format of SPKI
certificates is described in [RFC2693]. This method indicates that
the key (or one of the keys in the certificate) is an RSA-key.
The "spki-sign-dss". As above, but indicates that the key (or one of
the keys in the certificate) is a DSS-key.
The "pgp-sign-rsa" method indicates the certificates, the public key,
and the signature are in OpenPGP compatible binary format
([RFC2440]). This method indicates that the key is an RSA-key.
The "pgp-sign-dss". As above, but indicates that the key is a DSS-
Ylonen, et. al. Expires March 21, 2003 [Page 12]
Internet-Draft SSH Transport Layer Protocol September 2002
key.
5. Key Exchange
Key exchange begins by each side sending lists of supported
algorithms. Each side has a preferred algorithm in each category,
and it is assumed that most implementations at any given time will
use the same preferred algorithm. Each side MAY guess which
algorithm the other side is using, and MAY send an initial key
exchange packet according to the algorithm if appropriate for the
preferred method.
Guess is considered wrong, if:
o the kex algorithm and/or the host key algorithm is guessed wrong
(server and client have different preferred algorithm), or
o if any of the other algorithms cannot be agreed upon (the
procedure is defined below in Section Section 5.1).
Otherwise, the guess is considered to be right and the optimistically
sent packet MUST be handled as the first key exchange packet.
However, if the guess was wrong, and a packet was optimistically sent
by one or both parties, such packets MUST be ignored (even if the
error in the guess would not affect the contents of the initial
packet(s)), and the appropriate side MUST send the correct initial
packet.
Server authentication in the key exchange MAY be implicit. After a
key exchange with implicit server authentication, the client MUST
wait for response to its service request message before sending any
further data.
5.1 Algorithm Negotiation
Key exchange begins by each side sending the following packet:
byte SSH_MSG_KEXINIT
byte[16] cookie (random bytes)
string kex_algorithms
string server_host_key_algorithms
string encryption_algorithms_client_to_server
string encryption_algorithms_server_to_client
string mac_algorithms_client_to_server
string mac_algorithms_server_to_client
string compression_algorithms_client_to_server
string compression_algorithms_server_to_client
string languages_client_to_server
string languages_server_to_client
Ylonen, et. al. Expires March 21, 2003 [Page 13]
Internet-Draft SSH Transport Layer Protocol September 2002
boolean first_kex_packet_follows
uint32 0 (reserved for future extension)
Each of the algorithm strings MUST be a comma-separated list of
algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each
supported (allowed) algorithm MUST be listed in order of preference.
The first algorithm in each list MUST be the preferred (guessed)
algorithm. Each string MUST contain at least one algorithm name.
cookie
The cookie MUST be a random value generated by the sender. Its
purpose is to make it impossible for either side to fully
determine the keys and the session identifier.
kex_algorithms
Key exchange algorithms were defined above. The first
algorithm MUST be the preferred (and guessed) algorithm. If
both sides make the same guess, that algorithm MUST be used.
Otherwise, the following algorithm MUST be used to choose a key
exchange method: iterate over client's kex algorithms, one at a
time. Choose the first algorithm that satisfies the following
conditions:
+ the server also supports the algorithm,
+ if the algorithm requires an encryption-capable host key,
there is an encryption-capable algorithm on the server's
server_host_key_algorithms that is also supported by the
client, and
+ if the algorithm requires a signature-capable host key,
there is a signature-capable algorithm on the server's
server_host_key_algorithms that is also supported by the
client.
+ If no algorithm satisfying all these conditions can be
found, the connection fails, and both sides MUST disconnect.
server_host_key_algorithms
List of the algorithms supported for the server host key. The
server lists the algorithms for which it has host keys; the
client lists the algorithms that it is willing to accept.
(There MAY be multiple host keys for a host, possibly with
different algorithms.)
Some host keys may not support both signatures and encryption
(this can be determined from the algorithm), and thus not all
host keys are valid for all key exchange methods.
Algorithm selection depends on whether the chosen key exchange
Ylonen, et. al. Expires March 21, 2003 [Page 14]
Internet-Draft SSH Transport Layer Protocol September 2002
algorithm requires a signature or encryption capable host key.
It MUST be possible to determine this from the public key
algorithm name. The first algorithm on the client's list that
satisfies the requirements and is also supported by the server
MUST be chosen. If there is no such algorithm, both sides MUST
disconnect.
encryption_algorithms
Lists the acceptable symmetric encryption algorithms in order
of preference. The chosen encryption algorithm to each
direction MUST be the first algorithm on the client's list
that is also on the server's list. If there is no such
algorithm, both sides MUST disconnect.
Note that "none" must be explicitly listed if it is to be
acceptable. The defined algorithm names are listed in Section
Section 4.3.
mac_algorithms
Lists the acceptable MAC algorithms in order of preference.
The chosen MAC algorithm MUST be the first algorithm on the
client's list that is also on the server's list. If there is
no such algorithm, both sides MUST disconnect.
Note that "none" must be explicitly listed if it is to be
acceptable. The MAC algorithm names are listed in Section
Figure 1.
compression_algorithms
Lists the acceptable compression algorithms in order of
preference. The chosen compression algorithm MUST be the first
algorithm on the client's list that is also on the server's
list. If there is no such algorithm, both sides MUST
disconnect.
Note that "none" must be explicitly listed if it is to be
acceptable. The compression algorithm names are listed in
Section Section 4.2.
languages
This is a comma-separated list of language tags in order of
preference [RFC1766]. Both parties MAY ignore this list. If
there are no language preferences, this list SHOULD be empty.
first_kex_packet_follows
Indicates whether a guessed key exchange packet follows. If a
guessed packet will be sent, this MUST be TRUE. If no guessed
packet will be sent, this MUST be FALSE.
Ylonen, et. al. Expires March 21, 2003 [Page 15]
After receiving the SSH_MSG_KEXINIT packet from the other side,
each party will know whether their guess was right. If the
other party's guess was wrong, and this field was TRUE, the
next packet MUST be silently ignored, and both sides MUST then
act as determined by the negotiated key exchange method. If
the guess was right, key exchange MUST continue using the
guessed packet.
After the KEXINIT packet exchange, the key exchange algorithm is run.
It may involve several packet exchanges, as specified by the key
exchange method.
5.2 Output from Key Exchange
The key exchange produces two values: a shared secret K, and an
exchange hash H. Encryption and authentication keys are derived from
these. The exchange hash H from the first key exchange is
additionally used as the session identifier, which is a unique
identifier for this connection. It is used by authentication methods
as a part of the data that is signed as a proof of possession of a
private key. Once computed, the session identifier is not changed,
even if keys are later re-exchanged.
Each key exchange method specifies a hash function that is used in
the key exchange. The same hash algorithm MUST be used in key
derivation. Here, we'll call it HASH.
Encryption keys MUST be computed as HASH of a known value and K as
follows:
o Initial IV client to server: HASH(K || H || "A" || session_id)
(Here K is encoded as mpint and "A" as byte and session_id as raw
data."A" means the single character A, ASCII 65).
o Initial IV server to client: HASH(K || H || "B" || session_id)
o Encryption key client to server: HASH(K || H || "C" || session_id)
o Encryption key server to client: HASH(K || H || "D" || session_id)
o Integrity key client to server: HASH(K || H || "E" || session_id)
o Integrity key server to client: HASH(K || H || "F" || session_id)
Key data MUST be taken from the beginning of the hash output. 128
bits (16 bytes) SHOULD be used for algorithms with variable-length
keys. For other algorithms, as many bytes as are needed are taken
from the beginning of the hash value. If the key length in longer
than the output of the HASH, the key is extended by computing HASH of
the concatenation of K and H and the entire key so far, and appending
the resulting bytes (as many as HASH generates) to the key. This
process is repeated until enough key material is available; the key
is taken from the beginning of this value. In other words:
Ylonen, et. al. Expires March 21, 2003 [Page 16]
Internet-Draft SSH Transport Layer Protocol September 2002
K1 = HASH(K || H || X || session_id) (X is e.g. "A")
K2 = HASH(K || H || K1)
K3 = HASH(K || H || K1 || K2)
...
key = K1 || K2 || K3 || ...
This process will lose entropy if the amount of entropy in K is
larger than the internal state size of HASH.
5.3 Taking Keys Into Use
Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
This message is sent with the old keys and algorithms. All messages
sent after this message MUST use the new keys and algorithms.
When this message is received, the new keys and algorithms MUST be
taken into use for receiving.
This message is the only valid message after key exchange, in
addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE
messages. The purpose of this message is to ensure that a party is
able to respond with a disconnect message that the other party can
understand if something goes wrong with the key exchange.
Implementations MUST NOT accept any other messages after key exchange
before receiving SSH_MSG_NEWKEYS.
byte SSH_MSG_NEWKEYS
6. Diffie-Hellman Key Exchange
The Diffie-Hellman key exchange provides a shared secret that can not
be determined by either party alone. The key exchange is combined
with a signature with the host key to provide host authentication.
In the following description (C is the client, S is the server; p is
a large safe prime, g is a generator for a subgroup of GF(p), and q
is the order of the subgroup; V_S is S's version string; V_C is C's
version string; K_S is S's public host key; I_C is C's KEXINIT
message and I_S S's KEXINIT message which have been exchanged before
this part begins):
1. C generates a random number x (1 < x < q) and computes e = g^x
mod p. C sends "e" to S.
Ylonen, et. al. Expires March 21, 2003 [Page 17]
2. S generates a random number y (0 < y < q) and computes f = g^y
mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C
|| V_S || I_C || I_S || K_S || e || f || K) (these elements are
encoded according to their types; see below), and signature s on
H with its private host key. S sends "K_S || f || s" to C. The
signing operation may involve a second hashing operation.
3. C verifies that K_S really is the host key for S (e.g. using
certificates or a local database). C is also allowed to accept
the key without verification; however, doing so will render the
protocol insecure against active attacks (but may be desirable
for practical reasons in the short term in many environments). C
then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S ||
K_S || e || f || K), and verifies the signature s on H.
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
fails.
This is implemented with the following messages. The hash algorithm
for computing the exchange hash is defined by the method name, and is
called HASH. The public key algorithm for signing is negotiated with
the KEXINIT messages.
First, the client sends the following:
byte SSH_MSG_KEXDH_INIT
mpint e
The server responds with the following:
byte SSH_MSG_KEXDH_REPLY
string server public host key and certificates (K_S)
mpint f
string signature of H
The hash H is computed as the HASH hash of the concatenation of the
following:
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 I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
Ylonen, et. al. Expires March 21, 2003 [Page 18]
Internet-Draft SSH Transport Layer Protocol September 2002
This value is called the exchange hash, and it is used to
authenticate the key exchange. The exchange hash SHOULD be kept
secret.
The signature algorithm MUST be applied over H, not the original
data. Most signature algorithms include hashing and additional
padding. For example, "ssh-dss" specifies SHA-1 hashing; in that
case, the data is first hashed with HASH to compute H, and H is then
hashed with SHA-1 as part of the signing operation.
6.1 diffie-hellman-group1-sha1
The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
exchange with SHA-1 as HASH, and the following group:
The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi +
129093 ). Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF.
In decimal, this value is:
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007.
The generator used with this prime is g = 2. The group order q is (p
- 1) / 2.
This group was taken from the ISAKMP/Oakley specification, and was
originally generated by Richard Schroeppel at the University of
Arizona. Properties of this prime are described in [Orm96].
7. Key Re-Exchange
Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when
not already doing a key exchange (as described in Section Section
5.1). When this message is received, a party MUST respond with its
own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT
Ylonen, et. al. Expires March 21, 2003 [Page 19]
Internet-Draft SSH Transport Layer Protocol September 2002
already was a reply. Either party MAY initiate the re-exchange, but
roles MUST NOT be changed (i.e., the server remains the server, and
the client remains the client).
Key re-exchange is performed using whatever encryption was in effect
when the exchange was started. Encryption, compression, and MAC
methods are not changed before a new SSH_MSG_NEWKEYS is sent after
the key exchange (as in the initial key exchange). Re-exchange is
processed identically to the initial key exchange, except for the
session identifier that will remain unchanged. It is permissible to
change some or all of the algorithms during the re-exchange. Host
keys can also change. All keys and initialization vectors are
recomputed after the exchange. Compression and encryption contexts
are reset.
It is recommended that the keys are changed after each gigabyte of
transmitted data or after each hour of connection time, whichever
comes sooner. However, since the re-exchange is a public key
operation, it requires a fair amount of processing power and should
not be performed too often.
More application data may be sent after the SSH_MSG_NEWKEYS packet
has been sent; key exchange does not affect the protocols that lie
above the SSH transport layer.
8. Service Request
After the key exchange, the client requests a service. The service
is identified by a name. The format of names and procedures for
defining new names are defined in [SSH-ARCH].
Currently, the following names have been reserved:
ssh-userauth
ssh-connection
Similar local naming policy is applied to the service names, as is
applied to the algorithm names; a local service should use the
"servicename@domain" syntax.
byte SSH_MSG_SERVICE_REQUEST
string service name
If the server rejects the service request, it SHOULD send an
Ylonen, et. al. Expires March 21, 2003 [Page 20]
Internet-Draft SSH Transport Layer Protocol September 2002
appropriate SSH_MSG_DISCONNECT message and MUST disconnect.
When the service starts, it may have access to the session identifier
generated during the key exchange.
If the server supports the service (and permits the client to use
it), it MUST respond with the following:
byte SSH_MSG_SERVICE_ACCEPT
string service name
Message numbers used by services should be in the area reserved for
them (see Section 6 in [SSH-ARCH]). The transport level will
continue to process its own messages.
Note that after a key exchange with implicit server authentication,
the client MUST wait for response to its service request message
before sending any further data.
9. Additional Messages
Either party may send any of the following messages at any time.
9.1 Disconnection Message
byte SSH_MSG_DISCONNECT
uint32 reason code
string description [RFC2279]
string language tag [RFC1766]
This message causes immediate termination of the connection. All
implementations MUST be able to process this message; they SHOULD be
able to send this message.
The sender MUST NOT send or receive any data after this message, and
the recipient MUST NOT accept any data after receiving this message.
The description field gives a more specific explanation in a human-
readable form. The error code gives the reason in a more machine-
readable format (suitable for localization), and can have the
following values:
#define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
#define SSH_DISCONNECT_PROTOCOL_ERROR 2
#define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
#define SSH_DISCONNECT_RESERVED 4
Ylonen, et. al. Expires March 21, 2003 [Page 21]
Internet-Draft SSH Transport Layer Protocol September 2002
#define SSH_DISCONNECT_MAC_ERROR 5
#define SSH_DISCONNECT_COMPRESSION_ERROR 6
#define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
#define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
#define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
#define SSH_DISCONNECT_CONNECTION_LOST 10
#define SSH_DISCONNECT_BY_APPLICATION 11
#define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
#define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
#define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
#define SSH_DISCONNECT_ILLEGAL_USER_NAME 15
If the description string is displayed, control character filtering
discussed in [SSH-ARCH] should be used to avoid attacks by sending
terminal control characters.
9.2 Ignored Data Message
byte SSH_MSG_IGNORE
string data
All implementations MUST understand (and ignore) this message at any
time (after receiving the protocol version). No implementation is
required to send them. This message can be used as an additional
protection measure against advanced traffic analysis techniques.
9.3 Debug Message
byte SSH_MSG_DEBUG
boolean always_display
string message [RFC2279]
string language tag [RFC1766]
All implementations MUST understand this message, but they are
allowed to ignore it. This message is used to pass the other side
information that may help debugging. If always_display is TRUE, the
message SHOULD be displayed. Otherwise, it SHOULD NOT be displayed
unless debugging information has been explicitly requested by the
user.
The message doesn't need to contain a newline. It is, however,
allowed to consist of multiple lines separated by CRLF (Carriage
Return - Line Feed) pairs.
If the message string is displayed, terminal control character
filtering discussed in [SSH-ARCH] should be used to avoid attacks by
Ylonen, et. al. Expires March 21, 2003 [Page 22]
Internet-Draft SSH Transport Layer Protocol September 2002
sending terminal control characters.
9.4 Reserved Messages
An implementation MUST respond to all unrecognized messages with an
SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
received. Such messages MUST be otherwise ignored. Later protocol
versions may define other meanings for these message types.
byte SSH_MSG_UNIMPLEMENTED
uint32 packet sequence number of rejected message
10. Summary of Message Numbers
The following message numbers have been defined in this protocol:
#define SSH_MSG_DISCONNECT 1
#define SSH_MSG_IGNORE 2
#define SSH_MSG_UNIMPLEMENTED 3
#define SSH_MSG_DEBUG 4
#define SSH_MSG_SERVICE_REQUEST 5
#define SSH_MSG_SERVICE_ACCEPT 6
#define SSH_MSG_KEXINIT 20
#define SSH_MSG_NEWKEYS 21
/* Numbers 30-49 used for kex packets.
Different kex methods may reuse message numbers in
this range. */
#define SSH_MSG_KEXDH_INIT 30
#define SSH_MSG_KEXDH_REPLY 31
11. Security Considerations
This protocol provides a secure encrypted channel over an insecure
network. It performs server host authentication, key exchange,
encryption, and integrity protection. It also derives a unique
session id that may be used by higher-level protocols.
It is expected that this protocol will sometimes be used without
insisting on reliable association between the server host key and the
server host name. Such use is inherently insecure, but may be
necessary in non-security critical environments, and still provides
protection against passive attacks. However, implementors of
protocols running on top of this protocol should keep this
Ylonen, et. al. Expires March 21, 2003 [Page 23]
Internet-Draft SSH Transport Layer Protocol September 2002
possibility in mind.
This protocol is designed to be used over a reliable transport. If
transmission errors or message manipulation occur, the connection is
closed. The connection SHOULD be re-established if this occurs.
Denial of service attacks of this type ("wire cutter") are almost
impossible to avoid.
The protocol was not designed to eliminate covert channels. For
example, the padding, SSH_MSG_IGNORE messages, and several other
places in the protocol can be used to pass covert information, and
the recipient has no reliable way to verify whether such information
is being sent.
Nearly all ciphers specified in this document are used in cipher
block chaining (CBC) mode. It's been known for some time that CBC
modes will reveal information about the plaintext if two ciphertext
blocks encrypted under the same key are equal; this is one of the
reasons this document strongly recommends rekeying at least once per
gigabyte of data, to reduce the chance that a "birthday paradox"
collision will appear.
Recent research has uncovered a new attack on CBC mode which, under
certain conditions, allows a chosen plaintext attacker aware of the
IV for a forthcoming message to have some chance to artificially
induce a system into generating ciphertext collisions, allowing the
attacker's guesses at likely prior plaintexts to be confirmed.
Any protocol which uses CBC in a way which allows advance knowledge
of a message's IV (e.g., by using the last block of the preceding
message as the IV) might be vulnerable to this attack.
Preliminary analysis of this attack as applied to the SSH protocol
suggests that the protocol as implemented today is actually fairly
resistant to this attack. While estimates vary, on average, an
attacker would need tens or hundreds of millions of opportunities to
inject chosen plaintexts to be encrypted with a known IV to confirm
guesses on the value of a few unknown plaintexts.
While this attack involves less work than a brute-force attack on the
underlying cipher (and is thus a matter of some concern), it is also
likely to be significantly more difficult than attacks on other parts
of a system using the SSH protocol, and so is unlikely to be an
immediate risk to real-world systems. Due to this document's
recommendation that rekeying occur once an hour, an attacker also has
a limited amount of time to complete any particular attack.
Nevertheless, work is underway to specify, in a separate document or
Ylonen, et. al. Expires March 21, 2003 [Page 24]
Internet-Draft SSH Transport Layer Protocol September 2002
documents, additional cipher modes for the SSH protocol to address
this vulnerability. Implementors should be prepared to add new
algorithms to their implementations as this work progresses.
12. Intellectual Property
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 implementers or users of this specification can
be obtained from the IETF Secretariat.
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.
13. Additional Information
The current document editor is: Darren.Moffat@xxxxxxx. Comments on
this internet draft should be sent to the IETF SECSH working group,
details at: http://ietf.org/html.charters/secsh-charter.html
References
[FIPS-186] Federal Information Processing Standards Publication,
., "FIPS PUB 186, Digital Signature Standard", May
1994.
[Orm96] Orman, H., "The Okaley Key Determination Protcol
version1, TR97-92", 1996.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate
and CRL Profile", RFC 2459, January 1999.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, Nov 1987.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Ylonen, et. al. Expires March 21, 2003 [Page 25]
Internet-Draft SSH Transport Layer Protocol September 2002
Languages", RFC 1766, March 1995.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May
1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R.
Thayer, "OpenPGP Message Format", RFC 2440, November
1998.
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
Thomas, B. and T. Ylonen, "SPKI Certificate Theory",
RFC 2693, September 1999.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols algorithms and source in code in C", 1996.
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
[SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-
ietf-architecture-13.txt, September 2002.
[SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-15.txt, September 2002.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-
ietf-userauth-16.txt, September 2002.
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-
ietf-connect-16.txt, September 2002.
Ylonen, et. al. Expires March 21, 2003 [Page 26]
Internet-Draft SSH Transport Layer Protocol September 2002
Authors' Addresses
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: ylo@xxxxxxx
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: kivinen@xxxxxxx
Markku-Juhani O. Saarinen
University of Jyvaskyla
Timo J. Rinne
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: tri@xxxxxxx
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: sjl@xxxxxxx
Ylonen, et. al. Expires March 21, 2003 [Page 27]
Internet-Draft SSH Transport Layer Protocol September 2002
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 assigns.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ylonen, et. al. Expires March 21, 2003 [Page 28]
- Prev by Date: [Ethereal-dev] Can't catch traffic on already established TCP connections?
- Next by Date: [Ethereal-dev] Ethereal crashes after capturing traffic for some minutes...
- Previous by thread: Re: [Ethereal-dev] Can't catch traffic on already established TCP connections?
- Next by thread: [Ethereal-dev] Ethereal crashes after capturing traffic for some minutes...
- Index(es):
