draft-ietf-secsh-architecture-19.txt   draft-ietf-secsh-architecture-20.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 30, 2005 November 29, 2004 Expires: June 9, 2005 December 9, 2004
SSH Protocol Architecture SSH Protocol Architecture
draft-ietf-secsh-architecture-19.txt draft-ietf-secsh-architecture-20.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 34 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 30, 2005. This Internet-Draft will expire on June 9, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
SSH is a protocol for secure remote login and other secure network SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes the services over an insecure network. This document describes the
architecture of the SSH protocol, as well as the notation and architecture of the SSH protocol, as well as the notation and
skipping to change at page 8, line 51 skipping to change at page 8, line 51
characters. They are stored as a uint32 containing its length characters. They are stored as a uint32 containing its length
(number of bytes that follow) and zero (= empty string) or more (number of bytes that follow) and zero (= empty string) or more
bytes that are the value of the string. Terminating null bytes that are the value of the string. Terminating null
characters are not used. characters are not used.
Strings are also used to store text. In that case, US-ASCII is 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 used for internal names, and ISO-10646 UTF-8 for text that might
be displayed to the user. The terminating null character SHOULD be displayed to the user. The terminating null character SHOULD
NOT normally be stored in the string. For example: the US-ASCII NOT normally be stored in the string. For example: the US-ASCII
string "testing" is represented as 00 00 00 07 t e s t i n g. The 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. UTF-8 mapping does not alter the encoding of US-ASCII characters.
mpint mpint
Represents multiple precision integers in two's complement format, Represents multiple precision integers in two's complement format,
stored as a string, 8 bits per byte, MSB first. Negative numbers 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 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 the data partition. If the most significant bit would be set for
a positive number, the number MUST be preceded by a zero byte. a positive number, the number MUST be preceded by a zero byte.
Unnecessary leading bytes with the value 0 or 255 MUST NOT be Unnecessary leading bytes with the value 0 or 255 MUST NOT be
included. The value zero MUST be stored as a string with zero included. The value zero MUST be stored as a string with zero
skipping to change at page 9, line 33 skipping to change at page 9, line 33
9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
80 00 00 00 02 00 80 80 00 00 00 02 00 80
-1234 00 00 00 02 ed cc -1234 00 00 00 02 ed cc
-deadbeef 00 00 00 05 ff 21 52 41 11 -deadbeef 00 00 00 05 ff 21 52 41 11
name-list name-list
A string containing a comma-separated list of names. A 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 is represented as a uint32 containing its length (number of bytes
that follow) followed by a comma-separated list of zero or more 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 names. A name MUST have a non-zero length, and it MUST NOT
comma (","). Context may impose additional restrictions on the contain a comma (","). As this is a list of names, all of the
names; for example, the names in a name-list may have to be valid elements contained are names and MUST be in US-ASCII. Context may
algorithm identifier (see Section 6 below), or [RFC3066] language impose additional restrictions on the names. For example; the
tags. The order of the names in a name-list may or may not be names in a name-list may have to be a list of valid algorithm
identifiers (see Section 6 below), or a list of [RFC3066] language
tags. The order of the names in a name-list may, or may not be
significant. Again, this depends on the context where the list is significant. Again, this depends on the context where the list is
used. Terminating NUL characters are not used; neither for the used. Terminating null characters MUST NOT be used; neither for
individual names, nor for the list as a whole. the individual names, nor for the list as a whole.
Examples: Examples:
value representation (hex) value representation (hex)
----- -------------------- ----- --------------------
(), the empty name-list 00 00 00 00 (), the empty name-list 00 00 00 00
("zlib") 00 00 00 04 7a 6c 69 62 ("zlib") 00 00 00 04 7a 6c 69 62
("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 ("zlib,none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
6. Algorithm and Method Naming 6. Algorithm and Method Naming
The SSH protocols refer to particular hash, encryption, integrity, The SSH protocols refer to particular hash, encryption, integrity,
compression, and key exchange algorithms or methods by names. There compression, and key exchange algorithms or methods by names. There
are some standard algorithms and methods that all implementations are some standard algorithms and methods that all implementations
MUST support. There are also algorithms and methods that are defined MUST support. There are also algorithms and methods that are defined
in the protocol specification but are OPTIONAL. Furthermore, it is in the protocol specification but are OPTIONAL. Furthermore, it is
expected that some organizations will want to use their own expected that some organizations will want to use their own
algorithms or methods. algorithms or methods.
skipping to change at page 16, line 42 skipping to change at page 16, line 42
Because MACs use a 32 bit sequence number, they might start to leak Because MACs use a 32 bit sequence number, they might start to leak
information after 2**32 packets have been sent. However, following information after 2**32 packets have been sent. However, following
the rekeying recommendations should prevent this attack. The the rekeying recommendations should prevent this attack. The
transport protocol [SSH-TRANS] recommends rekeying after one gigabyte transport protocol [SSH-TRANS] recommends rekeying after one gigabyte
of data, and the smallest possible packet is 16 bytes. Therefore, of data, and the smallest possible packet is 16 bytes. Therefore,
rekeying SHOULD happen after 2**28 packets at the very most. rekeying SHOULD happen after 2**28 packets at the very most.
9.2.3 Replay 9.2.3 Replay
The use of a MAC other than 'none' provides integrity and The use of a MAC other than "none" provides integrity and
authentication. In addition, the transport protocol provides a authentication. In addition, the transport protocol provides a
unique session identifier (bound in part to pseudo-random data that unique session identifier (bound in part to pseudo-random data that
is part of the algorithm and key exchange process) that can be used is part of the algorithm and key exchange process) that can be used
by higher level protocols to bind data to a given session and prevent by higher level protocols to bind data to a given session and prevent
replay of data from prior sessions. For example: the authentication replay of data from prior sessions. For example: the authentication
protocol uses this to prevent replay of signatures from previous protocol uses this to prevent replay of signatures from previous
sessions. Because public key authentication exchanges are sessions. Because public key authentication exchanges are
cryptographically bound to the session (i.e., to the initial key cryptographically bound to the session (i.e., to the initial key
exchange) they cannot be successfully replayed in other sessions. exchange) they cannot be successfully replayed in other sessions.
Note that the session ID can be made public without harming the Note that the session ID can be made public without harming the
skipping to change at page 25, line 11 skipping to change at page 25, line 11
magic cookie access checking spoofing mechanism as described in magic cookie access checking spoofing mechanism as described in
[SSH-CONNECT] as an additional mechanism to prevent unauthorized use [SSH-CONNECT] as an additional mechanism to prevent unauthorized use
of the proxy. of the proxy.
10. References 10. References
10.1 Normative References 10.1 Normative References
[SSH-TRANS] [SSH-TRANS]
Lonvick, C., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-21.txt, November 2004. draft-ietf-secsh-transport-22.txt, December 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Lonvick, C., "SSH Authentication Protocol", I-D Lonvick, C., "SSH Authentication Protocol", I-D
draft-ietf-userauth-24.txt, November 2004. draft-ietf-secsh-userauth-25.txt, December 2004.
[SSH-CONNECT] [SSH-CONNECT]
Lonvick, C., "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol", I-D
draft-ietf-connect-22.txt, November 2004. draft-ietf-secsh-connect-23.txt, December 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", I-D Lonvick, C., "SSH Protocol Assigned Numbers", I-D
draft-ietf-assignednumbers-09.txt, November 2004. draft-ietf-secsh-assignednumbers-10.txt, December 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of [RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. Languages", BCP 47, RFC 3066, January 2001.
 End of changes. 

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