- [email protected] 2010/08/31 11:54:45

     [PROTOCOL PROTOCOL.agent PROTOCOL.certkeys auth2-jpake.c authfd.c]
     [authfile.c buffer.h dns.c kex.c kex.h key.c key.h monitor.c]
     [monitor_wrap.c myproposal.h packet.c packet.h pathnames.h readconf.c]
     [ssh-add.1 ssh-add.c ssh-agent.1 ssh-agent.c ssh-keygen.1 ssh-keygen.c]
     [ssh-keyscan.1 ssh-keyscan.c ssh-keysign.8 ssh.1 ssh.c ssh2.h]
     [ssh_config.5 sshconnect.c sshconnect2.c sshd.8 sshd.c sshd_config.5]
     [uuencode.c uuencode.h bufec.c kexecdh.c kexecdhc.c kexecdhs.c ssh-ecdsa.c]
     Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and
     host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer
     better performance than plain DH and DSA at the same equivalent symmetric
     key length, as well as much shorter keys.

     Only the mandatory sections of RFC5656 are implemented, specifically the
     three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and
     ECDSA. Point compression (optional in RFC5656 is NOT implemented).

     Certificate host and user keys using the new ECDSA key types are supported.

     Note that this code has not been tested for interoperability and may be
     subject to change.

     feedback and ok markus@

ChangeLog

@@ -25,6 +25,29 @@
      * actually, we allow a single one at the end of the string for now because
      we don't know how many deployed implementations get this wrong, but don't
      count on this to remain indefinitely.
+   - [email protected] 2010/08/31 11:54:45
+     [PROTOCOL PROTOCOL.agent PROTOCOL.certkeys auth2-jpake.c authfd.c]
+     [authfile.c buffer.h dns.c kex.c kex.h key.c key.h monitor.c]
+     [monitor_wrap.c myproposal.h packet.c packet.h pathnames.h readconf.c]
+     [ssh-add.1 ssh-add.c ssh-agent.1 ssh-agent.c ssh-keygen.1 ssh-keygen.c]
+     [ssh-keyscan.1 ssh-keyscan.c ssh-keysign.8 ssh.1 ssh.c ssh2.h]
+     [ssh_config.5 sshconnect.c sshconnect2.c sshd.8 sshd.c sshd_config.5]
+     [uuencode.c uuencode.h bufec.c kexecdh.c kexecdhc.c kexecdhs.c ssh-ecdsa.c]
+     Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and
+     host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer
+     better performance than plain DH and DSA at the same equivalent symmetric
+     key length, as well as much shorter keys.
+
+     Only the mandatory sections of RFC5656 are implemented, specifically the
+     three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and
+     ECDSA. Point compression (optional in RFC5656 is NOT implemented).
+
+     Certificate host and user keys using the new ECDSA key types are supported.
+
+     Note that this code has not been tested for interoperability and may be
+     subject to change.
+
+     feedback and ok markus@
 
 20100827
  - (dtucker) [contrib/redhat/sshd.init] Bug #1810: initlog is deprecated,

PROTOCOL

@@ -12,15 +12,17 @@ are individually implemented as extensions described below.
 The protocol used by OpenSSH's ssh-agent is described in the file
 PROTOCOL.agent
 
-1. transport: Protocol 2 MAC algorithm "[email protected]"
+1. Transport protocol changes
+
+1.1. transport: Protocol 2 MAC algorithm "[email protected]"
 
 This is a new transport-layer MAC method using the UMAC algorithm
 (rfc4418). This method is identical to the "umac-64" method documented
 in:
 
 http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt
 
-2. transport: Protocol 2 compression algorithm "[email protected]"
+1.2. transport: Protocol 2 compression algorithm "[email protected]"
 
 This transport-layer compression method uses the zlib compression
 algorithm (identical to the "zlib" method in rfc4253), but delays the
@@ -31,14 +33,27 @@ The method is documented in:
 
 http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
 
-3. transport: New public key algorithms "[email protected]" and
-   "[email protected]"
+1.3. transport: New public key algorithms "[email protected]",
+     "[email protected]",
+     "[email protected]",
+     "[email protected]" and
+     "[email protected]"
 
-OpenSSH introduces two new public key algorithms to support certificate
+OpenSSH introduces 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 "[email protected]"
+1.4. transport: Elliptic Curve cryptography
+
+OpenSSH supports ECC key exchange and public key authentication as
+specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384
+and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic
+curve points encoded using point compression are NOT accepted or
+generated.
+
+2. Connection protocol changes
+
+2.1. connection: Channel write close extension "[email protected]"
 
 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
@@ -77,8 +92,8 @@ message is only sent to OpenSSH peers (identified by banner).
 Other SSH implementations may be whitelisted to receive this message
 upon request.
 
-5. connection: disallow additional sessions extension
-   "[email protected]"
+2.2. connection: disallow additional sessions extension
+     "[email protected]"
 
 Most SSH connections will only ever request a single session, but a
 attacker may abuse a running ssh client to surreptitiously open
