Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/crypto/external/bsd/openssh/dist Imported openssh-5.6
details: https://anonhg.NetBSD.org/src/rev/a8cb507cdf3f
branches: trunk
changeset: 758920:a8cb507cdf3f
user: adam <adam%NetBSD.org@localhost>
date: Sun Nov 21 17:05:52 2010 +0000
description:
Imported openssh-5.6
diffstat:
crypto/external/bsd/openssh/dist/PROTOCOL | 37 +-
crypto/external/bsd/openssh/dist/PROTOCOL.agent | 24 +-
crypto/external/bsd/openssh/dist/PROTOCOL.certkeys | 225 +
crypto/external/bsd/openssh/dist/PROTOCOL.mux | 203 +
crypto/external/bsd/openssh/dist/pkcs11.h | 1358 +++++++++++
crypto/external/bsd/openssh/dist/roaming.h | 10 +-
crypto/external/bsd/openssh/dist/roaming_client.c | 277 ++
crypto/external/bsd/openssh/dist/roaming_serv.c | 30 +
crypto/external/bsd/openssh/dist/ssh-pkcs11-client.c | 231 +
crypto/external/bsd/openssh/dist/ssh-pkcs11-helper.8 | 44 +
crypto/external/bsd/openssh/dist/ssh-pkcs11-helper.c | 350 ++
crypto/external/bsd/openssh/dist/ssh-pkcs11-helper/Makefile | 18 +
crypto/external/bsd/openssh/dist/ssh-pkcs11.c | 586 ++++
crypto/external/bsd/openssh/dist/ssh-pkcs11.h | 21 +
14 files changed, 3396 insertions(+), 18 deletions(-)
diffs (truncated from 3583 to 300 lines):
diff -r 450cf81f5317 -r a8cb507cdf3f crypto/external/bsd/openssh/dist/PROTOCOL
--- a/crypto/external/bsd/openssh/dist/PROTOCOL Sun Nov 21 16:19:19 2010 +0000
+++ b/crypto/external/bsd/openssh/dist/PROTOCOL Sun Nov 21 17:05:52 2010 +0000
@@ -6,8 +6,8 @@
http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt
-Features from newer versions of the draft are not supported, unless
-explicitly implemented as extensions described below.
+Newer versions of the draft will not be supported, though some features
+are individually implemented as extensions described below.
The protocol used by OpenSSH's ssh-agent is described in the file
PROTOCOL.agent
@@ -31,7 +31,14 @@
http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
-3. connection: Channel write close extension "eow%openssh.com@localhost"
+3. transport: New public key algorithms "ssh-rsa-cert-v00%openssh.com@localhost" and
+ "ssh-dsa-cert-v00%openssh.com@localhost"
+
+OpenSSH introduces two new public key algorithms to support certificate
+authentication for users and hostkeys. These methods are documented in
+the file PROTOCOL.certkeys
+
+4. connection: Channel write close extension "eow%openssh.com@localhost"
The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF
message to allow an endpoint to signal its peer that it will send no
@@ -70,7 +77,7 @@
Other SSH implementations may be whitelisted to receive this message
upon request.
-4. connection: disallow additional sessions extension
+5. connection: disallow additional sessions extension
"no-more-sessions%openssh.com@localhost"
Most SSH connections will only ever request a single session, but a
@@ -98,7 +105,7 @@
servers (identified by banner). Other SSH implementations may be
whitelisted to receive this message upon request.
-5. connection: Tunnel forward extension "tun%openssh.com@localhost"
+6. connection: Tunnel forward extension "tun%openssh.com@localhost"
OpenSSH supports layer 2 and layer 3 tunnelling via the "tun%openssh.com@localhost"
channel type. This channel type supports forwarding of network packets
@@ -121,10 +128,10 @@
SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */
The "tunnel unit number" specifies the remote interface number, or may
-be zero to allow the server to automatically chose an interface. A server
-that is not willing to open a client-specified unit should refuse the
-request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful open,
-the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
+be 0x7fffffff to allow the server to automatically chose an interface. A
+server that is not willing to open a client-specified unit should refuse
+the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful
+open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
Once established the client and server may exchange packet or frames
over the tunnel channel by encapsulating them in SSH protocol strings
@@ -151,7 +158,7 @@
The "packet data" field consists of the IPv4/IPv6 datagram itself
without any link layer header.
-The contents of the "data" field for layer 3 packets is:
+The contents of the "data" field for layer 2 packets is:
uint32 packet length
byte[packet length] frame
@@ -159,7 +166,7 @@
The "frame" field contains an IEEE 802.3 Ethernet frame, including
header.
-6. sftp: Reversal of arguments to SSH_FXP_SYMLINK
+7. sftp: Reversal of arguments to SSH_FXP_SYMLINK
When OpenSSH's sftp-server was implemented, the order of the arguments
to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately,
@@ -172,7 +179,7 @@
string targetpath
string linkpath
-7. sftp: Server extension announcement in SSH_FXP_VERSION
+8. sftp: Server extension announcement in SSH_FXP_VERSION
OpenSSH's sftp-server lists the extensions it supports using the
standard extension announcement mechanism in the SSH_FXP_VERSION server
@@ -193,7 +200,7 @@
extension with multiple versions (though this is unlikely). Clients MUST
check the version number before attempting to use the extension.
-8. sftp: Extension request "posix-rename%openssh.com@localhost"
+9. sftp: Extension request "posix-rename%openssh.com@localhost"
This operation provides a rename operation with POSIX semantics, which
are different to those provided by the standard SSH_FXP_RENAME in
@@ -210,7 +217,7 @@
This extension is advertised in the SSH_FXP_VERSION hello with version
"1".
-9. sftp: Extension requests "statvfs%openssh.com@localhost" and
+10. sftp: Extension requests "statvfs%openssh.com@localhost" and
"fstatvfs%openssh.com@localhost"
These requests correspond to the statvfs and fstatvfs POSIX system
@@ -251,4 +258,4 @@
Both the "statvfs%openssh.com@localhost" and "fstatvfs%openssh.com@localhost" extensions are
advertised in the SSH_FXP_VERSION hello with version "2".
-$OpenBSD: PROTOCOL,v 1.12 2009/02/14 06:35:49 djm Exp $
+$OpenBSD: PROTOCOL,v 1.15 2010/02/26 20:29:54 djm Exp $
diff -r 450cf81f5317 -r a8cb507cdf3f crypto/external/bsd/openssh/dist/PROTOCOL.agent
--- a/crypto/external/bsd/openssh/dist/PROTOCOL.agent Sun Nov 21 16:19:19 2010 +0000
+++ b/crypto/external/bsd/openssh/dist/PROTOCOL.agent Sun Nov 21 17:05:52 2010 +0000
@@ -173,6 +173,15 @@
string key_comment
constraint[] key_constraints
+DSA certificates may be added with:
+ byte SSH2_AGENTC_ADD_IDENTITY or
+ SSH2_AGENTC_ADD_ID_CONSTRAINED
+ string "ssh-dss-cert-v00%openssh.com@localhost"
+ string certificate
+ mpint dsa_private_key
+ string key_comment
+ constraint[] key_constraints
+
RSA keys may be added with this request:
byte SSH2_AGENTC_ADD_IDENTITY or
@@ -187,6 +196,19 @@
string key_comment
constraint[] key_constraints
+RSA certificates may be added with this request:
+
+ byte SSH2_AGENTC_ADD_IDENTITY or
+ SSH2_AGENTC_ADD_ID_CONSTRAINED
+ string "ssh-rsa-cert-v00%openssh.com@localhost"
+ string certificate
+ mpint rsa_d
+ mpint rsa_iqmp
+ mpint rsa_p
+ mpint rsa_q
+ string key_comment
+ constraint[] key_constraints
+
Note that the 'rsa_p' and 'rsa_q' parameters are sent in the reverse
order to the protocol 1 add keys message. As with the corresponding
protocol 1 "add key" request, the private key is overspecified to avoid
@@ -513,4 +535,4 @@
SSH_AGENT_CONSTRAIN_LIFETIME 1
SSH_AGENT_CONSTRAIN_CONFIRM 2
-$OpenBSD: PROTOCOL.agent,v 1.4 2008/07/01 23:12:47 stevesk Exp $
+$OpenBSD: PROTOCOL.agent,v 1.5 2010/02/26 20:29:54 djm Exp $
diff -r 450cf81f5317 -r a8cb507cdf3f crypto/external/bsd/openssh/dist/PROTOCOL.certkeys
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/crypto/external/bsd/openssh/dist/PROTOCOL.certkeys Sun Nov 21 17:05:52 2010 +0000
@@ -0,0 +1,225 @@
+This document describes a simple public-key certificate authentication
+system for use by SSH.
+
+Background
+----------
+
+The SSH protocol currently supports a simple public key authentication
+mechanism. Unlike other public key implementations, SSH eschews the
+use of X.509 certificates and uses raw keys. This approach has some
+benefits relating to simplicity of configuration and minimisation
+of attack surface, but it does not support the important use-cases
+of centrally managed, passwordless authentication and centrally
+certified host keys.
+
+These protocol extensions build on the simple public key authentication
+system already in SSH to allow certificate-based authentication.
+The certificates used are not traditional X.509 certificates, with
+numerous options and complex encoding rules, but something rather
+more minimal: a key, some identity information and usage options
+that have been signed with some other trusted key.
+
+A sshd server may be configured to allow authentication via certified
+keys, by extending the existing ~/.ssh/authorized_keys mechanism
+to allow specification of certification authority keys in addition
+to raw user keys. The ssh client will support automatic verification
+of acceptance of certified host keys, by adding a similar ability
+to specify CA keys in ~/.ssh/known_hosts.
+
+Certified keys are represented using two new key types:
+ssh-rsa-cert-v01%openssh.com@localhost and ssh-dss-cert-v01%openssh.com@localhost that
+include certification information along with the public key that is used
+to sign challenges. ssh-keygen performs the CA signing operation.
+
+Protocol extensions
+-------------------
+
+The SSH wire protocol includes several extensibility mechanisms.
+These modifications shall take advantage of namespaced public key
+algorithm names to add support for certificate authentication without
+breaking the protocol - implementations that do not support the
+extensions will simply ignore them.
+
+Authentication using the new key formats described below proceeds
+using the existing SSH "publickey" authentication method described
+in RFC4252 section 7.
+
+New public key formats
+----------------------
+
+The ssh-rsa-cert-v01%openssh.com@localhost and ssh-dss-cert-v01%openssh.com@localhost key
+types take a similar high-level format (note: data types and
+encoding are as per RFC4251 section 5). The serialised wire encoding of
+these certificates is also used for storing them on disk.
+
+#define SSH_CERT_TYPE_USER 1
+#define SSH_CERT_TYPE_HOST 2
+
+RSA certificate
+
+ string "ssh-rsa-cert-v01%openssh.com@localhost"
+ string nonce
+ mpint e
+ mpint n
+ uint64 serial
+ uint32 type
+ string key id
+ string valid principals
+ uint64 valid after
+ uint64 valid before
+ string critical options
+ string extensions
+ string reserved
+ string signature key
+ string signature
+
+DSA certificate
+
+ string "ssh-dss-cert-v01%openssh.com@localhost"
+ string nonce
+ mpint p
+ mpint q
+ mpint g
+ mpint y
+ uint64 serial
+ uint32 type
+ string key id
+ string valid principals
+ uint64 valid after
+ uint64 valid before
+ string critical options
+ string extensions
+ string reserved
+ string signature key
+ string signature
+
+The nonce field is a CA-provided random bitstring of arbitrary length
+(but typically 16 or 32 bytes) included to make attacks that depend on
+inducing collisions in the signature hash infeasible.
+
+e and n are the RSA exponent and public modulus respectively.
+
+p, q, g, y are the DSA parameters as described in FIPS-186-2.
+
+serial is an optional certificate serial number set by the CA to
+provide an abbreviated way to refer to certificates from that CA.
+If a CA does not wish to number its certificates it must set this
+field to zero.
+
+type specifies whether this certificate is for identification of a user
+or a host using a SSH_CERT_TYPE_... value.
+
+key id is a free-form text field that is filled in by the CA at the time
+of signing; the intention is that the contents of this field are used to
+identify the identity principal in log messages.
+
+"valid principals" is a string containing zero or more principals as
+strings packed inside it. These principals list the names for which this
+certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and
+usernames for SSH_CERT_TYPE_USER certificates. As a special case, a
+zero-length "valid principals" field means the certificate is valid for
+any principal of the specified type. XXX DNS wildcards?
+
+"valid after" and "valid before" specify a validity period for the
+certificate. Each represents a time in seconds since 1970-01-01
+00:00:00. A certificate is considered valid if:
+ valid after <= current time < valid before
+
+criticial options is a set of zero or more key options encoded as
+below. All such options are "critical" in the sense that an implementation
+must refuse to authorise a key that has an unrecognised option.
+
+extensions is a set of zero or more optional extensions. These extensions
+are not critical, and an implementation that encounters one that it does
+not recognise may safely ignore it.
+
+The reserved field is currently unused and is ignored in this version of
+the protocol.
Home |
Main Index |
Thread Index |
Old Index