mina-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gno...@apache.org
Subject svn commit: r723396 [6/12] - in /mina/sshd/trunk: ./ src/ src/docs/ src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/ src/main/filtered-resources/org/apache/ src/main/filtered-resources/org/apache/sshd/ src/main/java/ src/main/jav...
Date Thu, 04 Dec 2008 18:59:36 GMT
Added: mina/sshd/trunk/src/docs/rfc4254.txt
URL: http://svn.apache.org/viewvc/mina/sshd/trunk/src/docs/rfc4254.txt?rev=723396&view=auto
==============================================================================
--- mina/sshd/trunk/src/docs/rfc4254.txt (added)
+++ mina/sshd/trunk/src/docs/rfc4254.txt Thu Dec  4 10:59:31 2008
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                          T. Ylonen
+Request for Comments: 4254              SSH Communications Security Corp
+Category: Standards Track                                C. Lonvick, Ed.
+                                                     Cisco Systems, Inc.
+                                                            January 2006
+
+
+               The Secure Shell (SSH) Connection Protocol
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Secure Shell (SSH) is a protocol for secure remote login and other
+   secure network services over an insecure network.
+
+   This document describes the SSH Connection Protocol.  It provides
+   interactive login sessions, remote execution of commands, forwarded
+   TCP/IP connections, and forwarded X11 connections.  All of these
+   channels are multiplexed into a single encrypted tunnel.
+
+   The SSH Connection Protocol has been designed to run on top of the
+   SSH transport layer and user authentication protocols.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 1]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Contributors ....................................................3
+   3. Conventions Used in This Document ...............................3
+   4. Global Requests .................................................4
+   5. Channel Mechanism ...............................................5
+      5.1. Opening a Channel ..........................................5
+      5.2. Data Transfer ..............................................7
+      5.3. Closing a Channel ..........................................9
+      5.4. Channel-Specific Requests ..................................9
+   6. Interactive Sessions ...........................................10
+      6.1. Opening a Session .........................................10
+      6.2. Requesting a Pseudo-Terminal ..............................11
+      6.3. X11 Forwarding ............................................11
+           6.3.1. Requesting X11 Forwarding ..........................11
+           6.3.2. X11 Channels .......................................12
+      6.4. Environment Variable Passing ..............................12
+      6.5. Starting a Shell or a Command .............................13
+      6.6. Session Data Transfer .....................................14
+      6.7. Window Dimension Change Message ...........................14
+      6.8. Local Flow Control ........................................14
+      6.9. Signals ...................................................15
+      6.10. Returning Exit Status ....................................15
+   7. TCP/IP Port Forwarding .........................................16
+      7.1. Requesting Port Forwarding ................................16
+      7.2. TCP/IP Forwarding Channels ................................18
+   8. Encoding of Terminal Modes .....................................19
+   9. Summary of Message Numbers .....................................21
+   10. IANA Considerations ...........................................21
+   11. Security Considerations .......................................21
+   12. References ....................................................22
+      12.1. Normative References .....................................22
+      12.2. Informative References ...................................22
+   Authors' Addresses ................................................23
+   Trademark Notice ..................................................23
+
+1.  Introduction
+
+   The SSH Connection Protocol has been designed to run on top of the
+   SSH transport layer and user authentication protocols ([SSH-TRANS]
+   and [SSH-USERAUTH]).  It provides interactive login sessions, remote
+   execution of commands, forwarded TCP/IP connections, and forwarded
+   X11 connections.
+
+   The 'service name' for this protocol is "ssh-connection".
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 2]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   This document should be read only after reading the SSH architecture
+   document [SSH-ARCH].  This document freely uses terminology and
+   notation from the architecture document without reference or further
+   explanation.
+
+2.  Contributors
+
+   The major original contributors of this set of documents have been:
+   Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
+   Communications Security Corp), and Markku-Juhani O. Saarinen
+   (University of Jyvaskyla).  Darren Moffat was the original editor of
+   this set of documents and also made very substantial contributions.
+
+   Many people contributed to the development of this document over the
+   years.  People who should be acknowledged include Mats Andersson, Ben
+   Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller,
+   Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff
+   Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph
+   Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas
+   Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon
+   Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and
+   Tadayoshi Kohno.  Listing their names here does not mean that they
+   endorse this document, but that they have contributed to it.
+
+3.  Conventions Used in This Document
+
+   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.  These keywords are to be interpreted as described in
+   [RFC2119].
+
+   The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
+   FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
+   APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
+   this document when used to describe namespace allocation are to be
+   interpreted as described in [RFC2434].
+
+   Protocol fields and possible values to fill them are defined in this
+   set of documents.  Protocol fields will be defined in the message
+   definitions.  As an example, SSH_MSG_CHANNEL_DATA is defined as
+   follows.
+
+      byte      SSH_MSG_CHANNEL_DATA
+      uint32    recipient channel
+      string    data
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 3]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   Throughout these documents, when the fields are referenced, they will
+   appear within single quotes.  When values to fill those fields are
+   referenced, they will appear within double quotes.  Using the above
+   example, possible values for 'data' are "foo" and "bar".
+
+4.  Global Requests
+
+   There are several kinds of requests that affect the state of the
+   remote end globally, independent of any channels.  An example is a
+   request to start TCP/IP forwarding for a specific port.  Note that
+   both the client and server MAY send global requests at any time, and
+   the receiver MUST respond appropriately.  All such requests use the
+   following format.
+
+      byte      SSH_MSG_GLOBAL_REQUEST
+      string    request name in US-ASCII only
+      boolean   want reply
+      ....      request-specific data follows
+
+   The value of 'request name' follows the DNS extensibility naming
+   convention outlined in [SSH-ARCH].
+
+   The recipient will respond to this message with
+   SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is
+   TRUE.
+
+      byte      SSH_MSG_REQUEST_SUCCESS
+      ....     response specific data
+
+   Usually, the 'response specific data' is non-existent.
+
+   If the recipient does not recognize or support the request, it simply
+   responds with SSH_MSG_REQUEST_FAILURE.
+
+      byte      SSH_MSG_REQUEST_FAILURE
+
+   In general, the reply messages do not include request type
+   identifiers.  To make it possible for the originator of a request to
+   identify to which request each reply refers, it is REQUIRED that
+   replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as
+   the corresponding request messages.  For channel requests, replies
+   that relate to the same channel MUST also be replied to in the right
+   order.  However, channel requests for distinct channels MAY be
+   replied to out-of-order.
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 4]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+5.  Channel Mechanism
+
+   All terminal sessions, forwarded connections, etc., are channels.
+   Either side may open a channel.  Multiple channels are multiplexed
+   into a single connection.
+
+   Channels are identified by numbers at each end.  The number referring
+   to a channel may be different on each side.  Requests to open a
+   channel contain the sender's channel number.  Any other channel-
+   related messages contain the recipient's channel number for the
+   channel.
+
+   Channels are flow-controlled.  No data may be sent to a channel until
+   a message is received to indicate that window space is available.
+
+5.1.  Opening a Channel
+
+   When either side wishes to open a new channel, it allocates a local
+   number for the channel.  It then sends the following message to the
+   other side, and includes the local channel number and initial window
+   size in the message.
+
+      byte      SSH_MSG_CHANNEL_OPEN
+      string    channel type in US-ASCII only
+      uint32    sender channel
+      uint32    initial window size
+      uint32    maximum packet size
+      ....      channel type specific data follows
+
+   The 'channel type' is a name, as described in [SSH-ARCH] and
+   [SSH-NUMBERS], with similar extension mechanisms.  The 'sender
+   channel' is a local identifier for the channel used by the sender of
+   this message.  The 'initial window size' specifies how many bytes of
+   channel data can be sent to the sender of this message without
+   adjusting the window.  The 'maximum packet size' specifies the
+   maximum size of an individual data packet that can be sent to the
+   sender.  For example, one might want to use smaller packets for
+   interactive connections to get better interactive response on slow
+   links.
+
+   The remote side then decides whether it can open the channel, and
+   responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
+   SSH_MSG_CHANNEL_OPEN_FAILURE.
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 5]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+      byte      SSH_MSG_CHANNEL_OPEN_CONFIRMATION
+      uint32    recipient channel
+      uint32    sender channel
+      uint32    initial window size
+      uint32    maximum packet size
+      ....      channel type specific data follows
+
+   The 'recipient channel' is the channel number given in the original
+   open request, and 'sender channel' is the channel number allocated by
+   the other side.
+
+      byte      SSH_MSG_CHANNEL_OPEN_FAILURE
+      uint32    recipient channel
+      uint32    reason code
+      string    description in ISO-10646 UTF-8 encoding [RFC3629]
+      string    language tag [RFC3066]
+
+   If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support
+   the specified 'channel type', it simply responds with
+   SSH_MSG_CHANNEL_OPEN_FAILURE.  The client MAY show the 'description'
+   string to the user.  If this is done, the client software should take
+   the precautions discussed in [SSH-ARCH].
+
+   The SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values are defined in
+   the following table.  Note that the values for the 'reason code' are
+   given in decimal format for readability, but they are actually uint32
+   values.
+
+             Symbolic name                           reason code
+             -------------                           -----------
+            SSH_OPEN_ADMINISTRATIVELY_PROHIBITED          1
+            SSH_OPEN_CONNECT_FAILED                       2
+            SSH_OPEN_UNKNOWN_CHANNEL_TYPE                 3
+            SSH_OPEN_RESOURCE_SHORTAGE                    4
+
+   Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'
+   values (and associated 'description' text) in the range of 0x00000005
+   to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
+   described in [RFC2434].  The IANA will not assign Channel Connection
+   Failure 'reason code' values in the range of 0xFE000000 to
+   0xFFFFFFFF.  Channel Connection Failure 'reason code' values in that
+   range are left for PRIVATE USE, as described in [RFC2434].
+
+   While it is understood that the IANA will have no control over the
+   range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two
+   parts and administered by the following conventions.
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 6]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   o  The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction
+      with locally assigned channels.  For example, if a channel is
+      proposed with a 'channel type' of "example_session@example.com",
+      but fails, then the response will contain either a 'reason code'
+      assigned by the IANA (as listed above and in the range of
+      0x00000001 to 0xFDFFFFFF) or a locally assigned value in the range
+      of 0xFE000000 to 0xFEFFFFFF.  Naturally, if the server does not
+      understand the proposed 'channel type', even if it is a locally
+      defined 'channel type', then the 'reason code' MUST be 0x00000003,
+      as described above, if the 'reason code' is sent.  If the server
+      does understand the 'channel type', but the channel still fails to
+      open, then the server SHOULD respond with a locally assigned
+      'reason code' value consistent with the proposed, local 'channel
+      type'.  It is assumed that practitioners will first attempt to use
+      the IANA assigned 'reason code' values and then document their
+      locally assigned 'reason code' values.
+
+   o  There are no restrictions or suggestions for the range starting
+      with 0xFF.  No interoperability is expected for anything used in
+      this range.  Essentially, it is for experimentation.
+
+5.2.  Data Transfer
+
+   The window size specifies how many bytes the other party can send
+   before it must wait for the window to be adjusted.  Both parties use
+   the following message to adjust the window.
+
+      byte      SSH_MSG_CHANNEL_WINDOW_ADJUST
+      uint32    recipient channel
+      uint32    bytes to add
+
+   After receiving this message, the recipient MAY send the given number
+   of bytes more than it was previously allowed to send; the window size
+   is incremented.  Implementations MUST correctly handle window sizes
+   of up to 2^32 - 1 bytes.  The window MUST NOT be increased above
+   2^32 - 1 bytes.
+
+   Data transfer is done with messages of the following type.
+
+      byte      SSH_MSG_CHANNEL_DATA
+      uint32    recipient channel
+      string    data
+
+   The maximum amount of data allowed is determined by the maximum
+   packet size for the channel, and the current window size, whichever
+   is smaller.  The window size is decremented by the amount of data
+   sent.  Both parties MAY ignore all extra data sent after the allowed
+   window is empty.
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 7]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   Implementations are expected to have some limit on the SSH transport
+   layer packet size (any limit for received packets MUST be 32768 bytes
+   or larger, as described in [SSH-TRANS]).  The implementation of the
+   SSH connection layer
+
+   o  MUST NOT advertise a maximum packet size that would result in
+      transport packets larger than its transport layer is willing to
+      receive.
+
+   o  MUST NOT generate data packets larger than its transport layer is
+      willing to send, even if the remote end would be willing to accept
+      very large packets.
+
+   Additionally, some channels can transfer several types of data.  An
+   example of this is stderr data from interactive sessions.  Such data
+   can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a
+   separate integer specifies the type of data.  The available types and
+   their interpretation depend on the type of channel.
+
+      byte      SSH_MSG_CHANNEL_EXTENDED_DATA
+      uint32    recipient channel
+      uint32    data_type_code
+      string    data
+
+   Data sent with these messages consumes the same window as ordinary
+   data.
+
+   Currently, only the following type is defined.  Note that the value
+   for the 'data_type_code' is given in decimal format for readability,
+   but the values are actually uint32 values.
+
+               Symbolic name                  data_type_code
+               -------------                  --------------
+             SSH_EXTENDED_DATA_STDERR               1
+
+   Extended Channel Data Transfer 'data_type_code' values MUST be
+   assigned sequentially.  Requests for assignments of new Extended
+   Channel Data Transfer 'data_type_code' values and their associated
+   Extended Channel Data Transfer 'data' strings, in the range of
+   0x00000002 to 0xFDFFFFFF, MUST be done through the IETF CONSENSUS
+   method as described in [RFC2434].  The IANA will not assign Extended
+   Channel Data Transfer 'data_type_code' values in the range of
+   0xFE000000 to 0xFFFFFFFF.  Extended Channel Data Transfer
+   'data_type_code' values in that range are left for PRIVATE USE, as
+   described in [RFC2434].  As is noted, the actual instructions to the
+   IANA are in [SSH-NUMBERS].
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 8]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+5.3.  Closing a Channel
+
+   When a party will no longer send more data to a channel, it SHOULD
+   send SSH_MSG_CHANNEL_EOF.
+
+      byte      SSH_MSG_CHANNEL_EOF
+      uint32    recipient channel
+
+   No explicit response is sent to this message.  However, the
+   application may send EOF to whatever is at the other end of the
+   channel.  Note that the channel remains open after this message, and
+   more data may still be sent in the other direction.  This message
+   does not consume window space and can be sent even if no window space
+   is available.
+
+   When either party wishes to terminate the channel, it sends
+   SSH_MSG_CHANNEL_CLOSE.  Upon receiving this message, a party MUST
+   send back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this
+   message for the channel.  The channel is considered closed for a
+   party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and
+   the party may then reuse the channel number.  A party MAY send
+   SSH_MSG_CHANNEL_CLOSE without having sent or received
+   SSH_MSG_CHANNEL_EOF.
+
+      byte      SSH_MSG_CHANNEL_CLOSE
+      uint32    recipient channel
+
+   This message does not consume window space and can be sent even if no
+   window space is available.
+
+   It is RECOMMENDED that all data sent before this message be delivered
+   to the actual destination, if possible.
+
+5.4.  Channel-Specific Requests
+
+   Many 'channel type' values have extensions that are specific to that
+   particular 'channel type'.  An example is requesting a pty (pseudo
+   terminal) for an interactive session.
+
+   All channel-specific requests use the following format.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    request type in US-ASCII characters only
+      boolean   want reply
+      ....      type-specific data follows
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 9]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   If 'want reply' is FALSE, no response will be sent to the request.
+   Otherwise, the recipient responds with either
+   SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or request-specific
+   continuation messages.  If the request is not recognized or is not
+   supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.
+
+   This message does not consume window space and can be sent even if no
+   window space is available.  The values of 'request type' are local to
+   each channel type.
+
+   The client is allowed to send further messages without waiting for
+   the response to the request.
+
+   'request type' names follow the DNS extensibility naming convention
+   outlined in [SSH-ARCH] and [SSH-NUMBERS].
+
+      byte      SSH_MSG_CHANNEL_SUCCESS
+      uint32    recipient channel
+
+
+      byte      SSH_MSG_CHANNEL_FAILURE
+      uint32    recipient channel
+
+   These messages do not consume window space and can be sent even if no
+   window space is available.
+
+6.  Interactive Sessions
+
+   A session is a remote execution of a program.  The program may be a
+   shell, an application, a system command, or some built-in subsystem.
+   It may or may not have a tty, and may or may not involve X11
+   forwarding.  Multiple sessions can be active simultaneously.
+
+6.1.  Opening a Session
+
+   A session is started by sending the following message.
+
+      byte      SSH_MSG_CHANNEL_OPEN
+      string    "session"
+      uint32    sender channel
+      uint32    initial window size
+      uint32    maximum packet size
+
+   Client implementations SHOULD reject any session channel open
+   requests to make it more difficult for a corrupt server to attack the
+   client.
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 10]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+6.2.  Requesting a Pseudo-Terminal
+
+   A pseudo-terminal can be allocated for the session by sending the
+   following message.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "pty-req"
+      boolean   want_reply
+      string    TERM environment variable value (e.g., vt100)
+      uint32    terminal width, characters (e.g., 80)
+      uint32    terminal height, rows (e.g., 24)
+      uint32    terminal width, pixels (e.g., 640)
+      uint32    terminal height, pixels (e.g., 480)
+      string    encoded terminal modes
+
+   The 'encoded terminal modes' are described in Section 8.  Zero
+   dimension parameters MUST be ignored.  The character/row dimensions
+   override the pixel dimensions (when nonzero).  Pixel dimensions refer
+   to the drawable area of the window.
+
+   The dimension parameters are only informational.
+
+   The client SHOULD ignore pty requests.
+
+6.3.  X11 Forwarding
+
+6.3.1.  Requesting X11 Forwarding
+
+   X11 forwarding may be requested for a session by sending a
+   SSH_MSG_CHANNEL_REQUEST message.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "x11-req"
+      boolean   want reply
+      boolean   single connection
+      string    x11 authentication protocol
+      string    x11 authentication cookie
+      uint32    x11 screen number
+
+   It is RECOMMENDED that the 'x11 authentication cookie' that is sent
+   be a fake, random cookie, and that the cookie be checked and replaced
+   by the real cookie when a connection request is received.
+
+   X11 connection forwarding should stop when the session channel is
+   closed.  However, already opened forwardings should not be
+   automatically closed when the session channel is closed.
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 11]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   If 'single connection' is TRUE, only a single connection should be
+   forwarded.  No more connections will be forwarded after the first, or
+   after the session channel has been closed.
+
+   The 'x11 authentication protocol' is the name of the X11
+   authentication method used, e.g., "MIT-MAGIC-COOKIE-1".
+
+   The 'x11 authentication cookie' MUST be hexadecimal encoded.
+
+   The X Protocol is documented in [SCHEIFLER].
+
+6.3.2.  X11 Channels
+
+   X11 channels are opened with a channel open request.  The resulting
+   channels are independent of the session, and closing the session
+   channel does not close the forwarded X11 channels.
+
+      byte      SSH_MSG_CHANNEL_OPEN
+      string    "x11"
+      uint32    sender channel
+      uint32    initial window size
+      uint32    maximum packet size
+      string    originator address (e.g., "192.168.7.38")
+      uint32    originator port
+
+   The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION
+   or SSH_MSG_CHANNEL_OPEN_FAILURE.
+
+   Implementations MUST reject any X11 channel open requests if they
+   have not requested X11 forwarding.
+
+6.4.  Environment Variable Passing
+
+   Environment variables may be passed to the shell/command to be
+   started later.  Uncontrolled setting of environment variables in a
+   privileged process can be a security hazard.  It is recommended that
+   implementations either maintain a list of allowable variable names or
+   only set environment variables after the server process has dropped
+   sufficient privileges.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "env"
+      boolean   want reply
+      string    variable name
+      string    variable value
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 12]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+6.5.  Starting a Shell or a Command
+
+   Once the session has been set up, a program is started at the remote
+   end.  The program can be a shell, an application program, or a
+   subsystem with a host-independent name.  Only one of these requests
+   can succeed per channel.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "shell"
+      boolean   want reply
+
+   This message will request that the user's default shell (typically
+   defined in /etc/passwd in UNIX systems) be started at the other end.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "exec"
+      boolean   want reply
+      string    command
+
+   This message will request that the server start the execution of the
+   given command.  The 'command' string may contain a path.  Normal
+   precautions MUST be taken to prevent the execution of unauthorized
+   commands.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "subsystem"
+      boolean   want reply
+      string    subsystem name
+
+   This last form executes a predefined subsystem.  It is expected that
+   these will include a general file transfer mechanism, and possibly
+   other features.  Implementations may also allow configuring more such
+   mechanisms.  As the user's shell is usually used to execute the
+   subsystem, it is advisable for the subsystem protocol to have a
+   "magic cookie" at the beginning of the protocol transaction to
+   distinguish it from arbitrary output generated by shell
+   initialization scripts, etc.  This spurious output from the shell may
+   be filtered out either at the server or at the client.
+
+   The server SHOULD NOT halt the execution of the protocol stack when
+   starting a shell or a program.  All input and output from these
+   SHOULD be redirected to the channel or to the encrypted tunnel.
+
+   It is RECOMMENDED that the reply to these messages be requested and
+   checked.  The client SHOULD ignore these messages.
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 13]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   Subsystem names follow the DNS extensibility naming convention
+   outlined in [SSH-NUMBERS].
+
+6.6.  Session Data Transfer
+
+   Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and
+   SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism.  The
+   extended data type SSH_EXTENDED_DATA_STDERR has been defined for
+   stderr data.
+
+6.7.  Window Dimension Change Message
+
+   When the window (terminal) size changes on the client side, it MAY
+   send a message to the other side to inform it of the new dimensions.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "window-change"
+      boolean   FALSE
+      uint32    terminal width, columns
+      uint32    terminal height, rows
+      uint32    terminal width, pixels
+      uint32    terminal height, pixels
+
+   A response SHOULD NOT be sent to this message.
+
+6.8.  Local Flow Control
+
+   On many systems, it is possible to determine if a pseudo-terminal is
+   using control-S/control-Q flow control.  When flow control is
+   allowed, it is often desirable to do the flow control at the client
+   end to speed up responses to user requests.  This is facilitated by
+   the following notification.  Initially, the server is responsible for
+   flow control.  (Here, again, client means the side originating the
+   session, and server means the other side.)
+
+   The message below is used by the server to inform the client when it
+   can or cannot perform flow control (control-S/control-Q processing).
+   If 'client can do' is TRUE, the client is allowed to do flow control
+   using control-S and control-Q.  The client MAY ignore this message.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "xon-xoff"
+      boolean   FALSE
+      boolean   client can do
+
+   No response is sent to this message.
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 14]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+6.9.  Signals
+
+   A signal can be delivered to the remote process/service using the
+   following message.  Some systems may not implement signals, in which
+   case they SHOULD ignore this message.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "signal"
+      boolean   FALSE
+      string    signal name (without the "SIG" prefix)
+
+   'signal name' values will be encoded as discussed in the passage
+   describing SSH_MSG_CHANNEL_REQUEST messages using "exit-signal" in
+   this section.
+
+6.10.  Returning Exit Status
+
+   When the command running at the other end terminates, the following
+   message can be sent to return the exit status of the command.
+   Returning the status is RECOMMENDED.  No acknowledgement is sent for
+   this message.  The channel needs to be closed with
+   SSH_MSG_CHANNEL_CLOSE after this message.
+
+   The client MAY ignore these messages.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "exit-status"
+      boolean   FALSE
+      uint32    exit_status
+
+   The remote command may also terminate violently due to a signal.
+   Such a condition can be indicated by the following message.  A zero
+   'exit_status' usually means that the command terminated successfully.
+
+      byte      SSH_MSG_CHANNEL_REQUEST
+      uint32    recipient channel
+      string    "exit-signal"
+      boolean   FALSE
+      string    signal name (without the "SIG" prefix)
+      boolean   core dumped
+      string    error message in ISO-10646 UTF-8 encoding
+      string    language tag [RFC3066]
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 15]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   The 'signal name' is one of the following (these are from [POSIX]).
+
+            ABRT
+            ALRM
+            FPE
+            HUP
+            ILL
+            INT
+            KILL
+            PIPE
+            QUIT
+            SEGV
+            TERM
+            USR1
+            USR2
+
+   Additional 'signal name' values MAY be sent in the format
+   "sig-name@xyz", where "sig-name" and "xyz" may be anything a
+   particular implementer wants (except the "@" sign).  However, it is
+   suggested that if a 'configure' script is used, any non-standard
+   'signal name' values it finds be encoded as "SIG@xyz.config.guess",
+   where "SIG" is the 'signal name' without the "SIG" prefix, and "xyz"
+   is the host type, as determined by "config.guess".
+
+   The 'error message' contains an additional textual explanation of the
+   error message.  The message may consist of multiple lines separated
+   by CRLF (Carriage Return - Line Feed) pairs.  The client software MAY
+   display this message to the user.  If this is done, the client
+   software should take the precautions discussed in [SSH-ARCH].
+
+7.  TCP/IP Port Forwarding
+
+7.1.  Requesting Port Forwarding
+
+   A party need not explicitly request forwardings from its own end to
+   the other direction.  However, if it wishes that connections to a
+   port on the other side be forwarded to the local side, it must
+   explicitly request this.
+
+      byte      SSH_MSG_GLOBAL_REQUEST
+      string    "tcpip-forward"
+      boolean   want reply
+      string    address to bind (e.g., "0.0.0.0")
+      uint32    port number to bind
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 16]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   The 'address to bind' and 'port number to bind' specify the IP
+   address (or domain name) and port on which connections for forwarding
+   are to be accepted.  Some strings used for 'address to bind' have
+   special-case semantics.
+
+   o  "" means that connections are to be accepted on all protocol
+      families supported by the SSH implementation.
+
+   o  "0.0.0.0" means to listen on all IPv4 addresses.
+
+   o  "::" means to listen on all IPv6 addresses.
+
+   o  "localhost" means to listen on all protocol families supported by
+      the SSH implementation on loopback addresses only ([RFC3330] and
+      [RFC3513]).
+
+   o  "127.0.0.1" and "::1" indicate listening on the loopback
+      interfaces for IPv4 and IPv6, respectively.
+
+   Note that the client can still filter connections based on
+   information passed in the open request.
+
+   Implementations should only allow forwarding privileged ports if the
+   user has been authenticated as a privileged user.
+
+   Client implementations SHOULD reject these messages; they are
+   normally only sent by the client.
+
+   If a client passes 0 as port number to bind and has 'want reply' as
+   TRUE, then the server allocates the next available unprivileged port
+   number and replies with the following message; otherwise, there is no
+   response-specific data.
+
+      byte     SSH_MSG_REQUEST_SUCCESS
+      uint32   port that was bound on the server
+
+   A port forwarding can be canceled with the following message.  Note
+   that channel open requests may be received until a reply to this
+   message is received.
+
+      byte      SSH_MSG_GLOBAL_REQUEST
+      string    "cancel-tcpip-forward"
+      boolean   want reply
+      string    address_to_bind (e.g., "127.0.0.1")
+      uint32    port number to bind
+
+   Client implementations SHOULD reject these messages; they are
+   normally only sent by the client.
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 17]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+7.2.  TCP/IP Forwarding Channels
+
+   When a connection comes to a port for which remote forwarding has
+   been requested, a channel is opened to forward the port to the other
+   side.
+
+      byte      SSH_MSG_CHANNEL_OPEN
+      string    "forwarded-tcpip"
+      uint32    sender channel
+      uint32    initial window size
+      uint32    maximum packet size
+      string    address that was connected
+      uint32    port that was connected
+      string    originator IP address
+      uint32    originator port
+
+   Implementations MUST reject these messages unless they have
+   previously requested a remote TCP/IP port forwarding with the given
+   port number.
+
+   When a connection comes to a locally forwarded TCP/IP port, the
+   following packet is sent to the other side.  Note that these messages
+   MAY also be sent for ports for which no forwarding has been
+   explicitly requested.  The receiving side must decide whether to
+   allow the forwarding.
+
+      byte      SSH_MSG_CHANNEL_OPEN
+      string    "direct-tcpip"
+      uint32    sender channel
+      uint32    initial window size
+      uint32    maximum packet size
+      string    host to connect
+      uint32    port to connect
+      string    originator IP address
+      uint32    originator port
+
+   The 'host to connect' and 'port to connect' specify the TCP/IP host
+   and port where the recipient should connect the channel.  The 'host
+   to connect' may be either a domain name or a numeric IP address.
+
+   The 'originator IP address' is the numeric IP address of the machine
+   from where the connection request originates, and the 'originator
+   port' is the port on the host from where the connection originated.
+
+   Forwarded TCP/IP channels are independent of any sessions, and
+   closing a session channel does not in any way imply that forwarded
+   connections should be closed.
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 18]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   Client implementations SHOULD reject direct TCP/IP open requests for
+   security reasons.
+
+8.  Encoding of Terminal Modes
+
+   All 'encoded terminal modes' (as passed in a pty request) are encoded
+   into a byte stream.  It is intended that the coding be portable
+   across different environments.  The stream consists of opcode-
+   argument pairs wherein the opcode is a byte value.  Opcodes 1 to 159
+   have a single uint32 argument.  Opcodes 160 to 255 are not yet
+   defined, and cause parsing to stop (they should only be used after
+   any other data).  The stream is terminated by opcode TTY_OP_END
+   (0x00).
+
+   The client SHOULD put any modes it knows about in the stream, and the
+   server MAY ignore any modes it does not know about.  This allows some
+   degree of machine-independence, at least between systems that use a
+   POSIX-like tty interface.  The protocol can support other systems as
+   well, but the client may need to fill reasonable values for a number
+   of parameters so the server pty gets set to a reasonable mode (the
+   server leaves all unspecified mode bits in their default values, and
+   only some combinations make sense).
+
+   The naming of opcode values mostly follows the POSIX terminal mode
+   flags.  The following opcode values have been defined.  Note that the
+   values given below are in decimal format for readability, but they
+   are actually byte values.
+
+          opcode  mnemonic       description
+          ------  --------       -----------
+          0     TTY_OP_END  Indicates end of options.
+          1     VINTR       Interrupt character; 255 if none.  Similarly
+                             for the other characters.  Not all of these
+                             characters are supported on all systems.
+          2     VQUIT       The quit character (sends SIGQUIT signal on
+                             POSIX systems).
+          3     VERASE      Erase the character to left of the cursor.
+          4     VKILL       Kill the current input line.
+          5     VEOF        End-of-file character (sends EOF from the
+                             terminal).
+          6     VEOL        End-of-line character in addition to
+                             carriage return and/or linefeed.
+          7     VEOL2       Additional end-of-line character.
+          8     VSTART      Continues paused output (normally
+                             control-Q).
+          9     VSTOP       Pauses output (normally control-S).
+          10    VSUSP       Suspends the current program.
+          11    VDSUSP      Another suspend character.
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 19]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+          12    VREPRINT    Reprints the current input line.
+          13    VWERASE     Erases a word left of cursor.
+          14    VLNEXT      Enter the next character typed literally,
+                             even if it is a special character
+          15    VFLUSH      Character to flush output.
+          16    VSWTCH      Switch to a different shell layer.
+          17    VSTATUS     Prints system status line (load, command,
+                             pid, etc).
+          18    VDISCARD    Toggles the flushing of terminal output.
+          30    IGNPAR      The ignore parity flag.  The parameter
+                             SHOULD be 0 if this flag is FALSE,
+                             and 1 if it is TRUE.
+          31    PARMRK      Mark parity and framing errors.
+          32    INPCK       Enable checking of parity errors.
+          33    ISTRIP      Strip 8th bit off characters.
+          34    INLCR       Map NL into CR on input.
+          35    IGNCR       Ignore CR on input.
+          36    ICRNL       Map CR to NL on input.
+          37    IUCLC       Translate uppercase characters to
+                             lowercase.
+          38    IXON        Enable output flow control.
+          39    IXANY       Any char will restart after stop.
+          40    IXOFF       Enable input flow control.
+          41    IMAXBEL     Ring bell on input queue full.
+          50    ISIG        Enable signals INTR, QUIT, [D]SUSP.
+          51    ICANON      Canonicalize input lines.
+          52    XCASE       Enable input and output of uppercase
+                             characters by preceding their lowercase
+                             equivalents with "\".
+          53    ECHO        Enable echoing.
+          54    ECHOE       Visually erase chars.
+          55    ECHOK       Kill character discards current line.
+          56    ECHONL      Echo NL even if ECHO is off.
+          57    NOFLSH      Don't flush after interrupt.
+          58    TOSTOP      Stop background jobs from output.
+          59    IEXTEN      Enable extensions.
+          60    ECHOCTL     Echo control characters as ^(Char).
+          61    ECHOKE      Visual erase for line kill.
+          62    PENDIN      Retype pending input.
+          70    OPOST       Enable output processing.
+          71    OLCUC       Convert lowercase to uppercase.
+          72    ONLCR       Map NL to CR-NL.
+          73    OCRNL       Translate carriage return to newline
+                             (output).
+          74    ONOCR       Translate newline to carriage
+                             return-newline (output).
+          75    ONLRET      Newline performs a carriage return
+                             (output).
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 20]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+          90    CS7         7 bit mode.
+          91    CS8         8 bit mode.
+          92    PARENB      Parity enable.
+          93    PARODD      Odd parity, else even.
+
+          128 TTY_OP_ISPEED  Specifies the input baud rate in
+                              bits per second.
+          129 TTY_OP_OSPEED  Specifies the output baud rate in
+                              bits per second.
+
+9.  Summary of Message Numbers
+
+   The following is a summary of messages and their associated message
+   number.
+
+            SSH_MSG_GLOBAL_REQUEST                  80
+            SSH_MSG_REQUEST_SUCCESS                 81
+            SSH_MSG_REQUEST_FAILURE                 82
+            SSH_MSG_CHANNEL_OPEN                    90
+            SSH_MSG_CHANNEL_OPEN_CONFIRMATION       91
+            SSH_MSG_CHANNEL_OPEN_FAILURE            92
+            SSH_MSG_CHANNEL_WINDOW_ADJUST           93
+            SSH_MSG_CHANNEL_DATA                    94
+            SSH_MSG_CHANNEL_EXTENDED_DATA           95
+            SSH_MSG_CHANNEL_EOF                     96
+            SSH_MSG_CHANNEL_CLOSE                   97
+            SSH_MSG_CHANNEL_REQUEST                 98
+            SSH_MSG_CHANNEL_SUCCESS                 99
+            SSH_MSG_CHANNEL_FAILURE                100
+
+10.  IANA Considerations
+
+   This document is part of a set.  The IANA considerations for the SSH
+   protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and
+   this document, are detailed in [SSH-NUMBERS].
+
+11.  Security Considerations
+
+   This protocol is assumed to run on top of a secure, authenticated
+   transport.  User authentication and protection against network-level
+   attacks are assumed to be provided by the underlying protocols.
+
+   Full security considerations for this protocol are provided in
+   [SSH-ARCH].  Specific to this document, it is RECOMMENDED that
+   implementations disable all the potentially dangerous features (e.g.,
+   agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host
+   key has changed without notice or explanation.
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 21]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+12.  References
+
+12.1.  Normative References
+
+   [SSH-ARCH]     Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
+                  (SSH) Protocol Architecture", RFC 4251, January 2006.
+
+   [SSH-TRANS]    Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
+                  (SSH) Transport Layer Protocol", RFC 4253, January
+                  2006.
+
+   [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
+                  (SSH) Authentication Protocol", RFC 4252, January
+                  2006.
+
+   [SSH-NUMBERS]  Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell
+                  (SSH) Protocol Assigned Numbers", RFC 4250, January
+                  2006.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
+                  an IANA Considerations Section in RFCs", BCP 26, RFC
+                  2434, October 1998.
+
+   [RFC3066]      Alvestrand, H., "Tags for the Identification of
+                  Languages", BCP 47, RFC 3066, January 2001.
+
+   [RFC3629]      Yergeau, F., "UTF-8, a transformation format of ISO
+                  10646", STD 63, RFC 3629, November 2003.
+
+12.2.  Informative References
+
+   [RFC3330]      IANA, "Special-Use IPv4 Addresses", RFC 3330,
+                  September 2002.
+
+   [RFC3513]      Hinden, R. and S. Deering, "Internet Protocol Version
+                  6 (IPv6) Addressing Architecture", RFC 3513, April
+                  2003.
+
+   [SCHEIFLER]    Scheifler, R., "X Window System : The Complete
+                  Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
+                  edition.", Digital Press ISBN 1555580882, February
+                  1992.
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 22]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+   [POSIX]        ISO/IEC, 9945-1., "Information technology -- Portable
+                  Operating System Interface  (POSIX)-Part 1: System
+                  Application Program Interface (API) C Language", ANSI/
+                  IEE Std 1003.1, July 1996.
+
+Authors' Addresses
+
+   Tatu Ylonen
+   SSH Communications Security Corp
+   Valimotie 17
+   00380 Helsinki
+   Finland
+
+   EMail: ylo@ssh.com
+
+
+   Chris Lonvick (editor)
+   Cisco Systems, Inc.
+   12515 Research Blvd.
+   Austin  78759
+   USA
+
+   EMail: clonvick@cisco.com
+
+Trademark Notice
+
+   "ssh" is a registered trademark in the United States and/or other
+   countries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 23]
+
+RFC 4254                SSH Connection Protocol             January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 24]
+