@@ -105,7 +120,7 @@ of this message, the no-more-sessions request is only sent to OpenSSH
 servers (identified by banner). Other SSH implementations may be
 whitelisted to receive this message upon request.
 
-6. connection: Tunnel forward extension "[email protected]"
+2.3. connection: Tunnel forward extension "[email protected]"
 
 OpenSSH supports layer 2 and layer 3 tunnelling via the "[email protected]"
 channel type. This channel type supports forwarding of network packets
@@ -166,7 +181,9 @@ The contents of the "data" field for layer 2 packets is:
 The "frame" field contains an IEEE 802.3 Ethernet frame, including
 header.
 
-7. sftp: Reversal of arguments to SSH_FXP_SYMLINK
+3. SFTP protocol changes
+
+3.1. 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,
@@ -179,7 +196,7 @@ SSH_FXP_SYMLINK as follows:
 	string		targetpath
 	string		linkpath
 
-8. sftp: Server extension announcement in SSH_FXP_VERSION
+3.2. 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
@@ -200,7 +217,7 @@ ever changed in an incompatible way. The server MAY advertise the same
 extension with multiple versions (though this is unlikely). Clients MUST
 check the version number before attempting to use the extension.
 
-9. sftp: Extension request "[email protected]"
+3.3. sftp: Extension request "[email protected]"
 
 This operation provides a rename operation with POSIX semantics, which
 are different to those provided by the standard SSH_FXP_RENAME in
@@ -217,7 +234,7 @@ rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
 This extension is advertised in the SSH_FXP_VERSION hello with version
 "1".
 
-10. sftp: Extension requests "[email protected]" and
+3.4. sftp: Extension requests "[email protected]" and
          "[email protected]"
 
 These requests correspond to the statvfs and fstatvfs POSIX system
@@ -258,4 +275,4 @@ The values of the f_flag bitmask are as follows:
 Both the "[email protected]" and "[email protected]" extensions are
 advertised in the SSH_FXP_VERSION hello with version "2".
 
-$OpenBSD: PROTOCOL,v 1.15 2010/02/26 20:29:54 djm Exp $
+$OpenBSD: PROTOCOL,v 1.16 2010/08/31 11:54:45 djm Exp $

PROTOCOL.agent

@@ -159,8 +159,8 @@ successfully added or a SSH_AGENT_FAILURE if an error occurred.
 
 2.2.3 Add protocol 2 key
 
-The OpenSSH agent supports DSA and RSA keys for protocol 2. DSA keys may
-be added using the following request
+The OpenSSH agent supports DSA, ECDSA and RSA keys for protocol 2. DSA
+keys may be added using the following request
 
 	byte			SSH2_AGENTC_ADD_IDENTITY or
 				SSH2_AGENTC_ADD_ID_CONSTRAINED
@@ -182,6 +182,30 @@ DSA certificates may be added with:
 	string			key_comment
 	constraint[]		key_constraints
 
+ECDSA keys may be added using the following request
+
+	byte			SSH2_AGENTC_ADD_IDENTITY or
+				SSH2_AGENTC_ADD_ID_CONSTRAINED
+	string			"ecdsa-sha2-nistp256" |
+				"ecdsa-sha2-nistp384" |
+				"ecdsa-sha2-nistp521"
+	string			ecdsa_curve_name
+	string			ecdsa_public_key
+	mpint			ecdsa_private
+	string			key_comment
+	constraint[]		key_constraints
+
+ECDSA certificates may be added with:
+	byte			SSH2_AGENTC_ADD_IDENTITY or
+				SSH2_AGENTC_ADD_ID_CONSTRAINED
+	string			"[email protected]" |
+				"[email protected]" |
+				"[email protected]"
+	string			certificate
+	mpint			ecdsa_private_key
+	string			key_comment
+	constraint[]		key_constraints
+
 RSA keys may be added with this request:
 
 	byte			SSH2_AGENTC_ADD_IDENTITY or
@@ -214,7 +238,7 @@ order to the protocol 1 add keys message. As with the corresponding
 protocol 1 "add key" request, the private key is overspecified to avoid
 redundant processing.
 
-For both DSA and RSA key add requests, "key_constraints" may only be
+For DSA, ECDSA and RSA key add requests, "key_constraints" may only be
 present if the request type is SSH2_AGENTC_ADD_ID_CONSTRAINED.
 
 The agent will reply with a SSH_AGENT_SUCCESS if the key has been
@@ -294,8 +318,7 @@ Protocol 2 keys may be removed with the following request:
 	string			key_blob
 
 Where "key_blob" is encoded as per RFC 4253 section 6.6 "Public Key
-Algorithms" for either of the supported key types: "ssh-dss" or
-"ssh-rsa".
+Algorithms" for any of the supported protocol 2 key types.
 
 The agent will delete any private key matching the specified public key
 and return SSH_AGENT_SUCCESS. If no such key was found, the agent will
