ports/libssh
ports/libssh
1
1
Fork 0
Code Releases 1 Activity

moved ssh drafts elsewhere (for packaging reasons)

Browse Source 
git-svn-id: svn+ssh://svn.berlios.de/svnroot/repos/libssh/trunk@95 7dcaeef0-15fb-0310-b436-a5af3365683c
This commit is contained in:
Aris Adamantiadis 2006-12-10 23:13:29 +00:00
parent 1298817046
commit f159b5d817
21 changed files with 0 additions and 19590 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
doc/base64.txt
View File

@ -1,107 +0,0 @@
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be humanly
readable. The encoding and decoding algorithms are simple, but the
encoded data are consistently only about 33 percent larger than the
unencoded data. This encoding is virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
The base64 encoding is adapted from RFC 1421, with one change: base64
eliminates the "*" mechanism for embedded clear text.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
NOTE: This subset has the important property that it is
represented identically in all versions of ISO 646, including US
ASCII, and all characters in the subset are also represented
identically in all versions of EBCDIC. Other popular encodings,
such as the encoding used by the uuencode utility and the base85
encoding specified as part of Level 2 PostScript, do not share
these properties, and thus do not fulfill the portability
requirements a binary transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right, a
24-bit input group is formed by concatenating 3 8-bit input groups.
These 24 bits are then treated as 4 concatenated 6-bit groups, each
of which is translated into a single digit in the base64 alphabet.
When encoding a bit stream via the base64 encoding, the bit stream
must be presumed to be ordered with the most-significant-bit first.
That is, the first bit in the stream will be the high-order bit in
the first byte, and the eighth bit will be the low-order bit in the
first byte, and so on.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string. These characters, identified in Table 1, below, are
selected so as to be universally representable, and the set excludes
characters with particular significance to SMTP (e.g., ".", CR, LF)
and to the encapsulation boundaries defined in this document (e.g.,
"-").
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
The output stream (encoded bytes) must be represented in lines of no
more than 76 characters each. All line breaks or other characters
not found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances.
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body. When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups. Padding at the end of
the data is performed using the '=' character. Since all base64
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Because it is used only for padding at the end of the data, the
occurrence of any '=' characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data. The same applies to any illegal sequence of
characters in the base64 encoding, such as "====="
Care must be taken to use the proper octets for line breaks if base64
encoding is applied directly to text material that has not been
converted to canonical form. In particular, text line breaks must be
converted into CRLF sequences prior to base64 encoding. The important
thing to note is that this may be done directly by the encoder rather
than in a prior canonicalization step in some implementations.
NOTE: There is no need to worry about quoting apparent
encapsulation boundaries within base64-encoded parts of multipart
entities because no hyphen characters are used in the base64
encoding.

647
doc/draft-ietf-secsh-agent-01.txt
View File