Added: mina/sshd/trunk/src/docs/rfc4255.txt
URL: http://svn.apache.org/viewvc/mina/sshd/trunk/src/docs/rfc4255.txt?rev=723396&view=auto
==============================================================================
--- mina/sshd/trunk/src/docs/rfc4255.txt (added)
+++ mina/sshd/trunk/src/docs/rfc4255.txt Thu Dec  4 10:59:31 2008
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        J. Schlyter
+Request for Comments: 4255                                       OpenSSH
+Category: Standards Track                                     W. Griffin
+                                                                  SPARTA
+                                                            January 2006
+
+
+   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a method of verifying Secure Shell (SSH) host
+   keys using Domain Name System Security (DNSSEC).  The document
+   defines a new DNS resource record that contains a standard SSH key
+   fingerprint.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. SSH Host Key Verification .......................................2
+      2.1. Method .....................................................2
+      2.2. Implementation Notes .......................................2
+      2.3. Fingerprint Matching .......................................3
+      2.4. Authentication .............................................3
+   3. The SSHFP Resource Record .......................................3
+      3.1. The SSHFP RDATA Format .....................................4
+           3.1.1. Algorithm Number Specification ......................4
+           3.1.2. Fingerprint Type Specification ......................4
+           3.1.3. Fingerprint .........................................5
+      3.2. Presentation Format of the SSHFP RR ........................5
+   4. Security Considerations .........................................5
+   5. IANA Considerations .............................................6
+   6. Normative References ............................................7
+   7. Informational References ........................................7
+   8. Acknowledgements ................................................8
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 1]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+1.  Introduction
+
+   The SSH [6] protocol provides secure remote login and other secure
+   network services over an insecure network.  The security of the
+   connection relies on the server authenticating itself to the client
+   as well as the user authenticating itself to the server.
+
+   If a connection is established to a server whose public key is not
+   already known to the client, a fingerprint of the key is presented to
+   the user for verification.  If the user decides that the fingerprint
+   is correct and accepts the key, the key is saved locally and used for
+   verification for all following connections.  While some security-
+   conscious users verify the fingerprint out-of-band before accepting
+   the key, many users blindly accept the presented key.
+
+   The method described here can provide out-of-band verification by
+   looking up a fingerprint of the server public key in the DNS [1][2]
+   and using DNSSEC [5] to verify the lookup.
+
+   In order to distribute the fingerprint using DNS, this document
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
+
+   Basic understanding of the DNS system [1][2] and the DNS security
+   extensions [5] is assumed by this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+2.  SSH Host Key Verification
+
+2.1.  Method
+
+   Upon connection to an SSH server, the SSH client MAY look up the
+   SSHFP resource record(s) for the host it is connecting to.  If the
+   algorithm and fingerprint of the key received from the SSH server
+   match the algorithm and fingerprint of one of the SSHFP resource
+   record(s) returned from DNS, the client MAY accept the identity of
+   the server.
+
+2.2.  Implementation Notes
+
+   Client implementors SHOULD provide a configurable policy used to
+   select the order of methods used to verify a host key.  This document
+   defines one method: Fingerprint storage in DNS.  Another method
+   defined in the SSH Architecture [6] uses local files to store keys
+   for comparison.  Other methods that could be defined in the future
+   might include storing fingerprints in LDAP or other databases.  A
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 2]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   configurable policy will allow administrators to determine which
+   methods they want to use and in what order the methods should be
+   prioritized.  This will allow administrators to determine how much
+   trust they want to place in the different methods.
+
+   One specific scenario for having a configurable policy is where
+   clients do not use fully qualified host names to connect to servers.
+   In this scenario, the implementation SHOULD verify the host key
+   against a local database before verifying the key via the fingerprint
+   returned from DNS.  This would help prevent an attacker from
+   injecting a DNS search path into the local resolver and forcing the
+   client to connect to a different host.
+
+2.3.  Fingerprint Matching
+
+   The public key and the SSHFP resource record are matched together by
+   comparing algorithm number and fingerprint.
+
+      The public key algorithm and the SSHFP algorithm number MUST
+      match.
+
+      A message digest of the public key, using the message digest
+      algorithm specified in the SSHFP fingerprint type, MUST match the
+      SSHFP fingerprint.
+
+2.4.  Authentication
+
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not
+   authenticated by a trusted SIG RR.
+
+   Clients that do validate the DNSSEC signatures themselves SHOULD use
+   standard DNSSEC validation procedures.
+
+   Clients that do not validate the DNSSEC signatures themselves MUST
+   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
+   between themselves and the entity performing the signature
+   validation.
+
+3.  The SSHFP Resource Record
+
+   The SSHFP resource record (RR) is used to store a fingerprint of an
+   SSH public host key that is associated with a Domain Name System
+   (DNS) name.
+
+   The RR type code for the SSHFP RR is 44.
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 3]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+3.1.  The SSHFP RDATA Format
+
+   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
+   type and the fingerprint of the public host key.
+
+       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |   algorithm   |    fp type    |                               /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
+       /                                                               /
+       /                          fingerprint                          /
+       /                                                               /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.1.  Algorithm Number Specification
+
+   This algorithm number octet describes the algorithm of the public
+   key.  The following values are assigned:
+
+          Value    Algorithm name
+          -----    --------------
+          0        reserved
+          1        RSA
+          2        DSS
+
+   Reserving other types requires IETF consensus [4].
+
+3.1.2.  Fingerprint Type Specification
+
+   The fingerprint type octet describes the message-digest algorithm
+   used to calculate the fingerprint of the public key.  The following
+   values are assigned:
+
+          Value    Fingerprint type
+          -----    ----------------
+          0        reserved
+          1        SHA-1
+
+   Reserving other types requires IETF consensus [4].
+
+   For interoperability reasons, as few fingerprint types as possible
+   should be reserved.  The only reason to reserve additional types is
+   to increase security.
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 4]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+3.1.3.  Fingerprint
+
+   The fingerprint is calculated over the public key blob as described
+   in [7].
+
+   The message-digest algorithm is presumed to produce an opaque octet
+   string output, which is placed as-is in the RDATA fingerprint field.
+
+3.2.  Presentation Format of the SSHFP RR
+
+   The RDATA of the presentation format of the SSHFP resource record
+   consists of two numbers (algorithm and fingerprint type) followed by
+   the fingerprint itself, presented in hex, e.g.:
+
+       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
+
+   The use of mnemonics instead of numbers is not allowed.
+
+4.  Security Considerations
+
+   Currently, the amount of trust a user can realistically place in a
+   server key is proportional to the amount of attention paid to
+   verifying that the public key presented actually corresponds to the
+   private key of the server.  If a user accepts a key without verifying
+   the fingerprint with something learned through a secured channel, the
+   connection is vulnerable to a man-in-the-middle attack.
+
+   The overall security of using SSHFP for SSH host key verification is
+   dependent on the security policies of the SSH host administrator and
+   DNS zone administrator (in transferring the fingerprint), detailed
+   aspects of how verification is done in the SSH implementation, and in
+   the client's diligence in accessing the DNS in a secure manner.
+
+   One such aspect is in which order fingerprints are looked up (e.g.,
+   first checking local file and then SSHFP).  We note that, in addition
+   to protecting the first-time transfer of host keys, SSHFP can
+   optionally be used for stronger host key protection.
+
+      If SSHFP is checked first, new SSH host keys may be distributed by
+      replacing the corresponding SSHFP in DNS.
+
+      If SSH host key verification can be configured to require SSHFP,
+      SSH host key revocation can be implemented by removing the
+      corresponding SSHFP from DNS.
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 5]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   As stated in Section 2.2, we recommend that SSH implementors provide
+   a policy mechanism to control the order of methods used for host key
+   verification.  One specific scenario for having a configurable policy
+   is where clients use unqualified host names to connect to servers.
+   In this case, we recommend that SSH implementations check the host
+   key against a local database before verifying the key via the
+   fingerprint returned from DNS.  This would help prevent an attacker
+   from injecting a DNS search path into the local resolver and forcing
+   the client to connect to a different host.
+
+   A different approach to solve the DNS search path issue would be for
+   clients to use a trusted DNS search path, i.e., one not acquired
+   through DHCP or other autoconfiguration mechanisms.  Since there is
+   no way with current DNS lookup APIs to tell whether a search path is
+   from a trusted source, the entire client system would need to be
+   configured with this trusted DNS search path.
+
+   Another dependency is on the implementation of DNSSEC itself.  As
+   stated in Section 2.4, we mandate the use of secure methods for
+   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
+   is especially important if SSHFP is to be used as a basis for host
+   key rollover and/or revocation, as described above.
+
+   Since DNSSEC only protects the integrity of the host key fingerprint
+   after it is signed by the DNS zone administrator, the fingerprint
+   must be transferred securely from the SSH host administrator to the
+   DNS zone administrator.  This could be done manually between the
+   administrators or automatically using secure DNS dynamic update [11]
+   between the SSH server and the nameserver.  We note that this is no
+   different from other key enrollment situations, e.g., a client
+   sending a certificate request to a certificate authority for signing.
+
+5.  IANA Considerations
+
+   IANA has allocated the RR type code 44 for SSHFP from the standard RR
+   type space.
+
+   IANA has opened a new registry for the SSHFP RR type for public key
+   algorithms.  The defined types are:
+
+      0 is reserved
+      1 is RSA
+      2 is DSA
+
+   Adding new reservations requires IETF consensus [4].
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 6]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   IANA has opened a new registry for the SSHFP RR type for fingerprint
+   types.  The defined types are:
+
+      0 is reserved
+      1 is SHA-1
+
+   Adding new reservations requires IETF consensus [4].
+
+6.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033, March
+         2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions", RFC
+         4035, March 2005.
+
+   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+         Protocol Architecture", RFC 4251, January 2006.
+
+   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+         Transport Layer Protocol", RFC 4253, January 2006.
+
+7.  Informational References
+
+   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
+         Roadmap", RFC 2411, November 1998.
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 7]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+         Wellington, "Secret Key Transaction Authentication for DNS
+         (TSIG)", RFC 2845, May 2000.
+
+   [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+         ( SIG(0)s )", RFC 2931, September 2000.
+
+   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+8.  Acknowledgements
+
+   The authors gratefully acknowledge, in no particular order, the
+   contributions of the following persons:
+
+      Martin Fredriksson
+
+      Olafur Gudmundsson
+
+      Edward Lewis
+
+      Bill Sommerfeld
+
+Authors' Addresses
+
+   Jakob Schlyter
+   OpenSSH
+   812 23rd Avenue SE
+   Calgary, Alberta  T2G 1N8
+   Canada
+
+   EMail: jakob@openssh.com
+   URI:   http://www.openssh.com/
+
+
+   Wesley Griffin
+   SPARTA
+   7075 Samuel Morse Drive
+   Columbia, MD  21046
+   USA
+
+   EMail: wgriffin@sparta.com
+   URI:   http://www.sparta.com/
+
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 8]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 9]
+



Mime
View raw message