@@ -364,8 +387,7 @@ Followed by zero or more consecutive keys, encoded as:
 	string			key_comment
 
 Where "key_blob" is encoded as per RFC 4253 section 6.6 "Public Key
-Algorithms" for either of the supported key types: "ssh-dss" or
-"ssh-rsa".
+Algorithms" for any of the supported protocol 2 key types.
 
 2.6 Private key operations
 
@@ -429,9 +451,9 @@ a protocol 2 key:
 	uint32			flags
 
 Where "key_blob" is encoded as per RFC 4253 section 6.6 "Public Key
-Algorithms" for either of the supported key types: "ssh-dss" or
-"ssh-rsa". "flags" is a bit-mask, but at present only one possible value
-is defined (see below for its meaning):
+Algorithms" for any of the supported protocol 2 key types. "flags" is
+a bit-mask, but at present only one possible value is defined (see below
+for its meaning):
 
 	SSH_AGENT_OLD_SIGNATURE		1
 
@@ -535,4 +557,4 @@ Locking and unlocking affects both protocol 1 and protocol 2 keys.
 	SSH_AGENT_CONSTRAIN_LIFETIME			1
 	SSH_AGENT_CONSTRAIN_CONFIRM			2
 
-$OpenBSD: PROTOCOL.agent,v 1.5 2010/02/26 20:29:54 djm Exp $
+$OpenBSD: PROTOCOL.agent,v 1.6 2010/08/31 11:54:45 djm Exp $

PROTOCOL.certkeys

@@ -5,31 +5,37 @@ 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.
+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.
+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.
+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:
-[email protected] and [email protected] that
-include certification information along with the public key that is used
-to sign challenges. ssh-keygen performs the CA signing operation.
+Certified keys are represented using new key types:
+
+    [email protected]
+    [email protected]
+    [email protected]
+    [email protected]
+    [email protected]
+
+These include certification information along with the public key
+that is used to sign challenges. ssh-keygen performs the CA signing
+operation.
 
 Protocol extensions
 -------------------
@@ -47,10 +53,9 @@ in RFC4252 section 7.
 New public key formats
 ----------------------
 
-The [email protected] and [email protected] 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.
+The certificate 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
@@ -93,6 +98,26 @@ DSA certificate
     string    signature key
     string    signature
 
+ECDSA certificate
+
+    string    "[email protected]" |
+              "[email protected]" |
+              "[email protected]"
+    string    nonce
+    string    curve
+    string    public_key
+    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.
@@ -101,6 +126,9 @@ 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.
 
+curve and public key are respectively the ECDSA "[identifier]" and "Q"
+defined in section 3.1 of RFC5656.
+
 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
@@ -123,7 +151,8 @@ 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
+
+    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
@@ -137,15 +166,17 @@ The reserved field is currently unused and is ignored in this version of
 the protocol.
 
 signature key contains the CA key used to sign the certificate.
-The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained"
+The valid key types for CA keys are ssh-rsa, ssh-dss and the ECDSA types
+ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521. "Chained"
 certificates, where the signature key type is a certificate type itself
 are NOT supported. Note that it is possible for a RSA certificate key to
-be signed by a DSS CA key and vice-versa.
+be signed by a DSS or ECDSA CA key and vice-versa.
 
 signature is computed over all preceding fields from the initial string
 up to, and including the signature key. Signatures are computed and
 encoded according to the rules defined for the CA's public key algorithm
-(RFC4253 section 6.6 for ssh-rsa and ssh-dss).
+(RFC4253 section 6.6 for ssh-rsa and ssh-dss, RFC5656 for the ECDSA
+types).
 
 Critical options
 ----------------
@@ -222,4 +253,4 @@ permit-user-rc          empty         Flag indicating that execution of
                                       of this script will not be permitted if
                                       this option is not present.
 
-$OpenBSD: PROTOCOL.certkeys,v 1.7 2010/08/04 05:40:39 djm Exp $
+$OpenBSD: PROTOCOL.certkeys,v 1.8 2010/08/31 11:54:45 djm Exp $

auth2-jpake.c

@@ -1,4 +1,4 @@
-/* $OpenBSD: auth2-jpake.c,v 1.3 2009/03/05 07:18:19 djm Exp $ */
+/* $OpenBSD: auth2-jpake.c,v 1.4 2010/08/31 11:54:45 djm Exp $ */
 /*
  * Copyright (c) 2008 Damien Miller.  All rights reserved.
  *
@@ -162,6 +162,11 @@ derive_rawsalt(const char *username, u_char *rawsalt, u_int len)
 			fatal("%s: DSA key missing priv_key", __func__);
 		buffer_put_bignum2(&b, k->dsa->priv_key);
 		break;
+	case KEY_ECDSA:
+		if (EC_KEY_get0_private_key(k->ecdsa) == NULL)
+			fatal("%s: ECDSA key missing priv_key", __func__);
+		buffer_put_bignum2(&b, EC_KEY_get0_private_key(k->ecdsa));
+		break;
 	default:
 		fatal("%s: unknown key type %d", __func__, k->type);
 	}