@ -1,647 +0,0 @@
Network Working Group Tatu Ylonen
INTERNET-DRAFT Timo J. Rinne
draft-ietf-secsh-agent-01.txt Sami Lehtinen
Expires in six months SSH Communications Security
20 November, 2002
Secure Shell Authentication Agent Protocol
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.
Abstract
This document describes the Secure Shell authentication agent protocol
(i.e., the protocol used between a client requesting authentication and
the authentication agent). This protocol usually runs in a machine-spe-
cific local channel or over a forwarded authentication channel. It is
assumed that the channel is trusted, so no protection for the communica-
tions channel is provided by this protocol.
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 1]
INTERNET-DRAFT 20 November, 2002
Table of Contents
1. Authentication Agent Protocol . . . . . . . . . . . . . . . . . 2
1.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Forwarding Notices . . . . . . . . . . . . . . . . . . . . . 3
1.3. Requesting Version Number . . . . . . . . . . . . . . . . . 3
1.4. Adding Keys to the Agent . . . . . . . . . . . . . . . . . . 4
1.5. Deleting Keys from the Agent . . . . . . . . . . . . . . . . 5
1.6. Deleting specific key from the Agent . . . . . . . . . . . . 5
1.7. Listing the Keys that the Agent Can Use . . . . . . . . . . 6
2. Performing Private Key Operations . . . . . . . . . . . . . . . 6
2.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Decrypting . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Secure Shell Challenge-Response Authentication . . . . . . . 7
3. Administrative Messages . . . . . . . . . . . . . . . . . . . . 7
3.1. Locking and unlocking the agent . . . . . . . . . . . . . . 8
3.2. Miscellaneous Agent Commands . . . . . . . . . . . . . . . . 8
4. Agent Forwarding With Secure Shell . . . . . . . . . . . . . . . 9
4.1. Requesting Agent Forwarding . . . . . . . . . . . . . . . . 9
4.2. Agent Forwarding Channels . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
6. Intellectual Property . . . . . . . . . . . . . . . . . . . . . 10
7. Additional Information . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Address of Authors . . . . . . . . . . . . . . . . . . . . . . . 10
1. Authentication Agent Protocol
The authentication agent is a piece of software that runs in a user's
local workstation, laptop, or other trusted device. It is used to
implement single sign-on. It holds the user's private keys in its own
storage, and can perform requested operations using the private key. It
allows the keys to be kept on a smartcard or other special hardware that
can perform cryptographic operations.
The authentication agent protocol is used to communicate between the
authentication agent and clients wanting to authenticate something or
wanting to perform private key operations.
The actual communication between the client and the agent happens using
a machine-dependent trusted communications channel. This channel would
typically be a local socket, named pipe, or some kind of secure
messaging system that works inside the local machine.
The protocol works by the client sending requests to the agent, and the
agent responding to these requests.
1.1. Packet Format
All messages passed to/from the authentication agent have the following
format:
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 2]
INTERNET-DRAFT 20 November, 2002
uint32 length
byte type
data[length -1] data payload
The following packet types are currently defined:
/* Messages sent by the client. */
#define SSH_AGENT_REQUEST_VERSION 1
#define SSH_AGENT_ADD_KEY 202
#define SSH_AGENT_DELETE_ALL_KEYS 203
#define SSH_AGENT_LIST_KEYS 204
#define SSH_AGENT_PRIVATE_KEY_OP 205
#define SSH_AGENT_FORWARDING_NOTICE 206
#define SSH_AGENT_DELETE_KEY 207
#define SSH_AGENT_LOCK 208
#define SSH_AGENT_UNLOCK 209
#define SSH_AGENT_PING 212
#define SSH_AGENT_RANDOM 213
/* Messages sent by the agent. */
#define SSH_AGENT_SUCCESS 101
#define SSH_AGENT_FAILURE 102
#define SSH_AGENT_VERSION_RESPONSE 103
#define SSH_AGENT_KEY_LIST 104
#define SSH_AGENT_OPERATION_COMPLETE 105
#define SSH_AGENT_RANDOM_DATA 106
#define SSH_AGENT_ALIVE 150
1.2. Forwarding Notices
If the agent connection is forwarded through intermediate hosts (using
the SSH Connection Protocol agent forwarding feature (described in
Section ``Agent Forwarding With Secure Shell'' of this document), or
some other means), each intermediate node (Secure Shell client) should
insert the following message into the agent channel before forwarding
any other messages. The real agent will then receive these messages in
sequence the nearest node first, and can determine whether the
connection is from a local machine and if not, can log the path where
the connection came from. These messages must be wrapped in the
appropriate header.
byte SSH_AGENT_FORWARDING_NOTICE
string remote host name (as typed by the user, preferably)
string remote host ip
uint32 remote host port
1.3. Requesting Version Number
When the client opens a connection, it must send the following message
to the server. This must be the first message sent. The real agent
will receive this after zero or more forwarding notice messages.
byte SSH_AGENT_REQUEST_VERSION
string version string of the application sending the request
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 3]
INTERNET-DRAFT 20 November, 2002
(optional)
If the agent follows this protocol, it will respond with
byte SSH_AGENT_VERSION_RESPONSE
uint32 version number, 2 for this protocol
If the version number request is ever sent to the Secure Shell 1.x
agent, it will interpret it as a request to list identities. It will
then respond with a message whose first byte is 2. This can be used to
determine the version of the agent if compatibility with Secure Shell
1.x is desired.
If the version string query arrives without trailing string identifying
the client software version, it can be translated list identities
request sent by Secure Shell 1.x and handled accordingly. If agent
software does not support the agent protocol of Secure Shell 1.x, it MAY
also interpret this query as valid SSH_AGENT_REQUEST_VERSION packet.
1.4. Adding Keys to the Agent
The client can add a new private key to the agent with the following
message.
byte SSH_AGENT_ADD_KEY
string private key blob with empty passphrase
string public key and/or certificates for it
string description of the key
... 0, 1 or several constraints follow
All constraints are pairs of following format:
byte SSH_AGENT_CONSTRAINT_*
variable argument for the constraint
The type of the argument is dependent on the constraint type. Following
constraint types are currently defined:
/* Constraints 50-99 have a uint32 argument */
/* Argument is uint32 defining key expiration time-out in
seconds. After this timeout expires, the key can't be used.
0 == no timeout */
#define SSH_AGENT_CONSTRAINT_TIMEOUT 50
/* Argument is uint32 defining the number of operations that can
be performed with this key. 0xffffffff == no limit */
#define SSH_AGENT_CONSTRAINT_USE_LIMIT 51
/* Argument is uint32 defining the number of forwarding steps that
this key can be forwarded. 0xffffffff == no limit */
#define SSH_AGENT_CONSTRAINT_FORWARDING_STEPS 52
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 4]
INTERNET-DRAFT 20 November, 2002
/* Constraints 100-149 have a string argument */
/* Argument is string defining the allowed forwarding steps for
this key. XXX define this. */
#define SSH_AGENT_CONSTRAINT_FORWARDING_PATH 100
/* Constraints 150-199 have a boolean argument */
/* Argument is a boolean telling whether the key can be used
in Secure Shell 1.x compatibility operations. */
#define SSH_AGENT_CONSTRAINT_SSH1_COMPAT 150
/* Argument is a boolean telling whether operations performed
with this key should be confirmed interactively by the user
or not. */
#define SSH_AGENT_CONSTRAINT_NEED_USER_VERIFICATION 151
Message can contain zero, one or multiple constraints.
If the operation is successful, the agent will respond with the
following message.
byte SSH_AGENT_SUCCESS
If the operation fails for some reason, the following message will be
returned instead.
byte SSH_AGENT_FAILURE
uint32 error code
The error code is one of the following:
#define SSH_AGENT_ERROR_TIMEOUT 1
#define SSH_AGENT_ERROR_KEY_NOT_FOUND 2
#define SSH_AGENT_ERROR_DECRYPT_FAILED 3
#define SSH_AGENT_ERROR_SIZE_ERROR 4
#define SSH_AGENT_ERROR_KEY_NOT_SUITABLE 5
#define SSH_AGENT_ERROR_DENIED 6
#define SSH_AGENT_ERROR_FAILURE 7
#define SSH_AGENT_ERROR_UNSUPPORTED_OP 8
1.5. Deleting Keys from the Agent
All keys that are in possession of the agent can be deleted with the
following message. (The client is allowed to ignore this for some keys
if desired.)
byte SSH_AGENT_DELETE_ALL_KEYS
The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 5]
INTERNET-DRAFT 20 November, 2002
1.6. Deleting specific key from the Agent
The client can delete a specific key with given public key with
following message.
byte SSH_AGENT_DELETE_KEY
string public key and/or certificates for it
string description of the key
The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
1.7. Listing the Keys that the Agent Can Use
The following message requests a list of all keys that the agent can
use.
byte SSH_AGENT_LIST_KEYS
The agent will respond with the following message.
byte SSH_AGENT_KEY_LIST
uint32 number_of_keys
repeats number_of_keys times:
string public key blob or certificates
string description
2. Performing Private Key Operations
The real purpose of the agent is to perform private key operations.
Such operations are performed with the following message.
byte SSH_AGENT_PRIVATE_KEY_OP
string operation name
string key or certificates, as returned in SSH_AGENT_KEY_LIST
... operation-specific data follows
The operation to be performed is identified by a name (string). Custom
operations can be added by suffixing the operation name by the fully
qualified domain name of the person/organization adding the new
operation.
When the operation is complete, the agent will respond with either
SSH_AGENT_FAILURE or with the following message if the operation is
successful:
byte SSH_AGENT_OPERATION_COMPLETE
string resulting data
If an operation is attempted that is not supported by the agent, the
agent will respond with SSH_AGENT_FAILURE with error code set to
SSH_AGENT_ERROR_UNSUPPORTED_OP.
The standard operations are defined below.
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 6]
INTERNET-DRAFT 20 November, 2002
2.1. Signing
The agent can be used to create a digital signature using a key held by
the agent. The operation name is "sign", and data in is a hash
(suitable for the key) that is to be signed. This normally performs the
raw private key operation, without hashing data first. The resulting
data will be a binary representation of the output of the private key
operation. The exact details of the operations to be performed depend
on the key being used.
The operation-specific data has the following format:
string data to be signed
Alternatively, it is possible to give the actual data to be signed to
the agent. This is done using the operation "hash-and-sign". This is
otherwise equal, but performs key-dependent hashing before signing.
If the requested operation is not legal for the key, SSH_AGENT_FAILURE
will be returned with error code set to
SSH_AGENT_ERROR_KEY_NOT_SUITABLE.
2.2. Decrypting
The agent can be used to decrypt a public key encrypted message with the
operation "decrypt". This takes in raw public-key encrypted data, and
returns the resulting decrypted data.
This may also fail. If the requested operation is not legal for the
key, error code is set to SSH_AGENT_ERROR_KEY_NOT_SUITABLE.
The operation-specific data has the following format:
string data to be decrypted
2.3. Secure Shell Challenge-Response Authentication
Performs Secure Shell challenge-response authentication. This operation
has the name "ssh1-challenge-response".
This operation works by first decrypting the challenge, then computing
MD5 of the concatenation of the decrypted challenge and the session id
(in this order), and returns the resulting 16 byte hash. The operation-
specific data is in the following format:
string challenge encrypted using the public key
string session id
Normally, the length of the challenge before encryption will be 32 bytes
and the length of the session id 16 bytes. The length of the encrypted
challenge depends on the key and algorithm used.
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 7]
INTERNET-DRAFT 20 November, 2002
3. Administrative Messages
There are also a number of messages that are only used to administer the
agent. These might e.g. be used by a user interface for the agent. The
agent should only allow these messages from local connection (i.e., if
no forwarding notice messages were received before the version number
request).
3.1. Locking and unlocking the agent
The agent can be temporarily locked by message:
byte SSH_AGENT_LOCK
string locking password
The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
Particularily SSH_AGENT_FAILURE is sent, if agent is already locked.
After this message, agent responds to all commands with
SSH_AGENT_FAILURE until it receives a following command.
byte SSH_AGENT_UNLOCK
string locking password
The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
Particularily SSH_AGENT_FAILURE is sent, if agent is not locked or if
the submitted password does not match with one given with SSH_AGENT_LOCK
message.
3.2. Miscellaneous Agent Commands
byte SSH_AGENT_PING
... arbitrary padding data
Any agent or client receiving this message, should respond with
byte SSH_AGENT_ALIVE
... padding data from the SSH_AGENT_PING request
where the padding data is identical to the data sent with
SSH_AGENT_PING.
byte SSH_AGENT_RANDOM
uint32 the length of the requested random buffer
Client can request random data from the agent by this message. Agent
responds either with SSH_AGENT_RANDOM_DATA or SSH_AGENT_FAILURE message.
byte SSH_AGENT_RANDOM_DATA
string random data
This message is a successful response to SSH_AGENT_RANDOM message.
Message contains the random string of requested length.
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 8]
INTERNET-DRAFT 20 November, 2002
4. Agent Forwarding With Secure Shell
The agent connection is typically forwarded over a Secure Shell
connection. This requires small additions to the SSH Connection Protocol
[SSH-CONN].
4.1. Requesting Agent Forwarding
Agent forwarding may be requested for a session by sending
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "auth-agent-req"
boolean want reply
This will, on success, create an agent listener to the remote end.
4.2. Agent Forwarding Channels
When a connection comes to the forwarded agent listener, a channel is
opened to forward the connection to the other side.
byte SSH_MSG_CHANNEL_OPEN
string "auth-agent"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
Implementations MUST reject these messages unless they have previously
requested agent forwarding.
Forwarded agent channels are independent of any sessions, and closing a
session channel does not in any way imply that forwarded connections
should be closed.
5. Security Considerations
The authentication agent is used to control security-sensitive
operations, and is used to implement single sign-on.
Anyone with access to the authentication agent can perform private key
operations with the agent. This is a power equivalent to possession of
the private key as long as the connection to the key is maintained. It
is not possible to retrieve the key from the agent.
It is recommended that agent implementations allow and perform some form
of logging and access control. This access control may utilize
information about the path through which the connection was received (as
collected with SSH_AGENT_FORWARDING_NOTICE messages; however, the path
is reliable only up to and including the first unreliable machine.).
Implementations should also allow restricting the operations that can be
performed with keys - e.g., limiting them to challenge-response only.
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 9]
INTERNET-DRAFT 20 November, 2002
One should note that a local superuser will be able to obtain access to
agents running on the local machine. This cannot be prevented; in most
operating systems, a user with sufficient privileges will be able to
read the keys from the physical memory.
The authentication agent should not be run or forwarded to machine whose
integrity is not trusted, as security on such machines might be
compromised and might allow an attacker to obtain unauthorized access to
the agent.
6. 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.
7. Additional Information
The current document editor is: Sami Lehtinen <sjl@ssh.com>. Comments
on this Internet-Draft should be sent to the IETF SECSH working group,
details at: http://ietf.org/html.charters/secsh-charter.html
8. References
[SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol",
Internet-Draft, draft-ietf-secsh-connect-16.txt
9. Address of Authors
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
FIN-00100 HELSINKI
Finland
E-mail: ylo@ssh.com
Timo J. Rinne
SSH Communications Security Corp
Fredrikinkatu 42
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 10]
INTERNET-DRAFT 20 November, 2002
FIN-00100 HELSINKI
Finland
E-mail: tri@ssh.com
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
FIN-00100 HELSINKI
Finland
E-mail: sjl@ssh.com
Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 11]

