draft-ietf-secsh-agent-00.txt   draft-ietf-secsh-agent-01.txt 
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
Network Working Group D. Moffat Secure Shell Authentication Agent Protocol
Internet-Draft Sun Microsystems
Expires: June 10, 2002 December 10, 2001
SSH Agent Forwarding
draft-ietf-secsh-agent-00.txt
Status of this Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance
all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as "work in progress." Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 10, 2002. Abstract
Copyright Notice 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.
Copyright (C) The Internet Society (2001). All Rights Reserved. Table of Contents
Abstract 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
SSH is a protocol for secure remote login and other secure network 1. Authentication Agent Protocol
services over an insecure network. One of the common authentication
mechanisms used with SSH is public key. This document describes the
authentication agent forwarding protocol, which runs as a channel
over [SSH-TRANS] it is designed to ensure that the sensitive private
keys never leave the users control even when using SSH to login over
multiple hops.
Table of Contents 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.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 The authentication agent protocol is used to communicate between the
1.1 Agent Operations . . . . . . . . . . . . . . . . . . . . . . . 3 authentication agent and clients wanting to authenticate something or
2. Security Considerations . . . . . . . . . . . . . . . . . . . 3 wanting to perform private key operations.
3. Additional Information . . . . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 5
1. Introduction 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.
This protocol is designed to facilitate an ad hoc secure single sign The protocol works by the client sending requests to the agent, and the
on mechanism using the SSH protocol. A typical scenario is that a agent responding to these requests.
user has their private keys stored on their laptop (host A) and uses
the SSH protocol to remotely connect to their corporate VPN (host B)
access point. Then uses further SSH connections to reach a specific
host (host C) within the enterprise network.
Without agent forwarding the user is required to have a copy of their 1.1. Packet Format
private key on host A and host B so that the connection to host C can
be made using public key authentication. The key pairs used for the
host A to B and the host B to C connection maybe the same but this is
not always the case.
This presents a security risk since the users private key(s) must be All messages passed to/from the authentication agent have the following
stored on host B which is likely to be a host the end user is not in format:
control of even though they do trust it. It is likely that the
private keys on host A and host B are stored in an encrypted format,
this means the user has at least two passwords to enter to make the
connection from A to C.
Ideally the private keys should remain on a device in the direct uint32 length
control of the end user (host A in this example) and all encryption byte type
and signing operations involving the private key should be performed data[length -1] data payload
on this device, regardless of the location of the entity requesting
the operation.
1.1 Agent Operations The following packet types are currently defined:
The following interactions with the agent are requried: ADD, DELETE, /* Messages sent by the client. */
LIST, SIGN. #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
An agent implementation MUST support requests to forward operations /* Messages sent by the agent. */
using all public key types, defined in [SSH-USERAUTH] even those that #define SSH_AGENT_SUCCESS 101
the implementation doesn't support natively. #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
2. Security Considerations 1.2. Forwarding Notices
This protocol is designed only to run as a channel of the SSH If the agent connection is forwarded through intermediate hosts (using
protocol. 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.
The goal of this extension is to ensure that the users private keys byte SSH_AGENT_FORWARDING_NOTICE
never leave the machine they are physically at. Ideally the private string remote host name (as typed by the user, preferably)
keys should be stored on a password protected removable media such as string remote host ip
a smartcard. uint32 remote host port
3. Additional Information 1.3. Requesting Version Number
The current document editor is: Darren.Moffat@Sun.COM. Comments on When the client opens a connection, it must send the following message
this internet draft should be sent to the IETF SECSH working group, to the server. This must be the first message sent. The real agent
details at: http://ietf.org/html.charters/secsh-charter.html will receive this after zero or more forwarding notice messages.
byte SSH_AGENT_REQUEST_VERSION
string version string of the application sending the request
(optional)
References If the agent follows this protocol, it will respond with
[FIPS-186] Federal Information Processing Standards Publication, byte SSH_AGENT_VERSION_RESPONSE
., "FIPS PUB 186, Digital Signature Standard", May uint32 version number, 2 for this protocol
1994.
[SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- If the version number request is ever sent to the Secure Shell 1.x
ietf-architecture-11.txt, July 2001. 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.
[SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D If the version string query arrives without trailing string identifying
draft-ietf-transport-11.txt, July 2001. 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.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- 1.4. Adding Keys to the Agent
ietf-userauth-13.txt, July 2001.
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- The client can add a new private key to the agent with the following
ietf-connect-14.txt, July 2001. message.
Author's Address 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
Darren J Moffat All constraints are pairs of following format:
Sun Microsystems
901 San Antonio Road
Palo Alto 94303
USA
EMail: Darren.Moffat@Sun.COM byte SSH_AGENT_CONSTRAINT_*
variable argument for the constraint
Full Copyright Statement The type of the argument is dependent on the constraint type. Following
constraint types are currently defined:
Copyright (C) The Internet Society (2001). All Rights Reserved. /* Constraints 50-99 have a uint32 argument */
This document and translations of it may be copied and furnished to /* Argument is uint32 defining key expiration time-out in
others, and derivative works that comment on or otherwise explain it seconds. After this timeout expires, the key can't be used.
or assist in its implementation may be prepared, copied, published 0 == no timeout */
and distributed, in whole or in part, without restriction of any #define SSH_AGENT_CONSTRAINT_TIMEOUT 50
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 /* Argument is uint32 defining the number of operations that can
revoked by the Internet Society or its successors or assigns. be performed with this key. 0xffffffff == no limit */
#define SSH_AGENT_CONSTRAINT_USE_LIMIT 51
This document and the information contained herein is provided on an /* Argument is uint32 defining the number of forwarding steps that
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING this key can be forwarded. 0xffffffff == no limit */
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING #define SSH_AGENT_CONSTRAINT_FORWARDING_STEPS 52
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION /* Constraints 100-149 have a string argument */
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement /* Argument is string defining the allowed forwarding steps for
this key. XXX define this. */
#define SSH_AGENT_CONSTRAINT_FORWARDING_PATH 100
Funding for the RFC Editor function is currently provided by the /* Constraints 150-199 have a boolean argument */
Internet Society.
/* 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.
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.
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.
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.
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.
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
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
 End of changes. 

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