1736
doc/draft-ietf-secsh-architecture-14.txt
View File

File diff suppressed because it is too large Load Diff

559
doc/draft-ietf-secsh-assignednumbers-04.txt
View File

@ -1,559 +0,0 @@
Network Working Group S. Lehtinen
Internet-Draft SSH Communications Security Corp
Expires: February 13, 2004 D. Moffat
Sun Microsystems
August 15, 2003
SSH Protocol Assigned Numbers
draft-ietf-secsh-assignednumbers-04.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 February 13, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). 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]. Except for one HISTORIC algorithm
generally regarded as obsolete, 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 February 13, 2004 [Page 1]
Internet-Draft SSH Protocol Assigned Numbers August 2003
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
4.4 Compression Algorithm Names . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
Lehtinen & Moffat Expires February 13, 2004 [Page 2]
Internet-Draft SSH Protocol Assigned Numbers August 2003
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 February 13, 2004 [Page 3]
Internet-Draft SSH Protocol Assigned Numbers August 2003
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 February 13, 2004 [Page 4]
Internet-Draft SSH Protocol Assigned Numbers August 2003
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 February 13, 2004 [Page 5]
Internet-Draft SSH Protocol Assigned Numbers August 2003
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 February 13, 2004 [Page 6]
Internet-Draft SSH Protocol Assigned Numbers August 2003
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 February 13, 2004 [Page 7]
Internet-Draft SSH Protocol Assigned Numbers August 2003
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]
4.4 Compression Algorithm Names
Algorithm name Reference
--------------- ---------
none [SSH-TRANS, Section 4.2]
zlib [SSH-TRANS, Section 4.2]
References
[SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-
ietf-architecture-14.txt, July 2003.
[SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-16.txt, July 2003.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-
ietf-userauth-17.txt, July 2003.
Lehtinen & Moffat Expires February 13, 2004 [Page 8]
Internet-Draft SSH Protocol Assigned Numbers August 2003
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-
ietf-connect-17.txt, July 2003.
[SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned
Numbers", I-D draft-ietf-secsh-assignednumbers-
03.txt, July 2003.
[FIPS-46-3] U.S. Dept. of Commerce, ., "FIPS PUB 46-3, Data
Encryption Standard (DES)", October 1999.
Authors' Addresses
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: sjl@ssh.com
Darren J Moffat
Sun Microsystems
901 San Antonio Road
Palo Alto 94303
USA
EMail: Darren.Moffat@Sun.COM
Lehtinen & Moffat Expires February 13, 2004 [Page 9]
Internet-Draft SSH Protocol Assigned Numbers August 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 February 13, 2004 [Page 10]

366
doc/draft-ietf-secsh-auth-kbdinteract-05-cleaned.txt
View File

@ -1,366 +0,0 @@
Generic Message Exchange Authentication For SSH
<draft-ietf-secsh-auth-kbdinteract-05.txt>
Abstract
SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes a general
purpose authentication method for the SSH protocol, suitable for
interactive authentications where the authentication data should be
entered via a keyboard. The major goal of this method is to allow
the SSH client to support a whole class of authentication
mechanism(s) without knowing the specifics of the actual
authentication mechanism(s).
1. Introduction
The SSH authentication protocol [SSH-USERAUTH] is a general-purpose
user authentication protocol. It is intended to be run over the SSH
transport layer protocol [SSH-TRANS]. The authentication protocol
assumes that the underlying protocols provide integrity and
confidentiality protection.
This document describes a general purpose authentication method for
the SSH authentication protocol. This method is suitable for
interactive authentication methods which do not need any special
software support on the client side. Instead all authentication data
should be entered via the keyboard. The major goal of this method is
to allow the SSH client to have little or no knowledge of the
specifics of the underlying authentication mechanism(s) used by the
SSH server. This will allow the server to arbitrarily select or
change the underlying authentication mechanism(s) without having to
update client code.
The name for this authentication method is "keyboard-interactive".
2. Rationale
Currently defined authentication methods for SSH are tightly coupled
with the underlying authentication mechanism. This makes it
difficult to add new mechanisms for authentication as all clients
must be updated to support the new mechanism. With the generic
method defined here, clients will not require code changes to support
new authentication mechanisms, and if a separate authentication layer
is used, such as [PAM], then the server may not need any code changes
either.
This presents a significant advantage to other methods, such as the
"password" method (defined in [SSH-USERAUTH]), as new (presumably
stronger) methods may be added "at will" and system security can be
transparently enhanced.
Challenge-response and One Time Password mechanisms are also easily
supported with this authentication method.
This authentication method is however limited to authentication
mechanisms which do not require any special code, such as hardware
drivers or password mangling, on the client.
3. Protocol Exchanges
The client initiates the authentication with a
SSH_MSG_USERAUTH_REQUEST message. The server then requests
authentication information from the client with a
SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the
information from the user and then responds with a
SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send
another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the
answer from the client.
3.1 Initial Exchange
The authentication starts with the client sending the following
packet:
byte SSH_MSG_USERAUTH_REQUEST
string user name (ISO-10646 UTF-8, as defined in [RFC-2279])
string service name (US-ASCII)
string "keyboard-interactive" (US-ASCII)
string language tag (as defined in [RFC-3066])
string submethods (ISO-10646 UTF-8)
The language tag is deprecated and SHOULD be the empty string. It
may be removed in a future revision of this specification. The
server SHOULD instead select the language used based on the tags
communicated during key exchange [SSH-TRANS].
If the language tag is not the empty string, the server SHOULD use
the specified language for any messages sent to the client as part of
this protocol. The language tag SHOULD NOT be used for language
selection for messages outside of this protocol. The language to be
used if the server does not support the requested language is
implementation-dependent.
The submethods field is included so the user can give a hint of which
actual methods he wants to use. It is a a comma-separated list of
authentication submethods (software or hardware) which the user
prefers. If the client has knowledge of the submethods preferred by
the user, presumably through a configuration setting, it MAY use the
submethods field to pass this information to the server. Otherwise
it MUST send the empty string.
The actual names of the submethods is something which the user and
the server needs to agree upon.
Server interpretation of the submethods field is implementation-
dependent.
One possible implementation strategy of the submethods field on the
server is that, unless the user may use multiple different
submethods, the server ignores this field. If the user may
authenticate using one of several different submethods the server
should treat the submethods field as a hint on which submethod the
user wants to use this time.
Note that when this message is sent to the server, the client has not
yet prompted the user for a password, and so that information is NOT
included with this initial message (unlike the "password" method).
The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS,
SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.
The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
if the failure is based on the user name or service name; instead it
SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just
like the one(s) which would have been sent in cases where
authentication should proceed, and then send the failure message
(after a suitable delay, as described below). The goal is to make it
impossible to find valid usernames by just comparing the results when
authenticating as different users.
3.2 Information Requests
Requests are generated from the server using the
SSH_MSG_USERAUTH_INFO_REQUEST message.
The server may send as many requests as are necessary to authenticate
the client; the client MUST be prepared to handle multiple exchanges.
However the server MUST NOT ever have more than one
SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may
not send another request before the client has answered.
The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:
byte SSH_MSG_USERAUTH_INFO_REQUEST
string name (ISO-10646 UTF-8)
string instruction (ISO-10646 UTF-8)
string language tag (as defined in [RFC-3066])
int num-prompts
string prompt[1] (ISO-10646 UTF-8)
boolean echo[1]
...
string prompt[num-prompts] (ISO-10646 UTF-8)
boolean echo[num-prompts]
The server SHOULD take into consideration that some clients may not
be able to properly display a long name or prompt field (see next
section), and limit the lengths of those fields if possible. For
example, instead of an instruction field of "Enter Password" and a
prompt field of "Password for user23@host.domain: ", a better choice
might be an instruction field of
"Password authentication for user23@host.domain" and a prompt field
of "Password: ". It is expected that this authentication method
would typically be backended by [PAM] and so such choices would not
be possible.
The name and instruction fields MAY be empty strings, the client MUST
be prepared to handle this correctly. The prompt field(s) MUST NOT
be empty strings.
The language tag SHOULD describe the language used in the textual
fields. If the server does not know the language used, or if
multiple languages are used, the language tag MUST be the empty
string.
The num-prompts field may be `0', in which case there will be no
prompt/echo fields in the message, but the client SHOULD still
display the name and instruction fields (as described below).
3.3 User Interface
Upon receiving a request message, the client SHOULD prompt the user
as follows:
A command line interface (CLI) client SHOULD print the name and
instruction (if non-empty), adding newlines. Then for each prompt in
turn, the client SHOULD display the prompt and read the user input.
A graphical user interface (GUI) client has many choices on how to
prompt the user. One possibility is to use the name field (possibly
prefixed with the application's name) as the title of a dialog window
in which the prompt(s) are presented. In that dialog window, the
instruction field would be a text message, and the prompts would be
labels for text entry fields. All fields SHOULD be presented to the
user, for example an implementation SHOULD NOT discard the name field
because its windows lack titles; it SHOULD instead find another way
to display this information. If prompts are presented in a dialog
window, then the client SHOULD NOT present each prompt in a separate
window.
All clients MUST properly handle an instruction field with embedded
newlines. They SHOULD also be able to display at least 30 characters
for the name and prompts. If the server presents names or prompts
longer than 30 characters, the client MAY truncate these fields to
the length it can display. If the client does truncate any fields,
there MUST be an obvious indication that such truncation has occured.
The instruction field SHOULD NOT be truncated.
Clients SHOULD use control character filtering as discussed in
[SSH-ARCH] to avoid attacks by including terminal control characters
in the fields to be displayed.
For each prompt, the corresponding echo field indicates whether or
not the user input should be echoed as characters are typed. Clients
SHOULD correctly echo/mask user input for each prompt independently
of other prompts in the request message. If a client does not honor
the echo field for whatever reason, then the client MUST err on the
side of masking input. A GUI client might like to have a checkbox
toggling echo/mask. Clients SHOULD NOT add any additional characters
to the prompt such as ": " (colon-space); the server is responsible
for supplying all text to be displayed to the user. Clients MUST
also accept empty responses from the user and pass them on as empty
strings.
3.4 Information Responses
After obtaining the requested information from the user, the client
MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.
The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
follows:
byte SSH_MSG_USERAUTH_INFO_RESPONSE
int num-responses
string response[1] (ISO-10646 UTF-8)
...
string response[num-responses] (ISO-10646 UTF-8)
Note that the responses are encoded in ISO-10646 UTF-8. It is up to
the server how it interprets the responses and validates them.
However, if the client reads the responses in some other encoding
(e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
before transmitting.
If the num-responses field does not match the num-prompts field in
the request message, the server MUST send a failure message.
In the case that the server sends a `0' num-prompts field in the
request message, the client MUST send a response message with a `0'
num-responses field.
The responses MUST be ordered as the prompts were ordered. That is,
response[n] MUST be the answer to prompt[n].
After receiving the response, the server MUST send either a
SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
SSH_MSG_USERAUTH_INFO_REQUEST message.
If the server fails to authenticate the user (through the underlying
authentication mechanism(s)), it SHOULD NOT send another request
message(s) in an attempt to obtain new authentication data, instead
it SHOULD send a failure message. The only time the server should
send multiple request messages is if additional authentication data
is needed (i.e., because there are multiple underlying authentication
mechanisms that must be used to authenticate the user).
If the server intends to respond with a failure message, it MAY delay
for an implementation-dependent time before sending to the client.
It is suspected that implementations are likely to make the time
delay a configurable, a suggested default is 2 seconds.
4. Authentication Examples
Here are two example exchanges between a client and server. The
first is an example of challenge/response with a handheld token.
This is an authentication that is not otherwise possible with other
authentication methods.
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string ""
C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "CRYPTOCard Authentication"
S: string "The challenge is '14315716'"
S: string "en-US"
S: int 1
S: string "Response: "
S: boolean TRUE
[Client prompts user for password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "6d757575"
S: byte SSH_MSG_USERAUTH_SUCCESS
The second example is of a standard password authentication, in
this case the user's password is expired.
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string "en-US"
C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Authentication"
S: string ""
S: string "en-US"
S: int 1
S: string "Password: "
S: boolean FALSE
[Client prompts user for password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "password"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
S: string "Your password has expired."
S: string "en-US"
S: int 2
S: string "Enter new password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
[Client prompts user for new password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 2
C: string "newpass"
C: string "newpass"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password changed"
S: string "Password successfully changed for user23."
S: string "en-US"
S: int 0
[Client displays message to user]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 0
S: byte SSH_MSG_USERAUTH_SUCCESS
5. IANA Considerations
The userauth type "keyboard-interactive" is used for this
authentication method.
The following method-specific constants are used with this
authentication method:
SSH_MSG_USERAUTH_INFO_REQUEST 60
SSH_MSG_USERAUTH_INFO_RESPONSE 61

619
doc/draft-ietf-secsh-auth-kbdinteract-05.txt
View File

@ -1,619 +0,0 @@
Network Working Group F. Cusack
INTERNET-DRAFT Google, Inc.
Expires November 1, 2003 M. Forssen
Appgate AB
May 1, 2003
Generic Message Exchange Authentication For SSH
<draft-ietf-secsh-auth-kbdinteract-05.txt>
Status of this Memo
This document is an Internet-Draft and is subject to 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 November 1, 2003.
Abstract
SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes a general
purpose authentication method for the SSH protocol, suitable for
interactive authentications where the authentication data should be
entered via a keyboard. The major goal of this method is to allow
the SSH client to support a whole class of authentication
mechanism(s) without knowing the specifics of the actual
authentication mechanism(s).
F. Cusack, M. Forssen Expires November 1, 2003 [Page 1]
Internet Draft SSH Generic Interactive Authentication May 1, 2003
1. Introduction
The SSH authentication protocol [SSH-USERAUTH] is a general-purpose
user authentication protocol. It is intended to be run over the SSH
transport layer protocol [SSH-TRANS]. The authentication protocol
assumes that the underlying protocols provide integrity and
confidentiality protection.
This document describes a general purpose authentication method for
the SSH authentication protocol. This method is suitable for
interactive authentication methods which do not need any special
software support on the client side. Instead all authentication data
should be entered via the keyboard. The major goal of this method is
to allow the SSH client to have little or no knowledge of the
specifics of the underlying authentication mechanism(s) used by the
SSH server. This will allow the server to arbitrarily select or
change the underlying authentication mechanism(s) without having to
update client code.
The name for this authentication method is "keyboard-interactive".
This document should be read only after reading the SSH architecture
document [SSH-ARCH] and the SSH authentication document
[SSH-USERAUTH]. This document freely uses terminology and notation
from both documents without reference or further explanation.
This document also describes some of the client interaction with the
user in obtaining the authentication information. While this is
somewhat out of the scope of a protocol specification, it is
described here anyway since some aspects of the protocol are
specifically designed based on user interface issues, and omitting
this information may lead to incompatible or awkward implementations.
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].
2. Rationale
Currently defined authentication methods for SSH are tightly coupled
with the underlying authentication mechanism. This makes it