From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 11:36:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVH2-0003Y8-KT for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:36:36 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVGw-0002yo-Pn for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:36:36 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id B21D663B56A; Thu, 5 Oct 2006 15:36:17 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 61E4463B559 for ; Thu, 5 Oct 2006 15:36:12 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 3EED2104DA0; Thu, 5 Oct 2006 17:36:02 +0200 (CEST) Message-ID: <452526E1.1040405@siliconcircus.com> Date: Thu, 05 Oct 2006 17:38:09 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lisa Dusseault CC: galb-list@vandyke.com, jpv@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: COMMENT: draft-ietf-secsh-publickey-subsystem References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi Lisa, Lisa Dusseault wrote: > > Is there any requirement for server ordering of public keys in > response to a 'list'? it might be worth saying the list is unordered > so that clients don't come to depend on some accidental ordering. Further to this, I've now added the following text: "There is no requirement that the responses be in any particular order. Whilst some server implementations may send the responses in some order, client implementations should not rely on responses being in any order." Thanks again for the review. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 11:36:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVH4-0003YV-9l for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:36:38 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVGz-00031N-TC for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:36:38 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 2D83763B581; Thu, 5 Oct 2006 15:36:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id C5EAE63B560 for ; Thu, 5 Oct 2006 15:36:16 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 6BE8711145E; Thu, 5 Oct 2006 17:36:10 +0200 (CEST) Message-ID: <452526EA.9000606@siliconcircus.com> Date: Thu, 05 Oct 2006 17:38:18 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sam Weiler CC: galb-list@vandyke.com, jpv@vandyke.com, ietf-ssh@netbsd.org Subject: Re: secdir review of draft-ietf-secsh-publickey-subsystem-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi Sam, Short replies to your comments below. Thanks for the review. Sam Weiler wrote: > > Substance: > > Section 4.3: Noticing that there's no way to revoke all keys without > explicitly naming them, i'm wondering if it would be wise to say that > implementations SHOULD support the 'list' operation. (Or, > alternatively, add a 'revoke all' command.) I've change the "MAY not..." text to a "SHOULD". > Section 4.1: It's not clear to me whether the "from" list contains > hostnames, IP addrs, or ...? Perhaps be a bit more specific. I've added the following text: "For IP-based networks, it is anticipated that the "from" parameter will take the form of a specific IP address or hostname." > Section 1 uses a 2119 SHOULD: "If password authentication is used, > servers SHOULD provide a configuration option to disable the use of > password authentication after the first public key is added." Is that > 2119 SHOULD really necessary? Following the comments from Jeffrey Hutzelman and Sam Hartman, I've not changed this text. > I was not entirely clear until section 3 that this doc was talking > about USER keys. Please say that more explicitly in both the abstract > and introduction. In both the abstract and introduction, I've swapped "...defines an authentication mechanism..." for "...defines a user authentication mechanism...". > Throughout, the doc talks about "packets" instead of "messages" > (e.g. in section 3, "the server sends response packets" or in section > 3.4, "...the first 15 bytes of the version packet") -- is that really > the appropriate term in this context? As noted by Jeffrey Hutzelman, it's consistent with SSH terminology. > Section 3.4 mentions that this is version 2 of the protocol. I'd > appreciate a historical note re: where version 1 is defined or, if it > wasn't defined, why we're using version #2. I've added the following sentence: "Version 1 was used by an early draft of this document. The version number was incremented after changes in the handling of status packets." > Section 3.1 uses the phrase "...close the subsystem", which seems a > bit unusual. Is that usage consistent with the rest of the SSH docs? See Jeffrey Hutzelman's note on this. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 11:36:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVHD-0003bM-Uq for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:36:47 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVHC-00037G-Hh for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:36:47 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 8176063B559; Thu, 5 Oct 2006 15:36:38 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 3FCD463B560 for ; Thu, 5 Oct 2006 15:36:37 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 05198111947 for ; Thu, 5 Oct 2006 17:36:35 +0200 (CEST) Message-ID: <45252703.7040305@siliconcircus.com> Date: Thu, 05 Oct 2006 17:38:43 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: IESG comments Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi, I've sent individual mails to Lisa Dusseault and Sam Weiler regarding their comments. Since I don't have addresses for the other people who commented, I'm covering them here. Lars Eggert: 3.1 para 8 : This is covered in RFC4254. 3.4 para 1 : I've clarified the text to "Both sides MUST start a connection..." 4.3 para 4 : critical isn't reported because some servers (indeed, I believe most/all current implementations?) may choose not to store that information. The security properties of "critical" are checked at the time of the add. 6.2.1 para 2 : Fixed Cullen Jennings: In order to be able to add the public key, the user has to have started the subsystem, which implies that the SSH connection protocol is running, which implies that the user has authenticated themselves to the server. This is equivalent to the various manual methods of adding keys the server for authentication. Dan Romascanu: I don't believe the document describes anything which requires a deployment strategy. There should be no interactions with other subsystems. No effects on other applications or the network are anticipated. Monitoring and management would probably be covered by any monitoring and management for the SSH server itself. In other words, if an operational considerations section were added, it would be short. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 11:37:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVHV-0003xW-PS for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:37:05 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVHU-0003BX-C5 for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 11:37:05 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 37CFC63B560; Thu, 5 Oct 2006 15:36:57 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 0B29463B12E for ; Thu, 5 Oct 2006 15:36:52 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 7411E111946; Thu, 5 Oct 2006 17:36:50 +0200 (CEST) Message-ID: <45252712.2040607@siliconcircus.com> Date: Thu, 05 Oct 2006 17:38:58 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: internet-drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Submission: draft-ietf-secsh-publickey-subsystem-08.txt Content-Type: multipart/mixed; boundary="------------050609080804000305080503" Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b9441a4a5b0bd4db4ba0f72cd2b21ac This is a multi-part message in MIME format. --------------050609080804000305080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached draft-ietf-secsh-publickey-subsystem-08.txt, which addresses IESG comments on version -07. Thanks, -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com --------------050609080804000305080503 Content-Type: text/plain; name="draft-ietf-secsh-publickey-subsystem-08.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-secsh-publickey-subsystem-08.txt" Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Intended status: Informational B. McClure Expires: April 8, 2007 VanDyke Software J. Bright Silicon Circus October 5, 2006 Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-08.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 8, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Galbraith, et al. Expires April 8, 2007 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem October 2006 Abstract Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Galbraith, et al. Expires April 8, 2007 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 6 3.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 6 3.2. Requests and Responses . . . . . . . . . . . . . . . . . . 7 3.3. The Status Message . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 7 3.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 8 4. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 9 4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 9 4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 12 4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 12 4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 15 6.2.2. Future Assignments of Names . . . . . . . . . . . . . 16 6.3. Public-Key Subystem Request Names . . . . . . . . . . . . 16 6.4. Public-Key Subsystem Response Names . . . . . . . . . . . 16 6.5. Public-Key Subsystem Attribute Names . . . . . . . . . . . 16 6.6. Public-Key subsystem Status Codes . . . . . . . . . . . . 17 6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 17 6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 17 6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Galbraith, et al. Expires April 8, 2007 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem October 2006 1. Introduction Secure Shell is a protocol for secure remote login and other secure network services over an insecure network. Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the Secure Shell transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the Secure Shell architecture [1] and Secure Shell connection [4] documents. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires April 8, 2007 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem October 2006 2. Terminology 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 RFC2119 [5]. Galbraith, et al. Expires April 8, 2007 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem October 2006 3. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove, and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in section 6.6, "Public Key Algorithms" of the SSH Transport Protocol document [2]. 3.1. Opening the Public-Key Subsystem The public-key subsystem is started by a client sending an SSH_MSG_CHANNEL_REQUEST over an existing session's channel. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". To open the public-key subsystem, the client sends: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey" Client implementations SHOULD reject this request; it is normally sent only by the client. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is not allowed access to the public-key subsystem (for example, because the user authenticated with a restricted public key). It is RECOMMENDED that clients request and check the reply for this request. Galbraith, et al. Expires April 8, 2007 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem October 2006 3.2. Requests and Responses All public-key subsystem requests and responses are sent in the following form: uint32 length string name ... request/response specific data follows The length field describes the length of the name field and of the request/response-specific data, but does not include the length of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. The version packet, as well as all requests and responses described in Section 4, are a description of the 'name' field and the data part of the packet. 3.3. The Status Message A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-3629] string language tag [RFC-3066] A status message MUST be sent for any unrecognized packets, and the request SHOULD NOT close the subsystem. 3.3.1. Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 Galbraith, et al. Expires April 8, 2007 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem October 2006 If a request completed successfully, the server MUST send the status code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as implied by their names. 3.4. The Version Packet Both sides MUST start a connection by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number This document describes version 2 of the protocol. Version 1 was used by an early draft of this document. The version number was incremented after changes in the handling of status packets. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Note that, normally, status messages are only sent by the server (in response to requests from the client). This is the only occasion on which the client sends a status message. Both sides MUST wait to receive this version before continuing. The "version" packet MUST NOT be sent again after this initial exchange. The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent in response to any other request. Implementations MAY use the first 15 bytes of the version packet as a "magic cookie" to avoid processing spurious output from the user's shell (as described in section 6.5 of [4]). These bytes will always be: 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E Galbraith, et al. Expires April 8, 2007 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem October 2006 4. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and listattributes. 4.1. Adding a Public Key If the client wishes to add a public key, the client sends: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists, but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED. Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a critical attribute, it MUST fail the add, with the status code SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a critical attribute, mere storage of the attribute is not sufficient -- rather, the server must understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [7]. Galbraith, et al. Expires April 8, 2007 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem October 2006 The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be critical. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specify the language for that attribute [6]. The client MAY specify more than one comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment with its language attribute. This attribute SHOULD NOT be critical. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorization checks the server may perform). This attribute SHOULD be critical. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be critical. If the value is empty, no subsystems may be started. If the "subsystem" attribute is not specified, no restrictions are placed on which subsystems may be started when authenticated using this key. "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "exec" Galbraith, et al. Expires April 8, 2007 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem October 2006 "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorization purposes, the authorization attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. The server should use whatever method is appropriate for its platform to identify the host - e.g. for IP-based networks, checking the IP address or performing a reverse DNS lookup. For IP-based networks, it is anticipated that the "from" parameter will take the form of a specific IP address or hostname. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except those to hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be critical. "reverse-forward" "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, except for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be critical. In addition to the attributes specified by the client, the server MAY provide a method for administrators to enforce certain attributes Galbraith, et al. Expires April 8, 2007 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem October 2006 compulsorily. 4.2. Removing a Public Key If the client wishes to remove a public key, the client sends: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 4.3. Listing Public Keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times There is no requirement that the responses be in any particular order. Whilst some server implementations may send the responses in some order, client implementations should not rely on responses being in any order. Following the last "publickey" response, a status packet MUST be sent. Implementations SHOULD support this request. 4.4. Listing Server Capabilities If the client wishes to know which key attributes the server supports, it sends: string "listattributes" The server will respond with zero or more of the following responses: Galbraith, et al. Expires April 8, 2007 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem October 2006 string "attribute" string attribute name boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. An example of use of the "compulsory" attribute would be a server with a configuration file specifying that the user is not permitted shell access. Given this, the server would return the "shell" attribute, with "compulsory" marked true. Whatever attributes the user subsequently asked the server to apply to their key, the server would also apply the "shell" attribute, rendering it impossible for the user to use a shell. Following the last "attribute" response, a status packet MUST be sent. An implementation MAY choose not to support this request. Galbraith, et al. Expires April 8, 2007 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem October 2006 5. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorize keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires April 8, 2007 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem October 2006 6. IANA Considerations This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments. 6.1. Registrations Consistent with Section 7 of [1], this document makes the following registration: The subsystem name "publickey". 6.2. Names In the following sections, the values for the namespaces are textual. The conventions and instructions to the IANA for future assignments are given in this section. The initial assignments are given in their respective sections. 6.2.1. Conventions for Names All names registered by the IANA in the following sections 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. A provision is made here for locally extensible names. The IANA will not register, and will not control names with the at-sign in them. Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceding the at-sign is the name. The format of the part preceding the at-sign is not specified, however these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), or whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified Internet domain name [9] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [8] email addresses. This is purely coincidental and actually has nothing to do with STD 11 [8]. An example of a locally defined name is "our-attribute@example.com" (without the double quotes). Galbraith, et al. Expires April 8, 2007 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem October 2006 6.2.2. Future Assignments of Names Requests for assignments of new Names MUST be done through the IETF Consensus method as described in [10]. 6.3. Public-Key Subystem Request Names The following table lists the initial assignments of Public-Key subsystem Request names. Request Name ------------- version add remove list listattributes 6.4. Public-Key Subsystem Response Names The following table lists the initial assignments of Public-Key subsystem Response names. Response Name -------------- version status publickey attribute 6.5. Public-Key Subsystem Attribute Names Attributes are used to define properties or restrictions for public keys. The following table lists the initial assignments of Public- Key subsystem Attribute names. Galbraith, et al. Expires April 8, 2007 [Page 16] Internet-Draft Secure Shell Public-Key Subsystem October 2006 Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-forward reverse-forward 6.6. Public-Key subsystem Status Codes The status code is a byte value, describing the status of a request. 6.6.1. Conventions Status responses have status codes in the range 0 to 255. These numbers are allocated as follows. Of these, the range 192 to 255 is reserved for use by local, private extensions. 6.6.2. Initial Assignments The following table identifies the initial assignments of the Public- Key subsystem status code values. Status code Value Reference ------------ ----- --------- SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 6.6.3. Future Assignments Requests for assignments of new status codes in the range of 0 to 191 MUST be done through the Standards Action method as described in [10]. Galbraith, et al. Expires April 8, 2007 [Page 17] Internet-Draft Secure Shell Public-Key Subsystem October 2006 The IANA will not control the status code range of 192 through 255. This range will be left for private use. Galbraith, et al. Expires April 8, 2007 [Page 18] Internet-Draft Secure Shell Public-Key Subsystem October 2006 7. References 7.1. Normative References [1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 7.2. Informative References [8] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [9] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Galbraith, et al. Expires April 8, 2007 [Page 19] Internet-Draft Secure Shell Public-Key Subsystem October 2006 Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: jpv@vandyke.com Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: bdmccl@yahoo.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 Email: jon@siliconcircus.com Galbraith, et al. Expires April 8, 2007 [Page 20] Internet-Draft Secure Shell Public-Key Subsystem October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Galbraith, et al. Expires April 8, 2007 [Page 21] --------------050609080804000305080503-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 17:00:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVaKj-0000fw-9d for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 17:00:45 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVaKh-0004gN-FF for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 17:00:45 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 6404463B2DF; Thu, 5 Oct 2006 21:00:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by mail.netbsd.org (Postfix) with ESMTP id 64F4763B12E for ; Thu, 5 Oct 2006 21:00:24 +0000 (UTC) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id B62D2100CACF0 for ; Thu, 5 Oct 2006 14:54:53 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24564-63 for ; Thu, 5 Oct 2006 14:54:46 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id D3396100CACEF for ; Thu, 5 Oct 2006 14:54:46 -0400 (EDT) Received: from merlot.certicom.com ([10.24.0.140]) by certicom1.certicom.com (Lotus Domino Release 7.0.1) with ESMTP id 2006100514532102-53857 ; Thu, 5 Oct 2006 14:53:21 -0400 Subject: SSH in ECC Internet Draft From: Jon Green To: ietf-ssh@netbsd.org Organization: Certicom Date: Thu, 05 Oct 2006 14:54:45 -0400 Message-Id: <1160074485.7777.30.camel@merlot.certicom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/05/2006 02:53:21 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/05/2006 02:53:22 PM, Serialize complete at 10/05/2006 02:53:22 PM Content-Type: multipart/mixed; boundary="=-adGS9Jx+s4tV6EM5hT9m" Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bec09d1709ba59869cec93c1a1c207e5 --=-adGS9Jx+s4tV6EM5hT9m Content-Transfer-Encoding: 7bit Content-Type: text/plain In the interest of supporting the US government's Suite B cryptographic algorithms, we have updated an ECC in SSH draft written by D. Stabila (draft-stebila-secsh-ecdh-01) and have added Suite B algorithms, specifically MQV to the draft. This draft has been submitted to the IETF as an internet draft and I'm posting it on this list to solicit some review and to try to generate some interest. Any comments on the draft at all would be appreciated. Thanks -- Jon Green Research Intern Certicom Corp. --=-adGS9Jx+s4tV6EM5hT9m Content-Transfer-Encoding: 7bit Content-Type: text/plain; name=draft-green-secsh-ecc-00.txt; charset=us-ascii Content-Disposition: attachment; filename=draft-green-secsh-ecc-00.txt Secure Shell Working Group J. Green Internet-Draft Certicom Expires: April 8, 2007 D. Stebila U Waterloo October 5, 2006 Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer draft-green-secsh-ecc-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 8, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. Green & Stebila Expires April 8, 2007 [Page 1] Internet-Draft SSH ECC Algorithm Integration October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. ECC Public Key Algorithm [ssh-ecc] . . . . . . . . . . . . . . 5 3.1. Key/Signature Encoding . . . . . . . . . . . . . . . . . . 6 4. ECDH Parameter and Key Exchange [ecdh-exchange] . . . . . . . 7 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 8 5. ECMQV Key Exchange and Verification [ecmqv] . . . . . . . . . 10 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. ssh-ecc . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. ecdh-exchange . . . . . . . . . . . . . . . . . . . . . . 14 6.3. ecmqv . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 15 7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 15 7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Appendix A. Named Elliptic Curve Domain Parameters . . . . . . . 17 Appendix A.1. Required and Recommended Curves . . . . . . . . . . 17 Appendix A.2. Sending Lists of Curves . . . . . . . . . . . . . . 17 Appendix A.3. SEC Equivalent NIST Curves . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Green & Stebila Expires April 8, 2007 [Page 2] Internet-Draft SSH ECC Algorithm Integration October 2006 1. Introduction Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem for environments with limited bandwidth and computing power. Compared to currently prevalent cryptosystems such as RSA, DSA, and DH, ECC variations on these schemes offer equivalent security with smaller key sizes. This is illustrated in the following table, based on Section 5.6.1 of NIST 800-57 [11], which gives approximate comparable key sizes for symmetric- and asymmetric- key cryptosystems based on the best known algorithms for attacking them. L is field size and N is sub-field size. +-----------+-----------------------------+-------+---------+ | Symmetric | Discreet Log (eg. DSA, DH) | RSA | ECC | +-----------+-----------------------------+-------+---------+ | 80 | L = 1024 N = 160 | 1024 | 160-223 | | | | | | | 112 | L = 2048 N = 256 | 2048 | 224-255 | | | | | | | 128 | L = 3072 N = 256 | 3072 | 256-383 | | | | | | | 192 | L = 7680 N = 384 | 7680 | 384-511 | | | | | | | 256 | L = 15360 N = 512 | 15360 | 512+ | +-----------+-----------------------------+-------+---------+ Figure 1: Comparable key sizes (in bits). Smaller key sizes result in power, bandwidth, and computational savings that make ECC especially attractive for constrained environments. This document describes additions to the SSH transport layer to support the use of Elliptic Curve Digital Signature Algorithm (ECDSA) for message signing, Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) to establish a shared key. Implementation of this specification requires familiarity with both SSH [1] [2] [3] and ECC [4] [12] [13]. Comments on this draft are solicited and should be addressed to Jon Green . Green & Stebila Expires April 8, 2007 [Page 3] Internet-Draft SSH ECC Algorithm Integration October 2006 2. Requirements Notation 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 [6]. The data types boolean, uint32, uint64, string, and mpint are to be interpreted in this document as described in RFC 4251 [1]. This document uses Abstract Syntax Notation (ASN.1) define some communication. This is in keeping with current ECC standards. All ASN.1 variables are DER encoded before being sent. Information about the ASN.1 and DER can be found in ITU-T recommendation X.680 [7] and ITU-T recommendation X.690 [8]. Protocol fields and possible values to fill them in are defined in this set of documents. As an example SSH_MSG_KEX_ECDH_INIT is defined as follows. byte SSH_MSG_NUMBER string pK, public key octet string. Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill in those fields are referenced they will appear in double quotes. Green & Stebila Expires April 8, 2007 [Page 4] Internet-Draft SSH ECC Algorithm Integration October 2006 3. ECC Public Key Algorithm [ssh-ecc] The ECC public key algorithm defines ECC public keys, private keys and signatures for use within the SSH protocol. When ECC is chosen as the public key algorithm through key exchange negotiations the servers long term ECC key pair (host keys) are used for identification and verification. When asked to sign communications or verify signatures by the key exchange method the elliptic curve digital signature algorithm (ECDSA) is used. The algorithmic details of ECDSA can be found in Section 4 of SEC 1 [4] and in [15]. This document is concerned with the SSH implementation details, specification of the algorithm is left to other standards documents. The message hashing algorithm to be used with ECDSA is the same one specified to generate the exchange hash in the key exchange method chosen during algorithm negotiation. If the chosen key exchange method doesn't specify a hashing function then SHA-256 [9] will be used. The algorithm for ECC key generation can be found in section 3.2 of SEC 1 [4]. Given some elliptic curve domain parameters, an ECC key pair can be generated containing an integer d that is makes up the secret key and an elliptic curve point Q which makes up the public key. The elliptic curve domain parameters to generate EC keys can be produced at random, but this is a costly operation and may result in the use of domain parameters of which the security hasn't been tested. Because of this, standards bodies have produced named sets of elliptic curve domain parameters or named curves. Details of the curves required and recommended by this public key algorithm are outlined in Appendix A. The public key algorithm identifier specified for ECC is "ssh-ecc". This specification conforms to conventions for the SSH public key algorithm namespace [2] and must be approved by the IANA before it is put into use. Green & Stebila Expires April 8, 2007 [Page 5] Internet-Draft SSH ECC Algorithm Integration October 2006 3.1. Key/Signature Encoding The ECC public key and signature are sent in the standard encoding for ECC keys and signatures. This requires ASN.1 DER encoding which is specified in [7] and [8]. The ecc public key has the following encoding: string "ssh-ecc" ASN/DER SubjectPublicKeyInfo Here 'SubjectPublicKeyInfo' is defined as it is in Section C3 of SEC1 [4]. The ecdsa signature has the following encoding: string "ssh-ecc" ASN/DER ECDSA-Sig-Value Here the integers R and S that form the ECDSA signature are encapsulated in the ASN.1 field 'ECDSA-Sig-Value'. The field 'ECDSA- Sig-Value' is defined here as it is in Section C6 of SEC1 [4]. Green & Stebila Expires April 8, 2007 [Page 6] Internet-Draft SSH ECC Algorithm Integration October 2006 4. ECDH Parameter and Key Exchange [ecdh-exchange] 4.1. Description This section is an informal overview of the elliptic curve Diffie- Hellman (ECDH) key exchange mechanism. A formal description can be found in Section 4.2. The first stage of the ECDH key exchange mechanism is the exchange of elliptic curve domain parameters. Once the domain parameters are decided upon, both the client and server generate ephemeral EC key pairs, and exchange their ephemeral public keys. Using its own key pair and the other's public key both the client and the server derive the same shared secret key using ECDH. In the following: C is the client, S is the server; E_C is the client's list of supported curves; E_S is the server's list of supported curves; cPK is the client's ephemeral public key; sPK is the server's ephemeral public key; K_S is the server's public host key; H is the exchange hash; s is the signature on H; and K is the shared secret. 1. C and S send 'E_C' and 'E_S', lists ordered by preference (most to least) of named elliptic curve domain parameters. The first curve in 'E_C' that also appears in 'E_S' is the curve that will be used for ephemeral key generation. If there are no matching curves both sides MUST disconnect. 2. C chooses the curve it prefers most from from 'E_S' then generates an ephemeral elliptic curve public-key / private-key pair and sends the public-key value 'cPK'. 3. S MAY validate 'cPK' using for example algorithm A.16.10 of [12]. S chooses the first curve in 'E_C' it supports and uses it to generate an ephemeral public-key / private-key pair. S uses cPK and S's ephemeral private key value to compute the shared secret K using ECDH. S computes 'H' and the signature 's' on 'H' using its private host key. S sends "K_S || sPK || s". 4. C MAY validate S's public-key value using for example algorithm A.16.10 of [12]. C verifies that 'K_S' really is the public host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks. C uses 'sPK' and C's ephemeral private key to compute the shared secret and verifies the signature 's' on 'H'. Green & Stebila Expires April 8, 2007 [Page 7] Internet-Draft SSH ECC Algorithm Integration October 2006 The size of the selected curve SHOULD be greater than 160 bits, and preferably at least 224 bits. The size of the curve used SHOULD be in line with the bulk encryption algorithm chosen during algorithm negotiation. Appendix A contains more information about required and recommended curves. 4.2. Implementation This document is concerned with describing the implementation of ECDH in SSH, not the specification of the algorithm itself. The algorithm used for shared key generation is ECDH, the full specification of which can be found in Section 3.3.2 of SEC1 [4]. The algorithm for generation of EC key pairs can be found in Section 3.2 of SEC1 [4]. This algorithm is necessary to generate the ephemeral EC key pairs needed for ECDH. The elliptic curve points (ephemeral public keys) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in SEC1 Section 2.3 [4]. The hash algorithm for computing the exchange hash is determined by the size of the named curve chosen. The method for choosing a hash function can be seen in the table below where b is the size of the curve: +----------------+----------------+ | Curve Size | Hash Algorithm | +----------------+----------------+ | b <= 256 | SHA-256 | | | | | 256 < b <= 384 | SHA-384 | | | | | 384 < b | SHA-512 | +----------------+----------------+ Green & Stebila Expires April 8, 2007 [Page 8] Internet-Draft SSH ECC Algorithm Integration October 2006 Specification of the message numbers SSH_MSG_KEX_ECDH_REQUEST, SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are found in Section 7. The ECDH key exchange algorithm is implemented with the following messages. The public key algorithm for signing is negotiated with the KEXINIT messages. Both the client and server send: byte SSH_MSG_KEX_ECDH_REQUEST ASN/DER curves (E_C or E_S), the list of supported curves Information on the ASN.1 syntax used for curves can be found in Appendix A.2. The client sends: byte SSH_MSG_KEX_ECDH_INIT string cPK, the octet string formed from the client's ephemeral public key. The server responds with: byte SSH_MSG_KEX_ECDH_REPLY string K_S, server public host key and/or certificates string sPK, the octet string formed from the server's ephemeral public key. string s, the signature of H The hash H is computed as the HASH of the concatenation of the following. string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the server's public host key ASN/DER E_C, the client's supported curve list ASN/DER E_S, the server's supported curve list string cPK, the client's ephemeral public key octet string. string sPK, the server's ephemeral public key octet string. mpint K, the shared secret Green & Stebila Expires April 8, 2007 [Page 9] Internet-Draft SSH ECC Algorithm Integration October 2006 5. ECMQV Key Exchange and Verification [ecmqv] 5.1. Description The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key generation algorithm generates a shared secret from two elliptic curve key pairs owned by one entity and two elliptic curve public keys owned by another entity. Both entities roles are analogous in the algorithm. Using their own key pairs and the other entities public keys, both will derive the same secret. The following is an informal discussion of ECMQV key exchange and verification for a formal description see Section 5.2. The key exchange starts with the communication, from the server to the client, of the named curve that will be used for ephemeral key generation. The server and the client generate ephemeral key pairs, and exchange their public keys and use the ECMQV algorithm to derive the shared key. The client doesn't necessarily have a long term key under the existing SSH protocol. Instead of generating two ephemeral key pairs the client generates one ephemeral key pair and uses it for all the keys it is required to supply. This is illustrated below considering the ECMQV algorithm in terms of a black box: Local Keys |-----|-|-----| Remote Keys ECMQV Block: _______ Key Pair ----| |---- Public Key | ECMQV | Key Pair ----|_______|---- Public Key | shared secret Server Configuration: _______ Server Host Key ----| |---- Pair | ECMQV | |-- Client Ephemeral Server Ephemeral Key ----|_______|---- Public Key Pair | shared secret Client Configuration: _______ ----| |---- Server Public Host Key Client Ephemeral --| | ECMQV | Key Pair ----|_______|---- Server Ephemeral Public | Key shared secret Green & Stebila Expires April 8, 2007 [Page 10] Internet-Draft SSH ECC Algorithm Integration October 2006 In the following: C is the client; S is the server; curve is the curve used to generate the host key; K_S is the server's public host key; sPK is the server's ephemeral public key; cPK is the client's ephemeral public key; H is the exchange hash; T is the HMAC tag of H; and K is the shared secret. 1. S sends 'curve' containing the named curve that was used to generate its ECC host keys. 2. C OPTIONALLY verifies that the 'curve' has an acceptable level of security compared to the bulk encryption algorithm chosen during algorithm negotiation, a good reference for key strength comparison can be found in [11]. If C accepts 'curve' then it uses the associated domain parameters to generate an ephemeral ECC public/private key pair. C sends 'cPK'. 3. S MAY validate 'cPK' using, for example, algorithm A.16.10 of [12]. S generates an ephemeral public/private key pair using 'curve'. S then generates 'K' using its private hostkey, its private ephemeral key and 'cPK'. S computes 'H' (specified below) and the message authentication code (MAC) tag 'T' = HMAC(K,H). S then sends "K_S || sPK || T". 4. C MAY validate 'sPK' and 'K_S' as above. C verifies that 'K_S' really is the public host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks. C generates 'K' using its private ephemeral key, 'sPK' and 'K_S'. C independently computes 'H' and verifies the tag 'T' is valid for its 'H' and 'K'. We use a MAC tag with 'K' as a key for verification of communication with S because the private host key was used to create 'K', eliminating the need for a costly signing algorithm. 5.2. Implementation This document is concerned with describing the implementation of ECMQV in SSH, not the specification of the algorithm itself. A full description of ECMQV can be found in Section 3.4 of SEC1 [4]. An implementation of SSH supporting ECMQV MUST support the ECC Public Key Algorithm (Section 3). If during the key exchange algorithm negotiation ECMQV is chosen as the key exchange algorithm then "ssh- ecc" MUST be selected as the server host key algorithm. If "ssh-ecc" is not in the clients name-list then both sides MUST disconnect. Green & Stebila Expires April 8, 2007 [Page 11] Internet-Draft SSH ECC Algorithm Integration October 2006 ECMQV Key Exchange relies on the ECC public key algorithm to provide it with the necessary ECC server host key. ECMQV should support the same set of curves that the ECC public key algorithm supports. Required and recommended curve support is outlined in Appendix A. The server's host keys are used in shared key generation, therefore the named curve used to generate them is the curve that must be used by the ECMQV algorithm. Care should be taken that the server's host key is generated with sufficient strength to ensure that the ECMQV algorithm isn't the weakest point in the SSH encryption suite. The elliptic curve points (public keys) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in SEC1 Section 2.3 [4]. The hash algorithm for computing the exchange hash is determined by the strength of the named curve used by ECMQV. The method for choosing a hash function can be seen in the table below where b is the size of the curve: +----------------+----------------+ | Curve Size | Hash Algorithm | +----------------+----------------+ | b <= 256 | SHA-256 | | | | | 256 < b <= 384 | SHA-384 | | | | | 384 < b | SHA-512 | +----------------+----------------+ The hash function chosen above is also the hash function that is used to implement the HMAC used for server identification and varification. The algorithm for implementing HMAC with any of the above hash functions can be found in [10]. The specificiation of the message numbers SSH_MSG_ECMQV_KEYTYPE, SSH_MSG_ECMQV_INIT and SSH_MSG_ECMQV_REPLY can be found in Section 7. The algorithm for generation of EC key pairs can be found in SEC1 Section 3.2 [4]. This algorithm is necessary to generate the ephemeral EC key pairs needed for ECMQV. Green & Stebila Expires April 8, 2007 [Page 12] Internet-Draft SSH ECC Algorithm Integration October 2006 This key exchange algorithm is implemented with the following messages. The server sends: byte SSH_MSG_ECMQV_KEYTYPE ASN/DER curve Information on the ASN.1 syntax used for curve can be found in Appendix A. The client responds with: byte SSH_MSG_ECMQV_INIT string cPK, The octet string formed from the client's ephemeral public key. The server sends: byte SSH_MSG_ECMQV_REPLY string K_S, Server public host key octet string string sPK, Server ephemeral public key octet string string T, The HMAC tag computed on H using the shared secret The hash H is formed by applying the algorithm HASH on a concatenation of the following: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT ASN/DER curve, the named curve all the keys are based upon string cPK, client's ephemeral public key octet string K_S, server's public host key octet string sPK, server's ephemeral public key octet mpint K, the shared secret Green & Stebila Expires April 8, 2007 [Page 13] Internet-Draft SSH ECC Algorithm Integration October 2006 6. IANA Considerations This document defines two new key exchange method names and one new public key algorithm name in the SSH name registry. These additions to the SSH namespace will have to be approved by the IANA. New Key Exchange Algorithms: "ecmqv" "ecdh-exchange" New Host Key Algorithms: "ssh-ecc" 6.1. ssh-ecc The "ssh-ecc" method specifies Elliptic Curve digital signature algorithm (ECDSA) for use in signing communications with ECC host keys. When used with ECMQV "ssh-ecc" provides ecmqv with a host key. This method is discussed in Section 3. 6.2. ecdh-exchange The "ecdh-exchange" method specifies Elliptic Curve Diffie-Hellman with for key exchange as described in Section 4. 6.3. ecmqv The "ecmqv" method specifies the use of Elliptic Curve Menezes-Qu- Vanstone for Key Exchange as discussed in Section 5. Green & Stebila Expires April 8, 2007 [Page 14] Internet-Draft SSH ECC Algorithm Integration October 2006 7. Key Exchange Messages The message numbers 30-49 are key exchange-specific and in a private namespace defined in RFC4250 [3] that may be redefined by any key exchange method [2] without being granted IANA permission. The following message numbers have been defined in this document: 7.1. ECDH Message Numbers #define SSH_MSG_KEX_ECDH_REQUEST 30 #define SSH_MSG_KEX_ECDH_INIT 31 #define SSH_MSG_KEX_ECDH_REPLY 32 7.2. ECMQV Message Numbers #define SSH_MSG_ECMQV_KEYTYPE 30 #define SSH_MSG_ECMQV_INIT 31 #define SSH_MSG_ECMQV_REPLY 32 Green & Stebila Expires April 8, 2007 [Page 15] Internet-Draft SSH ECC Algorithm Integration October 2006 8. Security Considerations The Elliptic Curve Diffie-Hellman key agreement algorithm is defined in [4], [12] and [13]. The appropriate security considerations of those documents apply. The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is defined in [4]. The security considerations raised in that document also apply. A more detailed discussion of security considerations can be found in The Guide to Elliptic Curve Cryptography section 4.7 [16]. The methods defined in Section 4 rely on the SHA family of hashing functions as defined in [9]. The appropriate security considerations of that document apply. Additionally a good general discussion of the security considerations that must be taken into account when creating an ECC implementation can be found in The Guide to Elliptic Curve Cryptography section 5 [16]. Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and thus arbitrary security strength, it is important that the size of elliptic curve be chosen to match the security strength of other elements of the SSH handshake. In particular, host key sizes, hashing algorithms and bulk encryption algorithms must be chosen appropriately. Information regarding estimated equivalence of key sizes is available in [11]. Green & Stebila Expires April 8, 2007 [Page 16] Internet-Draft SSH ECC Algorithm Integration October 2006 Appendix A. Named Elliptic Curve Domain Parameters Implementations may support any ASN.1 object identifier (OID) in the ASN.1 object tree that defines a set of elliptic curve domain parameters. Curve is defined in ASN.1 syntax below. curve ::= OBJECT IDENTIFIER UNIQUE Appendix A.1. Required and Recommended Curves Every SSH ECC implementation MUST support the named curves below, these curves are defined in SEC2 [5]. secp256r1 sect283k1 secp384r1 sect409k1 It is RECOMMENDED that SSH ECC implementations also support the following curves. sect163k1 secp192r1 sect233k1 secp224r1 sect233r1 sect409r1 secp521r1 sect571k1 Appendix A.2. Sending Lists of Curves When lists of curves need to be sent to negotiate mutually supported curves they are sent as a sequence of unique ASN.1 OIDS. The ASN.1 syntax of this curve list is shown below. This ASN.1 syntax is encoded with DER and put into the appropriate packet. curves::= SEQUENCE SIZE (1 ... 12) OF { curve } Green & Stebila Expires April 8, 2007 [Page 17] Internet-Draft SSH ECC Algorithm Integration October 2006 Appendix A.3. SEC Equivalent NIST Curves +-----------+----------+ | SEC | NIST[14] | +-----------+----------+ | sect163k1 | nistk163 | | | | | secp192r1 | nistp192 | | | | | secp224r1 | nistp224 | | | | | sect233k1 | nistk233 | | | | | sect233r1 | nistb233 | | | | | secp256r1 | nistp256 | | | | | sect283k1 | nistk283 | | | | | secp384r1 | nistp384 | | | | | sect409k1 | nistk409 | | | | | sect409r1 | nistb409 | | | | | secp521r1 | nistp521 | | | | | sect571k1 | nistk571 | +-----------+----------+ OIDs for the above curves can be found in SEC2 Section A.2.1 and A.2.2 [5]. Green & Stebila Expires April 8, 2007 [Page 18] Internet-Draft SSH ECC Algorithm Integration October 2006 9. Acknowledgements The author would like to thank Douglas Stebila who wrote draft-stebila-secsh-ecdh-01, the ECDH portion of this draft is largely an updated version of his document. The author would also like to thank Robert Lambert of Certicom for all the help and knowledge he provided. This work was performed during an internship at Certicom from Queens University. Green & Stebila Expires April 8, 2007 [Page 19] Internet-Draft SSH ECC Algorithm Integration October 2006 10. References 10.1. Normative References [1] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Protocol Architecture", RFC 4251, January 2006. [2] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Transport Layer Protocol", RFC 4253, January 2006. [3] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell Protocol Assigned Numbers", RFC 4250, January 2006. [4] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, September 2000. [5] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2, September 2000. [6] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [7] Internation Telecommunication Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X. 680, July 2002. [8] Internation Telecommunication Union, "ASN.1 encoding rules", X. 690, July 2002. [9] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, August 2002. [10] National Institute of Standards and Technology, "Keyed-Hash Message Authentication Code", FIPS 198, March 2002. Green & Stebila Expires April 8, 2007 [Page 20] Internet-Draft SSH ECC Algorithm Integration October 2006 10.2. Informative References [11] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1", NIST Special Publication 800-57. [12] Institute of Electrical and Electronics Engineers, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000. [13] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: Key Agreement and key Transport Using Elliptic Curve Cryptography", ANSI X9.63, November 2001. [14] National Institute of Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", August 1999. [15] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry The Elliptic Curve Digital Signature Algorithm", ANSI X9.62, 1998. [16] Hankerson, Menezes, and Vanstone, "Guide to Elliptic Curve Cryptography", 2004, . Green & Stebila Expires April 8, 2007 [Page 21] Internet-Draft SSH ECC Algorithm Integration October 2006 Authors' Addresses Jon Green Certicom 5520 Explorer Drive 4th Floor Mississauga, ON L4W 5L1 Canada Email: jgreen@certicom.com Douglas Stebila Department of Combinatorics and Optimization University of Waterloo Waterloo, ON N2L 3G1 Canada Email: douglas@stebila.ca Green & Stebila Expires April 8, 2007 [Page 22] Internet-Draft SSH ECC Algorithm Integration October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Green & Stebila Expires April 8, 2007 [Page 23] --=-adGS9Jx+s4tV6EM5hT9m-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 18:27:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVbgV-000383-6f for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 18:27:19 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVbgT-000494-Be for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 18:27:19 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id D8D6063B646; Thu, 5 Oct 2006 22:27:14 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 69D4963B10F for ; Thu, 5 Oct 2006 22:27:13 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA09189; Thu, 5 Oct 2006 18:27:10 -0400 (EDT) From: der Mouse Message-Id: <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 5 Oct 2006 17:56:13 -0400 (EDT) To: ietf-ssh@NetBSD.org Cc: Jon Green Subject: Re: SSH in ECC Internet Draft In-Reply-To: <1160074485.7777.30.camel@merlot.certicom.com> References: <1160074485.7777.30.camel@merlot.certicom.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Most of my comments will be copy-edit remarks, because I do not know enough about elliptic-curve crypto to say anything intelligent about that. (I hope to someday dig up the info, but the references you give are mostly things I don't currently know how to find.) This document specifies many packet fields as having type "ASN/DER". I'd prefer to see it spelled out more precisely what this means. Does it mean that the DER-produced octet string is exaclty what appears in the packet at that point? Does it mean that the packet contains a "string" which contains the DER-produced octet string? Something else? > +-----------+-----------------------------+-------+---------+ > | Symmetric | Discreet Log (eg. DSA, DH) | RSA | ECC | > +-----------+-----------------------------+-------+---------+ ITYPM "Discrete". This table is also meaningless unless accompanied by a way of comparing the amount of computation demanded by, say, a 240-bit elliptic curve key with the computation demanded by a 2048-bit RSA key. > Protocol fields and possible values to fill them in are defined in > this set of documents. As an example SSH_MSG_KEX_ECDH_INIT is > defined as follows. >=20 > byte SSH_MSG_NUMBER > string pK, public key octet string. s/MSG_NUMBER/MSG_KEX_ECDH_INIT/ surely? > as the public key algorithm through key exchange negotiations the > servers long term ECC key pair (host keys) are used for > identification and verification. s/servers/server's/ and s/are/is/ ("key pair" is singular). > the SSH implementation details, specification of the algorithm is s/,/;/ > public keys. Using its own key pair and the other's public key both > the client and the server derive the same shared secret key using > ECDH. s/key both/key, both/ > 3. S MAY validate 'cPK' using for example algorithm A.16.10 of [12]= . s/ for example/,&,/ > The size of the selected curve SHOULD be greater than 160 bits, and > preferably at least 224 bits. The size of the curve used SHOULD be Either s/,// or s/ and// here. > Specification of the message numbers SSH_MSG_KEX_ECDH_REQUEST, > SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are found in > Section 7. s/are/is/ (or s/Specification/&s/). > another entity. Both entities roles are analogous in the algorithm. > Using their own key pairs and the other entities public keys, both s/entities/&'/ on each line. > The following is an informal discussion of ECMQV key exchange and > verification for a formal description see Section 5.2. s/ for /;&/ > is not in the clients name-list then both sides MUST disconnect. s/clients/client's/ > The server's host keys are used in shared key generation, therefore s/, therefore/; therefore,/ > key is generated with sufficient strength to ensure that the ECMQV s/generated with sufficient strength to ensure/sufficiently strong/ > 6.1. ssh-ecc >=20 > The "ssh-ecc" method specifies Elliptic Curve digital signature > algorithm (ECDSA) for use in signing communications with ECC host > keys. When used with ECMQV "ssh-ecc" provides ecmqv with a host key= . > This method is discussed in Section 3. This makes it sound as though ssh-ecc host keys and ecmqv key exchange are not independent - that it is not possile to use one without the other. If true, I think this is a bad idea, if only because the negotiation framework does not support this kind of tied negotiation. > When lists of curves need to be sent to negotiate mutually supported > curves they are sent as a sequence of unique ASN.1 OIDS. The ASN.1 Why is there a hard limit on the size of a list of curves, especially a limit that's a magic number like 12? Surely it would be better to leave this extensible? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 18:51:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVc45-0007k4-DL for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 18:51:41 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVc42-0003qR-GB for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 18:51:41 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 33D1263B326; Thu, 5 Oct 2006 22:51:36 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 6258863B179 for ; Thu, 5 Oct 2006 22:51:35 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1GVc3y-00019h-00 for ietf-ssh@netbsd.org; Thu, 05 Oct 2006 23:51:34 +0100 From: Ben Harris To: ietf-ssh@netbsd.org Subject: Re: SSH in ECC Internet Draft In-Reply-To: <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> References: <1160074485.7777.30.camel@merlot.certicom.com> <1160074485.7777.30.camel@merlot.certicom.com> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Cc: Message-Id: Date: Thu, 05 Oct 2006 23:51:34 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 In article <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> you write: >> 6.1. ssh-ecc >> >> The "ssh-ecc" method specifies Elliptic Curve digital signature >> algorithm (ECDSA) for use in signing communications with ECC host >> keys. When used with ECMQV "ssh-ecc" provides ecmqv with a host key. >> This method is discussed in Section 3. > >This makes it sound as though ssh-ecc host keys and ecmqv key exchange >are not independent - that it is not possile to use one without the >other. If true, I think this is a bad idea, if only because the >negotiation framework does not support this kind of tied negotiation. Actually, in this case, we already have that kind of tied negotiation. SSH already supports the notions of signature-capable and encryption-capable host keys, and the choice of public-key algorithm depends on the selected public-key algorithm. This effectively adds an third key type to that algorithm. It might be a good idea for this to be done more explicitly (perhaps allowing for the possibility of other ECC key formats), but I don't see that there's anything inherently wrong with it. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 19:47:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVcw9-0005Uv-8z for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 19:47:33 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVcw7-0005ff-S2 for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 19:47:33 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 9924D63B676; Thu, 5 Oct 2006 23:47:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 6ABFB63B67E for ; Thu, 5 Oct 2006 23:47:15 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1GVcvq-0000Tm-00; Fri, 06 Oct 2006 00:47:14 +0100 From: Ben Harris To: jgreen@certicom.com Subject: Re: SSH in ECC Internet Draft In-Reply-To: <1160074485.7777.30.camel@merlot.certicom.com> References: <1160074485.7777.30.camel@merlot.certicom.com> Organization: Linux Unlimited Cc: ietf-ssh@netbsd.org Message-Id: Date: Fri, 06 Oct 2006 00:47:14 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Like der Mouse I currently know little about ECC, but I've got a few comments nonetheless. In article <1160074485.7777.30.camel@merlot.certicom.com> you write: >3.1. Key/Signature Encoding > > The ECC public key and signature are sent in the standard encoding > for ECC keys and signatures. This requires ASN.1 DER encoding which > is specified in [7] and [8]. Using ASN.1 worries me a little, given the rate at which security holes are found in ASN.1 decoders. > The ecc public key has the following encoding: > > string "ssh-ecc" > ASN/DER SubjectPublicKeyInfo > > Here 'SubjectPublicKeyInfo' is defined as it is in Section C3 of SEC1 > [4]. Conventionally, key format names beginning "ssh-" have been used for key formats invented specifically for SSH, while other names have been used for key formats imported from elsewhere. Thus I'd suggest using a name not starting with "ssh-" here, say "sec1-ecc". >4.2. Implementation > +----------------+----------------+ > | Curve Size | Hash Algorithm | > +----------------+----------------+ > | b <= 256 | SHA-256 | > | | | > | 256 < b <= 384 | SHA-384 | > | | | > | 384 < b | SHA-512 | > +----------------+----------------+ You should cite [9] here as a reference for SHA-256 etc. > The hash H is computed as the HASH of the concatenation of the > following. You haven't defined HASH here. >5.1. Description > 2. C OPTIONALLY verifies that the 'curve' has an acceptable level of > security compared to the bulk encryption algorithm chosen during > algorithm negotiation, a good reference for key strength > comparison can be found in [11]. If C accepts 'curve' then it > uses the associated domain parameters to generate an ephemeral > ECC public/private key pair. What does it do if it doesn't accept 'curve'? >5.2. Implementation > +----------------+----------------+ > | Curve Size | Hash Algorithm | > +----------------+----------------+ > | b <= 256 | SHA-256 | > | | | > | 256 < b <= 384 | SHA-384 | > | | | > | 384 < b | SHA-512 | > +----------------+----------------+ Again, cite [9]... > The hash H is formed by applying the algorithm HASH on a > concatenation of the following: And define HASH (or just refer to "the exchange hash algorithm"). >9. Acknowledgements > > The author would like to thank Douglas Stebila who wrote > draft-stebila-secsh-ecdh-01, the ECDH portion of this draft is > largely an updated version of his document. Douglas Stebila is one of the authors -- it seems odd for him to be thanking himself. > [4] Standards for Efficient Cryptography Group, "Elliptic Curve > Cryptography", SEC 1, September 2000. > > [5] Standards for Efficient Cryptography Group, "Recommended > Elliptic Curve Domain Parameters", SEC 2, September 2000. SECG standards seem to have version numbers -- it might be worth quoting them here. > [6] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement > Levels", RFC 2119, March 1997. RFCs are usually listed before other references. > [7] Internation Telecommunication Union, "Abstract Syntax Notation > One (ASN.1): Specification of basic notation", X. 680, > July 2002. > > [8] Internation Telecommunication Union, "ASN.1 encoding rules", > X. 690, July 2002. That's "International", "X.680" (no space), "X.690", and "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", according to the ITU Web site. > [10] National Institute of Standards and Technology, "Keyed-Hash > Message Authentication Code", FIPS 198, March 2002. Is there any good reason not to reference RFC 2104 instead of FIPS 198? -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 05 22:01:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVf1K-0001Qj-CV for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 22:01:02 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVf1H-0007SW-1y for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 05 Oct 2006 22:01:02 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id ADA4363B559; Fri, 6 Oct 2006 02:00:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by mail.netbsd.org (Postfix) with ESMTP id 9479863B131 for ; Fri, 6 Oct 2006 02:00:41 +0000 (UTC) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k960pHIq025119 for ; Thu, 5 Oct 2006 20:51:17 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9raW9W; Thu, 5 Oct 06 20:50:47 -0400 Received: from localhost (localhost.tislabs.com [127.0.0.1]) by pecan.tislabs.com (Postfix) with ESMTP id 24DCA3F496; Thu, 5 Oct 2006 18:44:47 -0400 (EDT) Date: Fri, 6 Oct 2006 00:45:46 +0200 (CEST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Jon Bright cc: galb-list@vandyke.com, jpv@vandyke.com, ietf-ssh@netbsd.org Subject: Re: secdir review of draft-ietf-secsh-publickey-subsystem-07.txt In-Reply-To: <452526EA.9000606@siliconcircus.com> Message-ID: References: <452526EA.9000606@siliconcircus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad >> Section 4.1: It's not clear to me whether the "from" list contains >> hostnames, IP addrs, or ...? Perhaps be a bit more specific. > > I've added the following text: "For IP-based networks, it is anticipated that > the "from" parameter will take the form of a specific IP address or > hostname." Only a single one? No lists? The rest of the changes sound good. Thank you. -- Sam From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 06 15:50:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVvic-0007Kj-OP for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 06 Oct 2006 15:50:50 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVvib-0004aD-9m for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 06 Oct 2006 15:50:50 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 013EA63B7B8; Fri, 6 Oct 2006 19:50:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by mail.netbsd.org (Postfix) with ESMTP id EB5F363B7A8 for ; Fri, 6 Oct 2006 19:50:32 +0000 (UTC) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1A77726E60; Fri, 6 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVvhp-00021Z-Sr; Fri, 06 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickey-subsystem-08.txt Message-Id: Date: Fri, 06 Oct 2006 15:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Secure Shell Public-Key Subsystem Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-publickey-subsystem-08.txt Pages : 21 Date : 2006-10-6 Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickey-subsystem-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-6102919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-6102919.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 06 17:25:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVxC8-0003aa-Gj for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 06 Oct 2006 17:25:24 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVxC5-0005Xe-HC for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 06 Oct 2006 17:25:24 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 79B3063B817; Fri, 6 Oct 2006 21:25:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by mail.netbsd.org (Postfix) with ESMTP id 5AFE563B2AE for ; Fri, 6 Oct 2006 21:24:58 +0000 (UTC) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 84607100EAE1C for ; Fri, 6 Oct 2006 17:24:54 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06088-45 for ; Fri, 6 Oct 2006 17:24:50 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id DEC1F100D6DBE for ; Fri, 6 Oct 2006 17:24:50 -0400 (EDT) Received: from merlot.certicom.com ([10.24.0.140]) by certicom1.certicom.com (Lotus Domino Release 7.0.1) with ESMTP id 2006100617232482-59164 ; Fri, 6 Oct 2006 17:23:24 -0400 Subject: Re: SSH in ECC Internet Draft From: Jon Green To: ietf-ssh@netbsd.org In-Reply-To: <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> References: <1160074485.7777.30.camel@merlot.certicom.com> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> Organization: Certicom Date: Fri, 06 Oct 2006 17:24:49 -0400 Message-Id: <1160169889.16989.25.camel@merlot.certicom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/06/2006 05:23:24 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/06/2006 05:23:25 PM, Serialize complete at 10/06/2006 05:23:25 PM Content-Type: multipart/mixed; boundary="=-UDTzM78g2LM7c+A50SoZ" Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e757c5fc4111242d37629bd94b9648e7 --=-UDTzM78g2LM7c+A50SoZ Content-Transfer-Encoding: 7bit Content-Type: text/plain > > +-----------+-----------------------------+-------+---------+ > > | Symmetric | Discreet Log (eg. DSA, DH) | RSA | ECC | > > +-----------+-----------------------------+-------+---------+ > This table is also meaningless unless accompanied by a way of comparing > the amount of computation demanded by, say, a 240-bit elliptic curve > key with the computation demanded by a 2048-bit RSA key. Computation to do what? (Create the key, crack the key) I'm not really sure what your suggesting I do here. The reference I provide goes into great detail about how their key comparisons are done. > > When lists of curves need to be sent to negotiate mutually supported > > curves they are sent as a sequence of unique ASN.1 OIDS. The ASN.1 > > Why is there a hard limit on the size of a list of curves, especially a > limit that's a magic number like 12? Surely it would be better to > leave this extensible? > This was a bit of a cop out because I was unable to find a way to specify in ASN.1 syntax how to not put an upper limit on a sequence. I've updated the specification to be: curves::= SEQUENCE SIZE (1 ... MAX) OF { curve } Other RFC's seem to specify unbounded sequences like this, without ever defining MAX, but I don't like leaving MAX undefined, since it doesn't seem to be part of the ASN specification. Can anyone tell me if this is correct? > >3.1. Key/Signature Encoding > > > > The ECC public key and signature are sent in the standard encoding > > for ECC keys and signatures. This requires ASN.1 DER encoding > which > > is specified in [7] and [8]. > > Using ASN.1 worries me a little, given the rate at which security > holes > are found in ASN.1 decoders. > I understand your concerns, and I do share them, but as far as I know the SSL ASN code is being rewritten. Honestly I don't like using ASN.1 at all, but I feel its a necessary evil to stay compliant with ECC standards, which I think is more important then software that will be rewritten. > > The ecc public key has the following encoding: > > > > string "ssh-ecc" > > ASN/DER SubjectPublicKeyInfo > > > > Here 'SubjectPublicKeyInfo' is defined as it is in Section C3 of > SEC1 > > [4]. > > Conventionally, key format names beginning "ssh-" have been used for > key > formats invented specifically for SSH, while other names have been > used > for key formats imported from elsewhere. Thus I'd suggest using a > name > not starting with "ssh-" here, say "sec1-ecc". Are you suggesting changing the name of the public key algorithm to sec1-ecc, or just the string sent before the key itself? All the current RFCs (as far as I know) send the same string with the key as the public key algorithm it will be used with. Is it going to be a problem to send a different string with the key? Should the string sent before the signature be changed as well? > Is there any good reason not to reference RFC 2104 instead of FIPS > 198? I didn't realize there was a RFC, I also found a RFC for the SHA series of hash functions, so I changed that reference to a RFC. Thanks for all the comments, keep them coming! Anything I didn't mention here got changed. I've attached a updated version to this email. Cheers -- Jon Green Research Intern Certicom Corp. --=-UDTzM78g2LM7c+A50SoZ Content-Transfer-Encoding: 7bit Content-Type: text/plain; name=draft-green-secsh-ecc-00.txt; charset=us-ascii Content-Disposition: attachment; filename=draft-green-secsh-ecc-00.txt Secure Shell Working Group J. Green Internet-Draft Certicom Expires: April 9, 2007 D. Stebila U Waterloo October 6, 2006 Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer draft-green-secsh-ecc-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 9, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. Green & Stebila Expires April 9, 2007 [Page 1] Internet-Draft SSH ECC Algorithm Integration October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ECC Public Key Algorithm [ssh-ecc] . . . . . . . . . . . . . . 5 3.1. Key/Signature Encoding . . . . . . . . . . . . . . . . . . 6 4. ECDH Parameter and Key Exchange [ecdh-exchange] . . . . . . . 7 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 8 5. ECMQV Key Exchange and Verification [ecmqv] . . . . . . . . . 10 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. ssh-ecc . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. ecdh-exchange . . . . . . . . . . . . . . . . . . . . . . 14 6.3. ecmqv . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 15 7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 15 7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Appendix A. Named Elliptic Curve Domain Parameters . . . . . . . 17 Appendix A.1. Required and Recommended Curves . . . . . . . . . . 17 Appendix A.2. Sending Lists of Curves . . . . . . . . . . . . . . 17 Appendix A.3. SEC Equivalent NIST Curves . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Green & Stebila Expires April 9, 2007 [Page 2] Internet-Draft SSH ECC Algorithm Integration October 2006 1. Introduction Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem for environments with limited bandwidth and computing power. Compared to currently prevalent cryptosystems such as RSA, DSA, and DH, ECC variations on these schemes offer equivalent security with smaller key sizes. This is illustrated in the following table, based on Section 5.6.1 of NIST 800-57 [10], which gives approximate comparable key sizes for symmetric- and asymmetric- key cryptosystems based on the best known algorithms for attacking them. L is field size and N is sub-field size. +-----------+-----------------------------+-------+---------+ | Symmetric | Discrete Log (eg. DSA, DH) | RSA | ECC | +-----------+-----------------------------+-------+---------+ | 80 | L = 1024 N = 160 | 1024 | 160-223 | | | | | | | 112 | L = 2048 N = 256 | 2048 | 224-255 | | | | | | | 128 | L = 3072 N = 256 | 3072 | 256-383 | | | | | | | 192 | L = 7680 N = 384 | 7680 | 384-511 | | | | | | | 256 | L = 15360 N = 512 | 15360 | 512+ | +-----------+-----------------------------+-------+---------+ Figure 1: Comparable key sizes (in bits). Smaller key sizes result in power, bandwidth, and computational savings that make ECC especially attractive for constrained environments. This document describes additions to the SSH transport layer to support the use of Elliptic Curve Digital Signature Algorithm (ECDSA) for message signing, Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) to establish a shared key. Implementation of this specification requires familiarity with both SSH [2] [3] [4] and ECC [6] [11] [12]. Green & Stebila Expires April 9, 2007 [Page 3] Internet-Draft SSH ECC Algorithm Integration October 2006 2. Notation 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 [1]. The data types boolean, uint32, uint64, string, and mpint are to be interpreted in this document as described in RFC 4251 [2]. This document uses Abstract Syntax Notation (ASN.1) define some communication. This is in keeping with current ECC standards. All ASN.1 variables are DER encoded before being sent. Information about the ASN.1 and DER can be found in ITU-T recommendation X.680 [8] and ITU-T recommendation X.690 [9]. The data type ASN/DER represents an arbitrary length octet string which is the output of DER encoding the ASN.1 variable. Protocol fields and possible values to fill them in are defined in this set of documents. As an example SSH_MSG_KEX_ECDH_INIT is defined as follows. byte SSH_MSG_KEX_ECDH_INIT string pK, public key octet string. Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill in those fields are referenced they will appear in double quotes. Green & Stebila Expires April 9, 2007 [Page 4] Internet-Draft SSH ECC Algorithm Integration October 2006 3. ECC Public Key Algorithm [ssh-ecc] The ECC public key algorithm defines ECC public keys, private keys and signatures for use within the SSH protocol. When ECC is chosen as the public key algorithm through key exchange negotiations the server's long term ECC key pair (host keys) is used for identification and verification. When asked to sign communications or verify signatures by the key exchange method the elliptic curve digital signature algorithm (ECDSA) is used. The algorithmic details of ECDSA can be found in Section 4 of SEC 1 [6] and in [14]. This document is concerned with the SSH implementation details; specification of the algorithm is left to other standards documents. The message hashing algorithm to be used with ECDSA is the same one specified to generate the exchange hash in the key exchange method chosen during algorithm negotiation. If the chosen key exchange method doesn't specify a hashing function then SHA-256 [5] will be used. The algorithm for ECC key generation can be found in section 3.2 of SEC 1 [6]. Given some elliptic curve domain parameters, an ECC key pair can be generated containing an integer d that is makes up the secret key and an elliptic curve point Q which makes up the public key. The elliptic curve domain parameters to generate EC keys can be produced at random, but this is a costly operation and may result in the use of domain parameters of which the security hasn't been tested. Because of this, standards bodies have produced named sets of elliptic curve domain parameters or named curves. Details of the curves required and recommended by this public key algorithm are outlined in Appendix A. The public key algorithm identifier specified for ECC is "ssh-ecc". This specification conforms to conventions for the SSH public key algorithm namespace [3] and must be approved by the IANA before it is put into use. Green & Stebila Expires April 9, 2007 [Page 5] Internet-Draft SSH ECC Algorithm Integration October 2006 3.1. Key/Signature Encoding The ECC public key and signature are sent in the standard encoding for ECC keys and signatures. This requires ASN.1 DER encoding which is specified in [8] and [9]. The ecc public key has the following encoding: string "ssh-ecc" ASN/DER SubjectPublicKeyInfo Here 'SubjectPublicKeyInfo' is defined as it is in Section C3 of SEC1 [6]. The ecdsa signature has the following encoding: string "ssh-ecc" ASN/DER ECDSA-Sig-Value Here the integers R and S that form the ECDSA signature are encapsulated in the ASN.1 field 'ECDSA-Sig-Value'. The field 'ECDSA- Sig-Value' is defined here as it is in Section C6 of SEC1 [6]. Green & Stebila Expires April 9, 2007 [Page 6] Internet-Draft SSH ECC Algorithm Integration October 2006 4. ECDH Parameter and Key Exchange [ecdh-exchange] 4.1. Description This section is an informal overview of the elliptic curve Diffie- Hellman (ECDH) key exchange mechanism. A formal description can be found in Section 4.2. The first stage of the ECDH key exchange mechanism is the exchange of elliptic curve domain parameters. Once the domain parameters are decided upon, both the client and server generate ephemeral EC key pairs, and exchange their ephemeral public keys. Using its own key pair and the other's public key, both the client and the server derive the same shared secret key using ECDH. In the following: C is the client, S is the server; E_C is the client's list of supported curves; E_S is the server's list of supported curves; cPK is the client's ephemeral public key; sPK is the server's ephemeral public key; K_S is the server's public host key; H is the exchange hash; s is the signature on H; and K is the shared secret. 1. C and S send 'E_C' and 'E_S', lists ordered by preference (most to least) of named elliptic curve domain parameters. The first curve in 'E_C' that also appears in 'E_S' is the curve that will be used for ephemeral key generation. If there are no matching curves both sides MUST disconnect. 2. C chooses the curve it prefers most from from 'E_S' then generates an ephemeral elliptic curve public-key / private-key pair and sends the public-key value 'cPK'. 3. S MAY validate 'cPK' using, for example, algorithm A.16.10 of [11]. S chooses the first curve in 'E_C' it supports and uses it to generate an ephemeral public-key / private-key pair. S uses cPK and S's ephemeral private key value to compute the shared secret K using ECDH. S computes 'H' and the signature 's' on 'H' using its private host key. S sends "K_S || sPK || s". 4. C MAY validate S's public-key value using, for example, algorithm A.16.10 of [11]. C verifies that 'K_S' really is the public host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks. C uses 'sPK' and C's ephemeral private key to compute the shared secret and verifies the signature 's' on 'H'. Green & Stebila Expires April 9, 2007 [Page 7] Internet-Draft SSH ECC Algorithm Integration October 2006 The size of the selected curve SHOULD be greater than 160 bits and preferably at least 224 bits. The size of the curve used SHOULD be in line with the bulk encryption algorithm chosen during algorithm negotiation. Appendix A contains more information about required and recommended curves. 4.2. Implementation This document is concerned with describing the implementation of ECDH in SSH, not the specification of the algorithm itself. The algorithm used for shared key generation is ECDH, the full specification of which can be found in Section 3.3.2 of SEC1 [6]. The algorithm for generation of EC key pairs can be found in Section 3.2 of SEC1 [6]. This algorithm is necessary to generate the ephemeral EC key pairs needed for ECDH. The elliptic curve points (ephemeral public keys) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in SEC1 Section 2.3 [6]. The hash algorithm HASH for computing the exchange hash is determined by the size of the named curve chosen. The method for choosing a hash function can be seen in the table below where b is the size of the curve [5]: +----------------+----------------+ | Curve Size | Hash Algorithm | +----------------+----------------+ | b <= 256 | SHA-256 | | | | | 256 < b <= 384 | SHA-384 | | | | | 384 < b | SHA-512 | +----------------+----------------+ Specification of the message numbers SSH_MSG_KEX_ECDH_REQUEST, SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY is found in Section 7. Green & Stebila Expires April 9, 2007 [Page 8] Internet-Draft SSH ECC Algorithm Integration October 2006 The ECDH key exchange algorithm is implemented with the following messages. The public key algorithm for signing is negotiated with the KEXINIT messages. Both the client and server send: byte SSH_MSG_KEX_ECDH_REQUEST ASN/DER curves (E_C or E_S), the list of supported curves Information on the ASN.1 syntax used for curves can be found in Appendix A.2. The client sends: byte SSH_MSG_KEX_ECDH_INIT string cPK, the octet string formed from the client's ephemeral public key. The server responds with: byte SSH_MSG_KEX_ECDH_REPLY string K_S, server public host key and/or certificates string sPK, the octet string formed from the server's ephemeral public key. string s, the signature of H The hash H is computed as the HASH of the concatenation of the following. string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the server's public host key ASN/DER E_C, the client's supported curve list ASN/DER E_S, the server's supported curve list string cPK, the client's ephemeral public key octet string. string sPK, the server's ephemeral public key octet string. mpint K, the shared secret Green & Stebila Expires April 9, 2007 [Page 9] Internet-Draft SSH ECC Algorithm Integration October 2006 5. ECMQV Key Exchange and Verification [ecmqv] 5.1. Description The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key generation algorithm generates a shared secret from two elliptic curve key pairs owned by one entity and two elliptic curve public keys owned by another entity. Both entities' roles are analogous in the algorithm. Using it's key pairs and the other entity's public keys, both entities' will derive the same secret. The following is an informal discussion of ECMQV key exchange and verification for a formal description see Section 5.2. The key exchange starts with the communication, from the server to the client, of the named curve that will be used for ephemeral key generation. The server and the client generate ephemeral key pairs, and exchange their public keys and use the ECMQV algorithm to derive the shared key. The client doesn't necessarily have a long term key under the existing SSH protocol. Instead of generating two ephemeral key pairs the client generates one ephemeral key pair and uses it for all the keys it is required to supply. This is illustrated below considering the ECMQV algorithm in terms of a black box: Local Keys |-----|-|-----| Remote Keys ECMQV Block: _______ Key Pair ----| |---- Public Key | ECMQV | Key Pair ----|_______|---- Public Key | shared secret Server Configuration: _______ Server Host Key ----| |---- Pair | ECMQV | |-- Client Ephemeral Server Ephemeral Key ----|_______|---- Public Key Pair | shared secret Client Configuration: _______ ----| |---- Server Public Host Key Client Ephemeral --| | ECMQV | Key Pair ----|_______|---- Server Ephemeral Public | Key shared secret Green & Stebila Expires April 9, 2007 [Page 10] Internet-Draft SSH ECC Algorithm Integration October 2006 In the following: C is the client; S is the server; curve is the curve used to generate the host key; K_S is the server's public host key; sPK is the server's ephemeral public key; cPK is the client's ephemeral public key; H is the exchange hash; T is the HMAC tag of H; and K is the shared secret. 1. S sends 'curve' containing the named curve that was used to generate its ECC host keys. 2. C OPTIONALLY verifies that the 'curve' has an acceptable level of security compared to the bulk encryption algorithm chosen during algorithm negotiation, a good reference for key strength comparison can be found in [10]. If C accepts 'curve' then it uses the associated domain parameters to generate an ephemeral ECC public/private key pair. C sends 'cPK'. If C rejects 'curve' then it sends a disconnection packet and drops the connection. 3. S MAY validate 'cPK' using, for example, algorithm A.16.10 of [11]. S generates an ephemeral public/private key pair using 'curve'. S then generates 'K' using its private hostkey, its private ephemeral key and 'cPK'. S computes 'H' (specified below) and the message authentication code (MAC) tag 'T' = HMAC(K,H). S then sends "K_S || sPK || T". 4. C MAY validate 'sPK' and 'K_S' as above. C verifies that 'K_S' really is the public host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks. C generates 'K' using its private ephemeral key, 'sPK' and 'K_S'. C independently computes 'H' and verifies the tag 'T' is valid for its 'H' and 'K'. We use a MAC tag with 'K' as a key for verification of communication with S because the private host key was used to create 'K', eliminating the need for a costly signing algorithm. 5.2. Implementation This document is concerned with describing the implementation of ECMQV in SSH, not the specification of the algorithm itself. A full description of ECMQV can be found in Section 3.4 of SEC1 [6]. An implementation of SSH supporting ECMQV MUST support the ECC Public Key Algorithm (Section 3). If during the key exchange algorithm negotiation ECMQV is chosen as the key exchange algorithm then "ssh- ecc" MUST be selected as the server host key algorithm. If "ssh-ecc" is not in the client's name-list then both sides MUST disconnect. Green & Stebila Expires April 9, 2007 [Page 11] Internet-Draft SSH ECC Algorithm Integration October 2006 ECMQV Key Exchange relies on the ECC public key algorithm to provide it with the necessary ECC server host key. ECMQV should support the same set of curves that the ECC public key algorithm supports. Required and recommended curve support is outlined in Appendix A. The server's host keys are used in shared key generation; therefore, the named curve used to generate them is the curve that must be used by the ECMQV algorithm. Care should be taken that the server's host key is sufficiently strong to ensure that the ECMQV algorithm isn't the weakest point in the SSH encryption suite. The elliptic curve points (public keys) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in SEC1 Section 2.3 [6]. The hash algorithm HASH for computing the exchange hash is determined by the strength of the named curve used by ECMQV. The method for choosing a hash function can be seen in the table below where b is the size of the curve [5]: +----------------+----------------+ | Curve Size | Hash Algorithm | +----------------+----------------+ | b <= 256 | SHA-256 | | | | | 256 < b <= 384 | SHA-384 | | | | | 384 < b | SHA-512 | +----------------+----------------+ The hash function chosen above is also the hash function that is used to implement the HMAC used for server identification and varification. The algorithm for implementing HMAC with any of the above hash functions can be found in [5]. The specificiation of the message numbers SSH_MSG_ECMQV_KEYTYPE, SSH_MSG_ECMQV_INIT and SSH_MSG_ECMQV_REPLY can be found in Section 7. The algorithm for generation of EC key pairs can be found in SEC1 Section 3.2 [6]. This algorithm is necessary to generate the ephemeral EC key pairs needed for ECMQV. Green & Stebila Expires April 9, 2007 [Page 12] Internet-Draft SSH ECC Algorithm Integration October 2006 This key exchange algorithm is implemented with the following messages. The server sends: byte SSH_MSG_ECMQV_KEYTYPE ASN/DER curve Information on the ASN.1 syntax used for curve can be found in Appendix A. The client responds with: byte SSH_MSG_ECMQV_INIT string cPK, The octet string formed from the client's ephemeral public key. The server sends: byte SSH_MSG_ECMQV_REPLY string K_S, Server public host key octet string string sPK, Server ephemeral public key octet string string T, The HMAC tag computed on H using the shared secret The hash H is formed by applying the algorithm HASH on a concatenation of the following: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT ASN/DER curve, the named curve all the keys are based upon string cPK, client's ephemeral public key octet string K_S, server's public host key octet string sPK, server's ephemeral public key octet mpint K, the shared secret Green & Stebila Expires April 9, 2007 [Page 13] Internet-Draft SSH ECC Algorithm Integration October 2006 6. IANA Considerations This document defines two new key exchange method names and one new public key algorithm name in the SSH name registry. These additions to the SSH namespace will have to be approved by the IANA. New Key Exchange Algorithms: "ecmqv" "ecdh-exchange" New Host Key Algorithms: "ssh-ecc" 6.1. ssh-ecc The "ssh-ecc" method specifies Elliptic Curve digital signature algorithm (ECDSA) for use in signing communications with ECC host keys. When used with ECMQV "ssh-ecc" provides ecmqv with a host key. This method is discussed in Section 3. 6.2. ecdh-exchange The "ecdh-exchange" method specifies Elliptic Curve Diffie-Hellman with for key exchange as described in Section 4. 6.3. ecmqv The "ecmqv" method specifies the use of Elliptic Curve Menezes-Qu- Vanstone for Key Exchange as discussed in Section 5. Green & Stebila Expires April 9, 2007 [Page 14] Internet-Draft SSH ECC Algorithm Integration October 2006 7. Key Exchange Messages The message numbers 30-49 are key exchange-specific and in a private namespace defined in RFC4250 [4] that may be redefined by any key exchange method [3] without being granted IANA permission. The following message numbers have been defined in this document: 7.1. ECDH Message Numbers #define SSH_MSG_KEX_ECDH_REQUEST 30 #define SSH_MSG_KEX_ECDH_INIT 31 #define SSH_MSG_KEX_ECDH_REPLY 32 7.2. ECMQV Message Numbers #define SSH_MSG_ECMQV_KEYTYPE 30 #define SSH_MSG_ECMQV_INIT 31 #define SSH_MSG_ECMQV_REPLY 32 Green & Stebila Expires April 9, 2007 [Page 15] Internet-Draft SSH ECC Algorithm Integration October 2006 8. Security Considerations The Elliptic Curve Diffie-Hellman key agreement algorithm is defined in [6], [11] and [12]. The appropriate security considerations of those documents apply. The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is defined in [6]. The security considerations raised in that document also apply. A more detailed discussion of security considerations can be found in The Guide to Elliptic Curve Cryptography section 4.7 [15]. The methods defined in Section 4 rely on the SHA family of hashing functions as defined in [16]. The appropriate security considerations of that document apply. Additionally a good general discussion of the security considerations that must be taken into account when creating an ECC implementation can be found in The Guide to Elliptic Curve Cryptography section 5 [15]. Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and thus arbitrary security strength, it is important that the size of elliptic curve be chosen to match the security strength of other elements of the SSH handshake. In particular, host key sizes, hashing algorithms and bulk encryption algorithms must be chosen appropriately. Information regarding estimated equivalence of key sizes is available in [10]. Green & Stebila Expires April 9, 2007 [Page 16] Internet-Draft SSH ECC Algorithm Integration October 2006 Appendix A. Named Elliptic Curve Domain Parameters Implementations may support any ASN.1 object identifier (OID) in the ASN.1 object tree that defines a set of elliptic curve domain parameters. Curve is defined in ASN.1 syntax below. curve ::= OBJECT IDENTIFIER UNIQUE Appendix A.1. Required and Recommended Curves Every SSH ECC implementation MUST support the named curves below, these curves are defined in SEC2 [7]. secp256r1 sect283k1 secp384r1 sect409k1 It is RECOMMENDED that SSH ECC implementations also support the following curves. sect163k1 secp192r1 sect233k1 secp224r1 sect233r1 sect409r1 secp521r1 sect571k1 Appendix A.2. Sending Lists of Curves When lists of curves need to be sent to negotiate mutually supported curves they are sent as a sequence of unique ASN.1 OIDS. The ASN.1 syntax of this curve list is shown below. This ASN.1 syntax is encoded with DER and put into the appropriate packet. curves::= SEQUENCE SIZE (1 ... MAX) OF { curve } Green & Stebila Expires April 9, 2007 [Page 17] Internet-Draft SSH ECC Algorithm Integration October 2006 Appendix A.3. SEC Equivalent NIST Curves +-----------+----------+ | SEC | NIST[13] | +-----------+----------+ | sect163k1 | nistk163 | | | | | secp192r1 | nistp192 | | | | | secp224r1 | nistp224 | | | | | sect233k1 | nistk233 | | | | | sect233r1 | nistb233 | | | | | secp256r1 | nistp256 | | | | | sect283k1 | nistk283 | | | | | secp384r1 | nistp384 | | | | | sect409k1 | nistk409 | | | | | sect409r1 | nistb409 | | | | | secp521r1 | nistp521 | | | | | sect571k1 | nistk571 | +-----------+----------+ OIDs for the above curves can be found in SEC2 Section A.2.1 and A.2.2 [7]. Green & Stebila Expires April 9, 2007 [Page 18] Internet-Draft SSH ECC Algorithm Integration October 2006 9. Acknowledgements Douglas Stebila wishes to thank Sheueling Chang and Vipul Gupta of Sun Microsystems. The work on draft-stebila-secsh-ecdh-01, of which this work is a dertivative document, was largely performed during a student internship at Sun Microsystems Laboratories from the University of Waterloo. Jon Green would like to thank Robert Lambert of Certicom for all the help and knowledge he provided. This document was written during an internship at Certicom from Queens University. Green & Stebila Expires April 9, 2007 [Page 19] Internet-Draft SSH ECC Algorithm Integration October 2006 10. References 10.1. Normative References [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Protocol Architecture", RFC 4251, January 2006. [3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Transport Layer Protocol", RFC 4253, January 2006. [4] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell Protocol Assigned Numbers", RFC 4250, January 2006. [5] Eastlake, 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [6] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1 v1.0, September 2000. [7] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2 v1.0, September 2000. [8] International Telecommunication Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680 , July 2002. [9] International Telecommunication Union, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", X.690 , July 2002. Green & Stebila Expires April 9, 2007 [Page 20] Internet-Draft SSH ECC Algorithm Integration October 2006 10.2. Informative References [10] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1", NIST Special Publication 800-57. [11] Institute of Electrical and Electronics Engineers, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000. [12] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: Key Agreement and key Transport Using Elliptic Curve Cryptography", ANSI X9.63, November 2001. [13] National Institute of Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", August 1999. [14] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry The Elliptic Curve Digital Signature Algorithm", ANSI X9.62, 1998. [15] Hankerson, Menezes, and Vanstone, "Guide to Elliptic Curve Cryptography", 2004, . [16] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, August 2002. Green & Stebila Expires April 9, 2007 [Page 21] Internet-Draft SSH ECC Algorithm Integration October 2006 Authors' Addresses Jon Green Certicom 5520 Explorer Drive 4th Floor Mississauga, ON L4W 5L1 Canada Email: jgreen@certicom.com Douglas Stebila Department of Combinatorics and Optimization University of Waterloo Waterloo, ON N2L 3G1 Canada Email: douglas@stebila.ca Green & Stebila Expires April 9, 2007 [Page 22] Internet-Draft SSH ECC Algorithm Integration October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Green & Stebila Expires April 9, 2007 [Page 23] --=-UDTzM78g2LM7c+A50SoZ-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 07 03:01:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW6BT-0008Fm-1u for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 07 Oct 2006 03:01:19 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW6BR-0000M4-Ny for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 07 Oct 2006 03:01:19 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 49F3363B413; Sat, 7 Oct 2006 07:00:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id DFB9663B3E9 for ; Sat, 7 Oct 2006 07:00:57 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA09343; Sat, 7 Oct 2006 03:00:56 -0400 (EDT) From: der Mouse Message-Id: <200610070700.DAA09343@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sat, 7 Oct 2006 02:48:52 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft In-Reply-To: <1160169889.16989.25.camel@merlot.certicom.com> References: <1160074485.7777.30.camel@merlot.certicom.com> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> <1160169889.16989.25.camel@merlot.certicom.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a [The message to which I am replying responded to messages from two different people, pulling them together. I didn't write all the two-level quotes here.] >>> | Symmetric | Discreet Log (eg. DSA, DH) | RSA | ECC | >> This table is also meaningless unless accompanied by a way of >> comparing the amount of computation demanded by, say, a 240-bit >> elliptic curve key with the computation demanded by a 2048-bit RSA >> key. > Computation to do what? (Create the key, crack the key) Use the keys. Giving them as "equivalent security" means that the computation to crack the key is (thought to be) about equal You cite smaller key sizes in a context that makes it read (at least to me) like a reason to use elliptic curve algorithms - but smaller key size, in itself, borders on meaningless; the number of bits involved is one of the least important attribtues of keys - at least until you get into many tens of thousands of bits. > I'm not really sure what [you're] suggesting I do here. Either reword it so this reads less like an advertisement for elliptic curve crypto or provide data indicating why (for example) an elliptic curve key of 240 bits is to be preferred over an RSA key of 2048 bits. >>> When lists of curves need to be sent [...] >> Why is there a hard limit on the size of a list of curves, >> especially a limit that's a magic number like 12? Surely it would >> be better to leave this extensible? > This was a bit of a cop out because I was unable to find a way to > specify in ASN.1 syntax how to not put an upper limit on a sequence. This seems to me like a fairly clear message that ASN.1 is the wrong tool to use here (quite aside from other problems with it - vide infra). >>> for ECC keys and signatures. This requires ASN.1 DER encoding >> Using ASN.1 worries me a little, given the rate at which security >> holes are found in ASN.1 decoders. > I understand your concerns, and I do share them, but as far as I know > the SSL ASN code is being rewritten. And this is relevant...why? Are you under some kind of impression that the result (a) will somehow supplant all other ASN.1 implementations used by SSH implementations and (b) will itself be free from further bugs? I find each part of that...dubious, at best. > Honestly I don't like using ASN.1 at all, but I feel its a necessary > evil to stay compliant with ECC standards, which I think is more > important then software that will be rewritten. Standards should help, hot hinder. Standards that hinder rather than helping should be ignored. Or at least that's my view of them. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 07 07:10:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWA50-0004nv-4N for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 07 Oct 2006 07:10:54 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWA4w-00079D-9I for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 07 Oct 2006 07:10:54 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 6B43463B580; Sat, 7 Oct 2006 11:10:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id AA47063B324 for ; Sat, 7 Oct 2006 11:10:39 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1GWA4k-0001q8-00; Sat, 07 Oct 2006 12:10:38 +0100 From: Ben Harris To: jgreen@certicom.com Subject: Re: SSH in ECC Internet Draft In-Reply-To: <1160169889.16989.25.camel@merlot.certicom.com> References: <1160074485.7777.30.camel@merlot.certicom.com> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> <1160169889.16989.25.camel@merlot.certicom.com> Organization: Linux Unlimited Cc: ietf-ssh@netbsd.org Message-Id: Date: Sat, 07 Oct 2006 12:10:38 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 In article <1160169889.16989.25.camel@merlot.certicom.com> you write: >> Conventionally, key format names beginning "ssh-" have been used for >> key formats invented specifically for SSH, while other names have >> been used for key formats imported from elsewhere. Thus I'd suggest >> using a name not starting with "ssh-" here, say "sec1-ecc". > >Are you suggesting changing the name of the public key algorithm to >sec1-ecc, or just the string sent before the key itself? Both. Basically s/ssh-ecc/sec1-ecc/g (or whatever new name you think is appropriate) over the document. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Oct 08 22:38:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWl1t-0004dQ-S6 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 08 Oct 2006 22:38:09 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWl1s-0007M2-JI for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 08 Oct 2006 22:38:09 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 14CE863B354; Mon, 9 Oct 2006 02:37:56 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id B239863B20A for ; Mon, 9 Oct 2006 02:37:54 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id WAA05056; Sun, 8 Oct 2006 22:37:53 -0400 (EDT) From: der Mouse Message-Id: <200610090237.WAA05056@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sun, 8 Oct 2006 22:30:18 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft In-Reply-To: References: <1160074485.7777.30.camel@merlot.certicom.com> <1160074485.7777.30.camel@merlot.certicom.com> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >>> [...] >> This makes it sound as though ssh-ecc host keys and ecmqv key >> exchange are not independent - that it is not possile to use one >> without the other. If true, I think this is a bad idea, if only >> because the negotiation framework does not support this kind of tied >> negotiation. > Actually, in this case, we already have that kind of tied > negotiation. SSH already supports the notions of signature-capable > and encryption-capable host keys, and the choice of public-key > algorithm depends on the selected public-key algorithm. This > effectively adds an third key type to that algorithm. Hmm. Yes, that's a logically coherent point of view. I don't like it, though, if only because it takes a special case for one particular algorithm (or, if you prefer, family of algorithms currently represented by a single element) and elevates it to being co=EBval with generic concepts like signatures and encryption. It feels like a level confusion. If this does stay, I'd prefer to see it spelled out much more explicitly. Not that what I think carries any particular authority, mind you.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 00:57:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWnCx-0002sN-F1 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 00:57:43 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWnCs-0005Xf-I3 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 00:57:43 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id ED48263B37D; Mon, 9 Oct 2006 04:57:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 03FFD63B1B6 for ; Mon, 9 Oct 2006 04:57:21 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k994vLYF028417 for ; Sun, 8 Oct 2006 22:57:21 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k994vKlO026739 for ; Sun, 8 Oct 2006 22:57:21 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k994vJbT004279; Sun, 8 Oct 2006 23:57:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k994vJtA004278; Sun, 8 Oct 2006 23:57:19 -0500 (CDT) Date: Sun, 8 Oct 2006 23:57:19 -0500 From: Nicolas Williams To: Jon Green Cc: ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft Message-ID: <20061009045719.GS3878@binky.Central.Sun.COM> References: <1160074485.7777.30.camel@merlot.certicom.com> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> <1160169889.16989.25.camel@merlot.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160169889.16989.25.camel@merlot.certicom.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Fri, Oct 06, 2006 at 05:24:49PM -0400, Jon Green wrote: > This was a bit of a cop out because I was unable to find a way to > specify in ASN.1 syntax how to not put an upper limit on a sequence. > > I've updated the specification to be: > curves::= SEQUENCE SIZE (1 ... MAX) OF { curve } Why do you need to specify a limit at all? > Other RFC's seem to specify unbounded sequences like this, without ever > defining MAX, but I don't like leaving MAX undefined, since it doesn't > seem to be part of the ASN specification. Can anyone tell me if this is > correct? That's not good -- nowadays the IESG insists on whole ASN.1 modules and that they compile with various available tools. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 01:02:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWnHE-0004sL-6z for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 01:02:08 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWnH9-000655-Qa for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 01:02:08 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id F0FC763B382; Mon, 9 Oct 2006 05:02:00 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 30E7F63B1B6 for ; Mon, 9 Oct 2006 05:02:00 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9951xGd023496 for ; Sun, 8 Oct 2006 22:01:59 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9951xOC022160 for ; Sun, 8 Oct 2006 23:01:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9951wXg004290; Mon, 9 Oct 2006 00:01:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9951wgl004289; Mon, 9 Oct 2006 00:01:58 -0500 (CDT) Date: Mon, 9 Oct 2006 00:01:58 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft Message-ID: <20061009050158.GT3878@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <1160074485.7777.30.camel@merlot.certicom.com> <200610052227.SAA09189@Sparkle.Rodents.Montreal.QC.CA> <1160169889.16989.25.camel@merlot.certicom.com> <200610070700.DAA09343@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610070700.DAA09343@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Sat, Oct 07, 2006 at 02:48:52AM -0400, der Mouse wrote: > >> Why is there a hard limit on the size of a list of curves, > >> especially a limit that's a magic number like 12? Surely it would > >> be better to leave this extensible? > > This was a bit of a cop out because I was unable to find a way to > > specify in ASN.1 syntax how to not put an upper limit on a sequence. > > This seems to me like a fairly clear message that ASN.1 is the wrong > tool to use here (quite aside from other problems with it - vide > infra). Jon says that the relevant parameters are identified by OIDs. If there is an existing namespace/registry of the such then it seems quite appropriate to use OIDs here. A list of OIDs need not be specified as an ASN.1 SEQUENCE though, and SSHv2 already has a way to encode lists of things, re-using here. That way there's no need to use ASN.1 or any of its encodings just to send these OIDs (since OIDs are DER encoded and so, when used as registered names, just simple octet string constants). Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 06:51:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWsjS-0004fE-CD for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 06:51:38 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWsjN-0005ax-Gq for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 06:51:38 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id DFAA863B3E9; Mon, 9 Oct 2006 10:51:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from piranha.informatik.uni-erlangen.de (piranha.informatik.uni-erlangen.de [131.188.30.252]) by mail.netbsd.org (Postfix) with ESMTP id 9F62263B10B for ; Mon, 9 Oct 2006 10:51:19 +0000 (UTC) Received: from folly.informatik.uni-erlangen.de (markus@localhost.informatik.uni-erlangen.de [127.0.0.1]) by piranha.informatik.uni-erlangen.de (8.13.4/8.13.4) with ESMTP id k999WWPi006409; Mon, 9 Oct 2006 11:32:32 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 97582F4F7; Mon, 9 Oct 2006 11:32:48 +0200 (CEST) Date: Mon, 9 Oct 2006 11:32:48 +0200 From: Markus Friedl To: Jon Green Cc: ietf-ssh@netbsd.org Subject: Re: SSH in ECC Internet Draft Message-ID: <20061009093248.GB24007@folly> References: <1160074485.7777.30.camel@merlot.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160074485.7777.30.camel@merlot.certicom.com> User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On Thu, Oct 05, 2006 at 02:54:45PM -0400, Jon Green wrote: > The data types boolean, uint32, uint64, string, and mpint are to be > interpreted in this document as described in RFC 4251 [1]. > > This document uses Abstract Syntax Notation (ASN.1) define some > communication. This is in keeping with current ECC standards. All > ASN.1 variables are DER encoded before being sent. Information about > the ASN.1 and DER can be found in ITU-T recommendation X.680 [7] and > ITU-T recommendation X.690 [8]. is it really necessary to use ASN.1 encoding? this is rather scary and does not fit well into the data type scheme defined in RFC 4251. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 12:39:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyAX-0001xG-Ud for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 12:39:57 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWyAV-00064c-2Q for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 12:39:57 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id F2F3763B268; Mon, 9 Oct 2006 16:39:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 0EB8363B247 for ; Mon, 9 Oct 2006 16:39:39 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1958BE0128; Mon, 9 Oct 2006 12:39:27 -0400 (EDT) From: Sam Hartman To: Jon Bright Cc: ietf-ssh@netbsd.org Subject: Re: Last call comments for draft-ietf-secsh-publickey-subsystem-07 References: <20060916220007.GB2190@chiark.greenend.org.uk> <451ACDF0.6080407@siliconcircus.com> Date: Mon, 09 Oct 2006 12:39:27 -0400 In-Reply-To: <451ACDF0.6080407@siliconcircus.com> (Jon Bright's message of "Wed, 27 Sep 2006 21:16:00 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.2 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >>>>> "Jon" == Jon Bright writes: Jon> Hi, Jon> Jacob Nevins wrote: >> (Apologies for the lateness of these comments.) Jon> Apologies for the delay in replying. >> In the following, "public-key blob" has the format specified >> in section 6.6, "Public Key Algorithms" of the SSH Transport >> Protocol document [2]: >> >> string certificate or public key format identifier byte[n] >> key/certificate data >> >> (Although in fact I'd rather we avoided the term "blob" >> entirely, as in publickeyfile, due to the conflict with 4253.) Jon> The suggestion seems OK. I'm not sure what word other than Jon> "blob" we could use. "public key object"? "public key Jon> representation"? Since we're in IESG evaluation now, I'm not Jon> sure what the process is for integrating such a change. If I Jon> can issue another rev, I will (unless someone speaks up Jon> against it) include this change. What ended up happening with this? I didn't see the comment because neither the ietf nor iesg list was copied. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 13:05:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyZM-0006bF-4e for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 13:05:36 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWyZI-0002Hp-RU for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 13:05:36 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id E2C4B63B2A9; Mon, 9 Oct 2006 17:05:25 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 13EAD63B137 for ; Mon, 9 Oct 2006 17:05:24 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99H5OQk016467 for ; Mon, 9 Oct 2006 11:05:24 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99H5NTW006905 for ; Mon, 9 Oct 2006 11:05:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k99H5NQb004839; Mon, 9 Oct 2006 12:05:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k99H5LGU004838; Mon, 9 Oct 2006 12:05:21 -0500 (CDT) Date: Mon, 9 Oct 2006 12:05:21 -0500 From: Nicolas Williams To: Sam Hartman Cc: Jon Bright , ietf-ssh@NetBSD.org Subject: Re: Last call comments for draft-ietf-secsh-publickey-subsystem-07 Message-ID: <20061009170521.GZ3878@binky.Central.Sun.COM> References: <20060916220007.GB2190@chiark.greenend.org.uk> <451ACDF0.6080407@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Mon, Oct 09, 2006 at 12:39:27PM -0400, Sam Hartman wrote: > Jon> The suggestion seems OK. I'm not sure what word other than > Jon> "blob" we could use. "public key object"? "public key > Jon> representation"? Since we're in IESG evaluation now, I'm not > Jon> sure what the process is for integrating such a change. If I > Jon> can issue another rev, I will (unless someone speaks up > Jon> against it) include this change. > > What ended up happening with this? I didn't see the comment because > neither the ietf nor iesg list was copied. I argued that no change was needed. I don't think there's consensus on making any change in this regard. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 13:45:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzCI-0002JK-Er for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 13:45:50 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzCF-0001Dh-Ih for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 13:45:50 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 0FAC363B3B8; Mon, 9 Oct 2006 17:45:45 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 4447463B137 for ; Mon, 9 Oct 2006 17:45:43 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id C2AF210F64B; Mon, 9 Oct 2006 19:45:37 +0200 (CEST) Message-ID: <452A8AC1.4050300@siliconcircus.com> Date: Mon, 09 Oct 2006 19:45:37 +0200 From: Jon Bright User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Nicolas Williams CC: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Last call comments for draft-ietf-secsh-publickey-subsystem-07 References: <20060916220007.GB2190@chiark.greenend.org.uk> <451ACDF0.6080407@siliconcircus.com> <20061009170521.GZ3878@binky.Central.Sun.COM> In-Reply-To: <20061009170521.GZ3878@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Nicolas Williams wrote: > On Mon, Oct 09, 2006 at 12:39:27PM -0400, Sam Hartman wrote: >> Jon> The suggestion seems OK. I'm not sure what word other than >> Jon> "blob" we could use. "public key object"? "public key >> Jon> representation"? Since we're in IESG evaluation now, I'm not >> Jon> sure what the process is for integrating such a change. If I >> Jon> can issue another rev, I will (unless someone speaks up >> Jon> against it) include this change. >> >> What ended up happening with this? I didn't see the comment because >> neither the ietf nor iesg list was copied. > > I argued that no change was needed. I don't think there's consensus on > making any change in this regard. That was the position I took - the change seemed good to me, but there was certainly opposition, so I didn't think it appropriate to make it now. -- Jon From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 15:14:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0aC-000266-Ik for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 15:14:36 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX0aB-0004M4-80 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 15:14:36 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4E67063B4C4; Mon, 9 Oct 2006 19:14:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id 6E44963B3E6 for ; Mon, 9 Oct 2006 19:14:19 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id D4A8269AFD; Tue, 10 Oct 2006 04:10:37 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.4 Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id 0C84969AB4; Tue, 10 Oct 2006 04:10:35 +1000 (EST) Received: by mail.mindrot.org (Postfix, from userid 1000) id 384B017E60A; Tue, 10 Oct 2006 03:46:38 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 36C0F17E609; Tue, 10 Oct 2006 03:46:38 +1000 (EST) Date: Tue, 10 Oct 2006 03:46:38 +1000 (EST) From: Damien Miller To: Jon Green cc: ietf-ssh@netbsd.org, ietf-ipr@ietf.org Subject: Re: SSH in ECC Internet Draft In-Reply-To: <1160074485.7777.30.camel@merlot.certicom.com> Message-ID: References: <1160074485.7777.30.camel@merlot.certicom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Thu, 5 Oct 2006, Jon Green wrote: > In the interest of supporting the US government's Suite B cryptographic > algorithms, we have updated an ECC in SSH draft written by D. Stabila > (draft-stebila-secsh-ecdh-01) and have added Suite B algorithms, > specifically MQV to the draft. > > This draft has been submitted to the IETF as an internet draft and I'm > posting it on this list to solicit some review and to try to generate > some interest. Any comments on the draft at all would be appreciated. [1] does not list any IPR disclosure filed for this draft, despite it containing something (MQV) that is known to be patented by Certicom. Many points of the draft (e.g. the checks recommended and required in 4.1) seem to point to other methods over which Certicom happens to hold patents. This working group has so far eschewed patent-encumbered technology, and I really hope that this position does not change. -d [1] https://datatracker.ietf.org/public/ipr_search.cgi?option=document_search&document_search=draft-green-secsh-ecc-00.txt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 15:29:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0p4-0007oH-IY for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 15:29:58 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX0p3-0002le-9X for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 15:29:58 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 1183063B365; Mon, 9 Oct 2006 19:29:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 240EA63B1E9 for ; Mon, 9 Oct 2006 19:29:51 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0AFB0E0128; Mon, 9 Oct 2006 15:29:43 -0400 (EDT) From: Sam Hartman To: Damien Miller Cc: Jon Green , ietf-ssh@netbsd.org, ietf-ipr@ietf.org Subject: Re: SSH in ECC Internet Draft References: <1160074485.7777.30.camel@merlot.certicom.com> Date: Mon, 09 Oct 2006 15:29:43 -0400 In-Reply-To: (Damien Miller's message of "Tue, 10 Oct 2006 03:46:38 +1000 (EST)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 >>>>> "Damien" == Damien Miller writes: Damien> On Thu, 5 Oct 2006, Jon Green wrote: >> In the interest of supporting the US government's Suite B >> cryptographic algorithms, we have updated an ECC in SSH draft >> written by D. Stabila (draft-stebila-secsh-ecdh-01) and have >> added Suite B algorithms, specifically MQV to the draft. >> >> This draft has been submitted to the IETF as an internet draft >> and I'm posting it on this list to solicit some review and to >> try to generate some interest. Any comments on the draft at all >> would be appreciated. Damien> [1] does not list any IPR disclosure filed for this draft, Damien> despite it containing something (MQV) that is known to be Damien> patented by Certicom. Many points of the draft (e.g. the Damien> checks recommended and required in 4.1) seem to point to Damien> other methods over which Certicom happens to hold patents. I'm sure the draft authors are well aware, but by submitting an IETf contribution such as an internet draft or a message to this list, they are bound by IETF IPR rules and subject to constraints outlined in the appropriate BCPs must file disclosures. If anyone has any questions about IETF IPR policy I would be happy to answer those questions or get you in touch with someone who can answer. Damien> This working group has so far eschewed patent-encumbered Damien> technology, and I really hope that this position does not Damien> change. This working group is closed. If these drafts are considered for publication it will be as an individual submission. However IETF consensus would be required for publication and the views of the ssh community would be a strong factor in that consensus. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 15:32:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0r3-00012z-FU for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 15:32:01 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX0r2-0002rq-2x for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 15:32:01 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 5BF4363B112; Mon, 9 Oct 2006 19:31:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 7C45063B3D1 for ; Mon, 9 Oct 2006 19:31:57 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8A6A4E0129; Mon, 9 Oct 2006 15:31:49 -0400 (EDT) From: Sam Hartman To: Markus Friedl Cc: Jon Green , ietf-ssh@netbsd.org Subject: Re: SSH in ECC Internet Draft References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> Date: Mon, 09 Oct 2006 15:31:49 -0400 In-Reply-To: <20061009093248.GB24007@folly> (Markus Friedl's message of "Mon, 9 Oct 2006 11:32:48 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >>>>> "Markus" == Markus Friedl writes: Markus> On Thu, Oct 05, 2006 at 02:54:45PM -0400, Jon Green wrote: >> The data types boolean, uint32, uint64, string, and mpint are >> to be interpreted in this document as described in RFC 4251 >> [1]. >> >> This document uses Abstract Syntax Notation (ASN.1) define some >> communication. This is in keeping with current ECC standards. >> All ASN.1 variables are DER encoded before being sent. >> Information about the ASN.1 and DER can be found in ITU-T >> recommendation X.680 [7] and ITU-T recommendation X.690 [8]. Markus> is it really necessary to use ASN.1 encoding? this is Markus> rather scary and does not fit well into the data type Markus> scheme defined in RFC 4251. I think you should look at how this will likely work in common implementations. If your ECC library is likely to want to take ASN.1 parameters as input, then that's probably how you want to transport them. Certainly there are a lot of IETF protocols that use ASN.1; ASN.1 is complex but sometimes that complexity is necessary. --Sam From laptop@wab.edu Mon Oct 09 17:17:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2Va-0003AS-5R for secsh-archive@megatron.ietf.org; Mon, 09 Oct 2006 17:17:58 -0400 Received: from gateway.wab.edu ([219.232.114.7] helo=smtp1.wab.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2VX-00016o-Vk for secsh-archive@megatron.ietf.org; Mon, 09 Oct 2006 17:17:58 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.wab.edu (Postfix) with ESMTP id 0803AE75E1C for ; Tue, 10 Oct 2006 02:49:20 +0800 (CST) Received: from smtp1.wab.edu ([127.0.0.1]) by localhost (random.wab.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25825-05 for ; Tue, 10 Oct 2006 02:49:19 +0800 (CST) Received: by smtp1.wab.edu (Postfix, from userid 504) id 6A059E2F22F; Mon, 9 Oct 2006 22:45:50 +0800 (CST) To: secsh-archive@megatron.ietf.org Subject: Message from eBay Member From: eBay-Mitglied gret Content-Type: text/html Message-Id: <20061009144550.6A059E2F22F@smtp1.wab.edu> Date: Mon, 9 Oct 2006 22:45:50 +0800 (CST) X-Virus-Scanned: by amavisd-new at wab.edu X-Spam-Score: 4.7 (++++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
eBay sents you this message.
Your registered name is included to show this message originated from eBay. Learn more.
Question from eBay Member -- Respond Now eBay
eBay sent this message on behalf of an eBay member via My Messages. Responses sent using email will not reach the eBay member. Use the Respond Now button below to respond to this message.
Question from ozantares
About This Member
ozantares( 0 )
Positive Feedback: 100%
Member Since: 27-Aug-06
Location: United States
Registered On: www.eBay.com
About your auction on eBay.
Please let me know if the price includes all shipping and insurance taxes.
I would appreciate a fast reply.
 
Thank you!
Respond to this question in My Messages.
Respond Now
Thank you for using eBay!
http://www.eBay.com
Marketplace Safety Tip Marketplace Safety Tip
If this message is an offer to sell an item without winning it on the eBay Web site (including Second Chance Offers sent through My Messages) please do not respond to the sender. These "outside of eBay" transactions are unsafe and not covered by eBay purchase protection programs.

Never pay for your eBay item through instant wire transfer services such as Western Union or MoneyGram. These payment methods are unsafe when paying someone you do not know.
Is this email inappropriate? Does it violate eBay policy? Help protect the community by reporting it.
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 09 21:01:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX5zj-0004QE-5p for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 21:01:19 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX5tv-0007xl-H0 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 09 Oct 2006 20:55:23 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4C1D563B4A0; Tue, 10 Oct 2006 00:55:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by mail.netbsd.org (Postfix) with ESMTP id 9BF0D63B22A for ; Tue, 10 Oct 2006 00:55:05 +0000 (UTC) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 40C5B328BD; Mon, 9 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GX3wg-0002GZ-41; Mon, 09 Oct 2006 18:50:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org Cc: ietf-ssh@netbsd.org, Bill Sommerfeld From: IESG Secretary Subject: WG Action: Conclusion of Secure Shell (secsh) Message-Id: Date: Mon, 09 Oct 2006 18:50:02 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c The Secure Shell (secsh) in the Security Area has concluded. The IESG contact persons are Russ Housley and Sam Hartman. The mailing list will remain active. The secure shell working group completed its primary objective of specifying the core SSH protocol. It also completed specifications for a number of extensions, including multiple cipher modes, a break extension, the keyboard interactive authentication protocol, support for GSS-API, and better management of SSH public keys. While other work was chartered, there is insufficient energy to justify an ongoing working group. Thanks for all the hard work from all the participants and chairs over the years. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 11:52:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJuR-0001wU-UN for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 11:52:47 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXJuQ-00026t-LY for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 11:52:47 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4C1CE63B14A; Tue, 10 Oct 2006 15:52:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id 56D5663B153 for ; Tue, 10 Oct 2006 15:52:30 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id 6B78169AF1; Wed, 11 Oct 2006 01:52:28 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.4 Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id 6AC4D69AA1; Wed, 11 Oct 2006 01:52:25 +1000 (EST) Received: by mail.mindrot.org (Postfix, from userid 1000) id 9902917E60A; Wed, 11 Oct 2006 01:52:24 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 976BD17E609; Wed, 11 Oct 2006 01:52:24 +1000 (EST) Date: Wed, 11 Oct 2006 01:52:24 +1000 (EST) From: Damien Miller To: Sam Hartman cc: Markus Friedl , Jon Green , ietf-ssh@netbsd.org Subject: Re: SSH in ECC Internet Draft In-Reply-To: Message-ID: References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Mon, 9 Oct 2006, Sam Hartman wrote: > Markus> is it really necessary to use ASN.1 encoding? this is > Markus> rather scary and does not fit well into the data type > Markus> scheme defined in RFC 4251. > > I think you should look at how this will likely work in common > implementations. If your ECC library is likely to want to take ASN.1 > parameters as input, then that's probably how you want to transport > them. > > Certainly there are a lot of IETF protocols that use ASN.1; ASN.1 is > complex but sometimes that complexity is necessary. I agree with Markus; the use of ASN.1 adds a lot of complexity and attack surface to an implementation. In this case, this additional complexity must be in the critical pre-authentication code. IMO that (some) ECC libraries happen to use ASN.1 is not a good reason to use it as protocol element. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 12:13:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKEo-0006pb-9s for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 12:13:50 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKEk-00088G-8n for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 12:13:50 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 8CE8B63B1B3; Tue, 10 Oct 2006 16:13:41 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id 6880363B1AA for ; Tue, 10 Oct 2006 16:13:40 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 50468200A1E4; Tue, 10 Oct 2006 18:13:38 +0200 (CEST) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05504-02-60; Tue, 10 Oct 2006 18:13:36 +0200 (CEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 2B6D1200A200; Tue, 10 Oct 2006 18:13:36 +0200 (CEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.13.4+Sun/8.13.4) with ESMTP id k9AGDYKn013301; Tue, 10 Oct 2006 18:13:35 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.13.4+Sun/8.12.8/Submit) id k9AGDXek013298; Tue, 10 Oct 2006 18:13:33 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Sam Hartman Cc: Markus Friedl , Jon Green , ietf-ssh@netbsd.org Subject: Re: SSH in ECC Internet Draft References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> Content-type: text/plain; charset=iso-8859-1 From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 10 Oct 2006 18:13:30 +0200 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Sam Hartman writes: > I think you should look at how this will likely work in common > implementations. If your ECC library is likely to want to take ASN.1 > parameters as input, then that's probably how you want to transport > them. I don't buy that argument. By the same argument, the only reason not to replace the "ssh-rsa" keys by the asn.1 based pkcs#x stuff formats is backwards compatibility. The way I see it, when you specify asn.1 as the wireformat for anything, that forces every implementation (or the libraries it depends upon) to take asn.1 to its core. I see the ssh RSA and DSA key formats as a good example on how to do things. It allows ssh implementatiions to use very simple and minimalistic libraries. Whenever compatibility with other formats is needed, that conversion can easily be done *off-line*, and without automatically making bugs in the conversion code into remote root exploits. Converting between asn.1 formats and simpler native formats used for the actual computation, is maybe no big deal in principle, but that's no good reason to *force* that conversion code into each and every implementation of the ssh protocol. You don't want code bloat in ssh implementations. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 12:17:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKIi-0000U8-GD for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 12:17:52 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKIf-0000u6-34 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 12:17:52 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 7B61A63B197; Tue, 10 Oct 2006 16:17:43 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by mail.netbsd.org (Postfix) with ESMTP id A955B63B153 for ; Tue, 10 Oct 2006 16:17:38 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AGHcpK007965 for ; Tue, 10 Oct 2006 09:17:38 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AGHbKf016937 for ; Tue, 10 Oct 2006 10:17:38 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9AGHR8j005811; Tue, 10 Oct 2006 11:17:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9AGHN6E005810; Tue, 10 Oct 2006 11:17:23 -0500 (CDT) Date: Tue, 10 Oct 2006 11:17:23 -0500 From: Nicolas Williams To: Damien Miller Cc: Sam Hartman , Markus Friedl , Jon Green , ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft Message-ID: <20061010161722.GP3878@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , Damien Miller , Sam Hartman , Markus Friedl , Jon Green , ietf-ssh@NetBSD.org References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: > IMO that (some) ECC libraries happen to use ASN.1 is not a good reason > to use it as protocol element. The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where existing SSHv2 constructs could be used instead. The draft's other uses of ASN.1/DER do not require an implementation of SSHv2 to implement ASN.1/DER outside ECC libraries, but this one type does. So I agree, remove that type. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 13:10:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL7a-0002GC-Jr for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:10:26 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXL3i-0000sr-6X for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:06:28 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 3A87C63B189; Tue, 10 Oct 2006 17:06:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 2530863B187 for ; Tue, 10 Oct 2006 17:06:21 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AH6K0C005690 for ; Tue, 10 Oct 2006 11:06:20 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AH6JeK011743 for ; Tue, 10 Oct 2006 11:06:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9AH6J94005851; Tue, 10 Oct 2006 12:06:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9AH6JKG005850; Tue, 10 Oct 2006 12:06:19 -0500 (CDT) Date: Tue, 10 Oct 2006 12:06:19 -0500 From: Nicolas Williams To: Jon Green Cc: Damien Miller , Sam Hartman , Markus Friedl , ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft Message-ID: <20061010170618.GT3878@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , Jon Green , Damien Miller , Sam Hartman , Markus Friedl , ietf-ssh@NetBSD.org References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> <20061010161722.GP3878@binky.Central.Sun.COM> <1160499711.24953.28.camel@shiraz.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160499711.24953.28.camel@shiraz.certicom.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Tue, Oct 10, 2006 at 01:01:51PM -0400, Jon Green wrote: > On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: > > The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where > > existing SSHv2 constructs could be used instead. The draft's other uses > > of ASN.1/DER do not require an implementation of SSHv2 to implement > > ASN.1/DER outside ECC libraries, but this one type does. > > I don't think that we can just remove curves and send a name-list of > OIDs. Sure you can. > Encoding and parsing a ASN.1 sequence is easier then encoding and > parsing a ssh namelist full of octet strings. Nonsense. If you're implementing this I-D then you are already implementing SSHv2 and you already have code for encoding/decoding SSHv2-style lists/arrays. But the reverse is not true! If you're using ECC libraries off-the-shelf and adding this to an SSHv2 implementation then it's not the case that you necessarily have the code to encode/decode ASN.1/DER SEQUENCEs. > So everyone is familiar with what an asn.1 sequence looks like: I am, but you cannot assume that SSHv2 implementors in general are. > The first problem with putting OIDs in name-lists is that the one of the > octets in the OID octet string may be 0x2C (ascii comma) which delimits > the list, so the OIDs will have to be encoded somehow before being put > into a standard namelist, or there has to be a new type of list > defined. You mistunderstand SSHv2 list/array encoding. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 13:10:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL7j-0002Jn-JQ for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:10:35 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKzV-0000JP-8y for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:02:06 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id AFE6363B19E; Tue, 10 Oct 2006 17:02:01 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by mail.netbsd.org (Postfix) with ESMTP id AA8E263B13F for ; Tue, 10 Oct 2006 17:02:00 +0000 (UTC) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id D5D0310159F82; Tue, 10 Oct 2006 13:01:56 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15360-99; Tue, 10 Oct 2006 13:01:55 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 30833100C81BB; Tue, 10 Oct 2006 13:01:55 -0400 (EDT) Received: from localhost ([10.0.1.29]) by certicom1.certicom.com (Lotus Domino Release 7.0.1) with ESMTP id 2006101013002652-67221 ; Tue, 10 Oct 2006 13:00:26 -0400 Subject: Re: SSH in ECC Internet Draft From: Jon Green To: Nicolas Williams Cc: Damien Miller , Sam Hartman , Markus Friedl , ietf-ssh@NetBSD.org In-Reply-To: <20061010161722.GP3878@binky.Central.Sun.COM> References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> <20061010161722.GP3878@binky.Central.Sun.COM> Date: Tue, 10 Oct 2006 13:01:51 -0400 Message-Id: <1160499711.24953.28.camel@shiraz.certicom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/10/2006 01:00:26 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/10/2006 01:00:27 PM, Serialize complete at 10/10/2006 01:00:27 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: > On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: > > IMO that (some) ECC libraries happen to use ASN.1 is not a good reason > > to use it as protocol element. > > The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where > existing SSHv2 constructs could be used instead. The draft's other uses > of ASN.1/DER do not require an implementation of SSHv2 to implement > ASN.1/DER outside ECC libraries, but this one type does. I don't think that we can just remove curves and send a name-list of OIDs. Encoding and parsing a ASN.1 sequence is easier then encoding and parsing a ssh namelist full of octet strings. So everyone is familiar with what an asn.1 sequence looks like: [ identifier | length | oid | oid | oid | oid | ... where each oid contains [ identifier | length | oid data ] The first problem with putting OIDs in name-lists is that the one of the octets in the OID octet string may be 0x2C (ascii comma) which delimits the list, so the OIDs will have to be encoded somehow before being put into a standard namelist, or there has to be a new type of list defined. Any list constructs I came up with seemed to be very similar to the ASN.1 sequence of construct, so i decided to use it. Would including some psudocode in the draft to encode and parse 'curves' maybe be a good idea? I like using the OIDs to identify curves since there is an already existing IANA registry and we don't have to reinvent the wheel this way. Cheers, Jon Green From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 13:10:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL7l-0002KQ-2s for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:10:37 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKzG-0000E5-CG for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:01:56 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 16F6D63B153; Tue, 10 Oct 2006 17:01:47 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 3726A63B13F for ; Tue, 10 Oct 2006 17:01:46 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AH1g6X028686 for ; Tue, 10 Oct 2006 10:01:46 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AH1fi1014792 for ; Tue, 10 Oct 2006 11:01:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9AH1fDK005842; Tue, 10 Oct 2006 12:01:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9AH1fOF005841; Tue, 10 Oct 2006 12:01:41 -0500 (CDT) Date: Tue, 10 Oct 2006 12:01:41 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Damien Miller , Sam Hartman , Markus Friedl , Jon Green , ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft Message-ID: <20061010170140.GS3878@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , Bill Sommerfeld , Damien Miller , Sam Hartman , Markus Friedl , Jon Green , ietf-ssh@NetBSD.org References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> <20061010161722.GP3878@binky.Central.Sun.COM> <1160499087.4380.11.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160499087.4380.11.camel@thunk> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Tue, Oct 10, 2006 at 12:51:27PM -0400, Bill Sommerfeld wrote: > On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: > > On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: > > > IMO that (some) ECC libraries happen to use ASN.1 is not a good reason > > > to use it as protocol element. > > > > The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where > > existing SSHv2 constructs could be used instead. The draft's other uses > > of ASN.1/DER do not require an implementation of SSHv2 to implement > > ASN.1/DER outside ECC libraries, but this one type does. > > actually, it looks to me like there may be a deeper problem: the same > "two level negotiation" issue which affected the gssapi key exchange. Yeah, that was pointed out elsewhere. Do we have consensus on how best to deal with extensions that tie KEX/host key algs so intimately? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 13:32:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLSV-0004kV-Dw for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:32:03 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXLSS-0006uZ-Hb for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:32:03 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id DC76C63B1BA; Tue, 10 Oct 2006 17:31:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id AE5B763B1AE for ; Tue, 10 Oct 2006 17:31:46 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3FCFBE0127; Tue, 10 Oct 2006 13:31:34 -0400 (EDT) From: Sam Hartman To: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Cc: Markus Friedl , Jon Green , ietf-ssh@netbsd.org Subject: Re: SSH in ECC Internet Draft References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> Date: Tue, 10 Oct 2006 13:31:34 -0400 In-Reply-To: (Niels =?iso-8859-1?Q?M=F6ller's?= message of "10 Oct 2006 18:13:30 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c >>>>> "Niels" =3D=3D Niels M=F6ller writes: Niels> Sam Hartman writes: >> I think you should look at how this will likely work in common >> implementations. If your ECC library is likely to want to take >> ASN.1 parameters as input, then that's probably how you want to >> transport them. Niels> I don't buy that argument. By the same argument, the only Niels> reason not to replace the "ssh-rsa" keys by the asn.1 based Niels> pkcs#x stuff formats is backwards compatibility. Well, let's put it this way, I think using ASN.1 in that instance would have been an entirely reasonable design tradeoff. Niels> The way I see it, when you specify asn.1 as the wireformat Niels> for anything, that forces every implementation (or the Niels> libraries it depends upon) to take asn.1 to its core. So, my advice to the authors of the ECC draft is to listen to the comments here about ASN.1, to the extent that you agree with them make changes, but to have the debate about whether you are using too much ASN.1 in the ietf-wide context not on this list. I think that there is a lot of anti-ASN.1 FUD here and you will get a much more balanced viewpoint on the ietf list. But if you are going to use ASN.1 at all, USE IT CORRECTLY. Arbitrary limits because you can't find out how to write your constraints and lack of a module that compiles will be a problem. Niels> I see the ssh RSA and DSA key formats as a good example on Niels> how to do things. It allows ssh implementatiions to use Niels> very simple and minimalistic libraries. Whenever Niels> compatibility with other formats is needed, that conversion Niels> can easily be done *off-line*, and without automatically Niels> making bugs in the conversion code into remote root Niels> exploits. This is one valid approach. If you are only going to have ssh, then it is a clear savings in complexity and as you point out complexity is tied to security. However if I'm going to have a bunch of protocols each of which does things lightly differently I eventually get to a point where chasing down all the problems in all the implementations of similar concepts actually provides worse security. Like everything else it is a balance between local complexity and global complexity. Please do not confuse the tradeoff you have chosen with the right answer: it is simply *a* right answer. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 13:52:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLmG-0004mY-BH for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:52:28 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXLmD-0002YC-U1 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 13:52:28 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 1170F63B1D3; Tue, 10 Oct 2006 17:52:14 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by mail.netbsd.org (Postfix) with ESMTP id F162C63B1CC for ; Tue, 10 Oct 2006 17:52:12 +0000 (UTC) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id D1A17101572E4 for ; Tue, 10 Oct 2006 13:52:09 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16245-83 for ; Tue, 10 Oct 2006 13:52:07 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 136681014DE5F for ; Tue, 10 Oct 2006 13:52:07 -0400 (EDT) Received: from localhost ([10.0.1.29]) by certicom1.certicom.com (Lotus Domino Release 7.0.1) with ESMTP id 2006101013503835-67402 ; Tue, 10 Oct 2006 13:50:38 -0400 Subject: Re: SSH in ECC Internet Draft From: Jon Green To: ietf-ssh@NetBSD.org In-Reply-To: <20061010170618.GT3878@binky.Central.Sun.COM> References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> <20061010161722.GP3878@binky.Central.Sun.COM> <1160499711.24953.28.camel@shiraz.certicom.com> <20061010170618.GT3878@binky.Central.Sun.COM> Date: Tue, 10 Oct 2006 13:52:03 -0400 Message-Id: <1160502723.24953.56.camel@shiraz.certicom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/10/2006 01:50:38 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/10/2006 01:50:39 PM, Serialize complete at 10/10/2006 01:50:39 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On Tue, 2006-10-10 at 12:06 -0500, Nicolas Williams wrote: > > The first problem with putting OIDs in name-lists is that the one of the > > octets in the OID octet string may be 0x2C (ascii comma) which delimits > > the list, so the OIDs will have to be encoded somehow before being put > > into a standard namelist, or there has to be a new type of list > > defined. > > You mistunderstand SSHv2 list/array encoding. I'm sorry if I misunderstand, could you please elaborate on your plans to encode OIDs within SSHv2 namelists? I am more then happy to throw out the 'curves' construct if its redundant and a name-list can be used. I feel as if ASN.1 has to have some part in this design, but if there is a SSH specific way of sending lists that can be used, then i fully support using that in order reduce the amount of ASN.1 that has to be used. I just re-read RFC4251 and I don't see how OIDs that can contain 0x2C can be allowed to be put into a name-list. >From RFC4251: > name-list > > A string containing a comma-separated list of names. A name-list > is represented as a uint32 containing its length (number of bytes > that follow) followed by a comma-separated list of zero or more > names. A name MUST have a non-zero length, and it MUST NOT > contain a comma (","). As this is a list of names, all of the > elements contained are names and MUST be in US-ASCII. Context may > impose additional restrictions on the names. For example, the > names in a name-list may have to be a list of valid algorithm > identifiers (see Section 6 below), or a list of [RFC 3066] language > tags. The order of the names in a name-list may or may not be > significant. Again, this depends on the context in which the list > is used. Terminating null characters MUST NOT be used, neither > for the individual names, nor for the list as a whole. > > Examples: > > value representation (hex) > ----- -------------------- > (), the empty name-list 00 00 00 00 > ("zlib") 00 00 00 04 7a 6c 69 62 > ("zlib,none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 > The definition of a namelist itself states that an entity in the namelist cannot contain 0x2C or 0x00. All of the SEC curve OIDs do contain a 0x00, and it is possible other OIDs contain 0x2C. Cheers, Jon Green From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 14:03:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLwS-00032q-9K for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:03:00 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXLwO-0004EY-Oe for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:03:00 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 304E063B1D6; Tue, 10 Oct 2006 18:02:37 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id BE56863B1CC for ; Tue, 10 Oct 2006 18:02:35 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AGpTdK020162; Tue, 10 Oct 2006 09:51:30 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AGpS8E017580; Tue, 10 Oct 2006 12:51:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9AGpRUB004703; Tue, 10 Oct 2006 12:51:27 -0400 (EDT) Subject: Re: SSH in ECC Internet Draft From: Bill Sommerfeld To: Nicolas Williams Cc: Damien Miller , Sam Hartman , Markus Friedl , Jon Green , ietf-ssh@NetBSD.org In-Reply-To: <20061010161722.GP3878@binky.Central.Sun.COM> References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> <20061010161722.GP3878@binky.Central.Sun.COM> Content-Type: text/plain Date: Tue, 10 Oct 2006 12:51:27 -0400 Message-Id: <1160499087.4380.11.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: > On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: > > IMO that (some) ECC libraries happen to use ASN.1 is not a good reason > > to use it as protocol element. > > The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where > existing SSHv2 constructs could be used instead. The draft's other uses > of ASN.1/DER do not require an implementation of SSHv2 to implement > ASN.1/DER outside ECC libraries, but this one type does. actually, it looks to me like there may be a deeper problem: the same "two level negotiation" issue which affected the gssapi key exchange. I think you need to define a family of ssh key exchanges, one per defined "curve", so that two implementations which support noninteresecting sets of ECC curves but also support other KEX mechanisms can find other common mechanisms. - Bill From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 14:05:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLyr-0003bi-4n for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:05:29 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXLyp-0004Vg-Ov for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:05:29 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 09D1F63B1D9; Tue, 10 Oct 2006 18:05:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id E53B763B1D7 for ; Tue, 10 Oct 2006 18:05:14 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 753890; Tue, 10 Oct 2006 11:59:43 -0600 Message-ID: <452BDF73.3040103@vandyke.com> Date: Tue, 10 Oct 2006 11:59:15 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jon Green CC: Nicolas Williams , Damien Miller , Sam Hartman , Markus Friedl , ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> <20061010161722.GP3878@binky.Central.Sun.COM> <1160499711.24953.28.camel@shiraz.certicom.com> In-Reply-To: <1160499711.24953.28.camel@shiraz.certicom.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Jon Green wrote: > On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: >> On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: >>> IMO that (some) ECC libraries happen to use ASN.1 is not a good reason >>> to use it as protocol element. >> The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where >> existing SSHv2 constructs could be used instead. The draft's other uses >> of ASN.1/DER do not require an implementation of SSHv2 to implement >> ASN.1/DER outside ECC libraries, but this one type does. > > I don't think that we can just remove curves and send a name-list of > OIDs. Encoding and parsing a ASN.1 sequence is easier then encoding and > parsing a ssh namelist full of octet strings. > > So everyone is familiar with what an asn.1 sequence looks like: > [ identifier | length | oid | oid | oid | oid | ... > where each oid contains > [ identifier | length | oid data ] > > The first problem with putting OIDs in name-lists is that the one of the > octets in the OID octet string may be 0x2C (ascii comma) which delimits > the list, so the OIDs will have to be encoded somehow before being put > into a standard namelist, or there has to be a new type of list > defined. If, as it appears, we only need a list of oids, I can think of two ways to do this 'the ssh way.' 1. Encode each oid in the numeric dotted ascii format, i.e., "1.2.840.113554.1.2.2"; comma seperate them, and send as a single string. 2. Encode as uint32 uCount string oid-octet-strings[uCount] or string curves string oid string oid string oid ... > Any list constructs I came up with seemed to be very similar to the > ASN.1 sequence of construct, so i decided to use it. Would including > some psudocode in the draft to encode and parse 'curves' maybe be a good > idea? > > I like using the OIDs to identify curves since there is an already > existing IANA registry and we don't have to reinvent the wheel this > way. Oh... definitely keep the oids... I don't think anyone is arguing against using oids. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 14:07:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXM0W-0005Gz-Uu for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:07:12 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXM0V-0004u6-Ie for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:07:12 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4159A63B1C5; Tue, 10 Oct 2006 18:07:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 77E1663B199 for ; Tue, 10 Oct 2006 18:07:08 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1GXM0M-0002FX-00; Tue, 10 Oct 2006 19:07:02 +0100 From: Ben Harris To: sommerfeld@sun.com Subject: Re: SSH in ECC Internet Draft In-Reply-To: <1160499087.4380.11.camel@thunk> References: <1160074485.7777.30.camel@merlot.certicom.com> <20061010161722.GP3878@binky.Central.Sun.COM> <20061010161722.GP3878@binky.Central.Sun.COM> <1160499087.4380.11.camel@thunk> Organization: Linux Unlimited Cc: ietf-ssh@netbsd.org Message-Id: Date: Tue, 10 Oct 2006 19:07:02 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 In article <1160499087.4380.11.camel@thunk> you write: >On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: >> On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: >> > IMO that (some) ECC libraries happen to use ASN.1 is not a good reason >> > to use it as protocol element. >> >> The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where >> existing SSHv2 constructs could be used instead. The draft's other uses >> of ASN.1/DER do not require an implementation of SSHv2 to implement >> ASN.1/DER outside ECC libraries, but this one type does. > >actually, it looks to me like there may be a deeper problem: the same >"two level negotiation" issue which affected the gssapi key exchange. > >I think you need to define a family of ssh key exchanges, one per >defined "curve", so that two implementations which support >noninteresecting sets of ECC curves but also support other KEX >mechanisms can find other common mechanisms. Um, implementations aren't allowed to support non-intersecting sets of curves, since Appendix A.1 requires all implementations to support four standard curves. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 14:17:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMAx-0001OF-UR for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:17:59 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMAw-0007nD-Lc for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:17:59 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id C039963B1CC; Tue, 10 Oct 2006 18:17:53 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 05BE863B199 for ; Tue, 10 Oct 2006 18:17:52 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 755961; Tue, 10 Oct 2006 12:17:29 -0600 Message-ID: <452BE39A.9090004@vandyke.com> Date: Tue, 10 Oct 2006 12:16:58 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ben Harris CC: sommerfeld@sun.com, ietf-ssh@netbsd.org Subject: Re: SSH in ECC Internet Draft References: <1160074485.7777.30.camel@merlot.certicom.com> <20061010161722.GP3878@binky.Central.Sun.COM> <20061010161722.GP3878@binky.Central.Sun.COM> <1160499087.4380.11.camel@thunk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Ben Harris wrote: > In article <1160499087.4380.11.camel@thunk> you write: >> On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: >>> On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: >>>> IMO that (some) ECC libraries happen to use ASN.1 is not a good reason >>>> to use it as protocol element. >>> The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where >>> existing SSHv2 constructs could be used instead. The draft's other uses >>> of ASN.1/DER do not require an implementation of SSHv2 to implement >>> ASN.1/DER outside ECC libraries, but this one type does. >> actually, it looks to me like there may be a deeper problem: the same >> "two level negotiation" issue which affected the gssapi key exchange. >> >> I think you need to define a family of ssh key exchanges, one per >> defined "curve", so that two implementations which support >> noninteresecting sets of ECC curves but also support other KEX >> mechanisms can find other common mechanisms. > > Um, implementations aren't allowed to support non-intersecting sets of > curves, since Appendix A.1 requires all implementations to support four > standard curves. While the implementation must support them, the site policy may disable them. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 10 14:20:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMD1-00021n-Nd for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:20:07 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMD0-0008T0-BD for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 10 Oct 2006 14:20:07 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 129ED63B199; Tue, 10 Oct 2006 18:20:02 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 4132B63B16F for ; Tue, 10 Oct 2006 18:20:01 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 755977; Tue, 10 Oct 2006 12:19:31 -0600 Message-ID: <452BE41D.5020906@vandyke.com> Date: Tue, 10 Oct 2006 12:19:09 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Bill Sommerfeld CC: Nicolas Williams , Damien Miller , Sam Hartman , Markus Friedl , Jon Green , ietf-ssh@NetBSD.org Subject: Re: SSH in ECC Internet Draft References: <1160074485.7777.30.camel@merlot.certicom.com> <20061009093248.GB24007@folly> <20061010161722.GP3878@binky.Central.Sun.COM> <1160499087.4380.11.camel@thunk> In-Reply-To: <1160499087.4380.11.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Bill Sommerfeld wrote: > On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote: >> On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote: >>> IMO that (some) ECC libraries happen to use ASN.1 is not a good reason >>> to use it as protocol element. >> The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where >> existing SSHv2 constructs could be used instead. The draft's other uses >> of ASN.1/DER do not require an implementation of SSHv2 to implement >> ASN.1/DER outside ECC libraries, but this one type does. > > actually, it looks to me like there may be a deeper problem: the same > "two level negotiation" issue which affected the gssapi key exchange. > > I think you need to define a family of ssh key exchanges, one per > defined "curve", so that two implementations which support > noninteresecting sets of ECC curves but also support other KEX > mechanisms can find other common mechanisms. You could take the route that gssapi did and base64 encode the curve oid and make it part of the name: "ssh-ecc-,ssh-ecc-" Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 16 13:09:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVyQ-0002px-HB for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 16 Oct 2006 13:09:58 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVyO-0001YX-Qm for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 16 Oct 2006 13:09:58 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 67D9463B104; Mon, 16 Oct 2006 17:09:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by mail.netbsd.org (Postfix) with ESMTP id AE73263B4A4 for ; Mon, 16 Oct 2006 17:09:34 +0000 (UTC) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 2E4741023A2B8 for ; Mon, 16 Oct 2006 13:09:31 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23879-18 for ; Mon, 16 Oct 2006 13:09:28 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 5AF1010239493 for ; Mon, 16 Oct 2006 13:09:28 -0400 (EDT) Received: from merlot.certicom.com ([10.24.0.140]) by certicom1.certicom.com (Lotus Domino Release 7.0.1) with ESMTP id 2006101613075694-13258 ; Mon, 16 Oct 2006 13:07:56 -0400 Subject: ECC in SSH draft version -01 From: Jon Green To: ietf-ssh@netbsd.org Organization: Certicom Date: Mon, 16 Oct 2006 13:09:26 -0400 Message-Id: <1161018566.28037.13.camel@merlot.certicom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/16/2006 01:07:56 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/16/2006 01:07:58 PM, Serialize complete at 10/16/2006 01:07:58 PM Content-Type: multipart/mixed; boundary="=-K3l0fjndAW2ez/XMnRcS" Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6114c32714d9d375c08d057a5b20b8b4 --=-K3l0fjndAW2ez/XMnRcS Content-Transfer-Encoding: 7bit Content-Type: text/plain Thank you for all the comments on draft-green-secsh-ecc-00. I've addressed a lot of the concerns that were raised with a new version of this draft draft-green-secsh-ecc-01. I submitted the new version to the IETF, but I'm not sure if I made the deadline for drafts to be posted, so I attached it to the message as well, while I wait for it to be posted. Specifically I addressed the problems with double negotiation within the protocol and in doing so, made the ASN.1 in the document redundant, so I moved away from ASN.1 messages. I'm would appreciate any comments you have on the revised version of the draft. Thanks, -- Jon Green Research Intern Certicom Corp. --=-K3l0fjndAW2ez/XMnRcS Content-Transfer-Encoding: 7bit Content-Type: text/plain; name=draft-green-secsh-ecc-01.txt; charset=us-ascii Content-Disposition: attachment; filename=draft-green-secsh-ecc-01.txt Secure Shell Working Group J. Green Internet-Draft Certicom Expires: April 19, 2007 D. Stebila U Waterloo October 16, 2006 Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer draft-green-secsh-ecc-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. Green & Stebila Expires April 19, 2007 [Page 1] Internet-Draft SSH ECC Algorithm Integration October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ECC Public Key Algorithm . . . . . . . . . . . . . . . . . . . 5 3.1. Key/Signature Encoding . . . . . . . . . . . . . . . . . . 6 4. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 8 5. ECMQV Key Exchange and Verification . . . . . . . . . . . . . 10 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. ECC Public Key Algorithm Identifiers . . . . . . . . . . . 14 6.2. ECDH Key Exchange Method Names . . . . . . . . . . . . . . 14 6.3. ECMQV Key Exchange and Verification Method Names . . . . . 15 7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 16 7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 16 7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 Appendix A. Named Elliptic Curve Domain Parameters . . . . . . . 18 Appendix A.1. Required and Recommended Curves . . . . . . . . . . 18 Appendix A.2. SEC Equivalent NIST Curves and OIDs . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Green & Stebila Expires April 19, 2007 [Page 2] Internet-Draft SSH ECC Algorithm Integration October 2006 1. Introduction Due to its inclusion in NSA's Suit B and its small key sizes elliptic curve cryptography (ECC) is becoming a widely utilized and attractive public-key cryptosystem. In the interest of adding Suit B algorithms to SSH this document adds three ECC Suit B algorithms to the Secure Shell arsenal: Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) as well as utilizing the SHA2 family of secure hash algorithms. Compared to cryptosystems such as RSA, DSA, and DH, ECC variations on these schemes offer equivalent security with smaller key sizes. This is illustrated in the following table, based on Section 5.6.1 of NIST 800-57 [9], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best known algorithms for attacking them. L is field size and N is sub-field size. +-----------+-----------------------------+-------+---------+ | Symmetric | Discrete Log (eg. DSA, DH) | RSA | ECC | +-----------+-----------------------------+-------+---------+ | 80 | L = 1024 N = 160 | 1024 | 160-223 | | | | | | | 112 | L = 2048 N = 256 | 2048 | 224-255 | | | | | | | 128 | L = 3072 N = 256 | 3072 | 256-383 | | | | | | | 192 | L = 7680 N = 384 | 7680 | 384-511 | | | | | | | 256 | L = 15360 N = 512 | 15360 | 512+ | +-----------+-----------------------------+-------+---------+ Figure 1: Comparable key sizes (in bits). Smaller key sizes result in power, bandwidth, and computational savings that make ECC especially attractive for constrained environments. Implementation of this specification requires familiarity with both SSH [2] [3] [4] and ECC [6] [10] [11]. Green & Stebila Expires April 19, 2007 [Page 3] Internet-Draft SSH ECC Algorithm Integration October 2006 2. Notation 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 [1]. The data types boolean, uint32, uint64, string, and mpint are to be interpreted in this document as described in RFC 4251 [2]. The size of a set of elliptic curve domain parameters on a prime curve is defined as the number of bits in the binary representation of the field order, commonly denoted p. Size on a characteristric-2 curve is defined as the number of bits in the binary representation of the field, commonly denoted m. Protocol fields and possible values to fill them in are defined in this set of documents. As an example SSH_MSG_KEX_ECDH_INIT is defined as follows. byte SSH_MSG_KEX_ECDH_INIT string pK, public key octet string. Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill in those fields are referenced they will appear in double quotes. Green & Stebila Expires April 19, 2007 [Page 4] Internet-Draft SSH ECC Algorithm Integration October 2006 3. ECC Public Key Algorithm The ECC public key algorithm defines ECC public keys, private keys and signatures for use within the SSH protocol. When ECC is chosen as the public key algorithm through key exchange negotiations the server's long term ECC key pair, which are called host keys throughout this draft, is used for identification and verification. When asked to sign communications or verify signatures by the key exchange method the elliptic curve digital signature algorithm (ECDSA) is used. The algorithmic details of ECDSA can be found in Section 4 of SEC 1 [6] and in [13]. This document is concerned with the SSH implementation details; specification of the algorithm is left to other standards documents. The message hashing algorithm to be used with ECDSA is the same one specified to generate the exchange hash in the key exchange method chosen during algorithm negotiation. If the chosen key exchange method doesn't specify a hashing function then SHA-256 [5] will be used. The algorithm for ECC key generation can be found in section 3.2 of SEC 1 [6]. Given some elliptic curve domain parameters, an ECC key pair can be generated containing an integer d that makes up the secret key and an elliptic curve point Q which makes up the public key. The elliptic curve domain parameters to generate EC keys can be produced at random, but this is a costly operation and may result in the use of domain parameters of which the security hasn't been tested. Because of this, standards bodies have produced named sets of elliptic curve domain parameters or named curves. This public key algorithm only allows named curves, specified by their ASN.1 OIDs, to be used. Details of the curves that are required and recommended are outlined in Appendix A. The family of public key algorithm identifiers for ECC is specified in Section 6.1. For the remainder of this section [identifier] will represent the ECC Public Key Algorithm identifier determined in Section 6.1. Green & Stebila Expires April 19, 2007 [Page 5] Internet-Draft SSH ECC Algorithm Integration October 2006 3.1. Key/Signature Encoding The ecc public key has the following encoding: string [identifier] string Q Where Q is the elliptic curve point that forms the public key. Here Q is encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of SEC1 [6]. The ECDSA signature has the following encoding: string [identifier] mpint r mpint s Where the integers R and S are the output of the ECDSA algorithm. Green & Stebila Expires April 19, 2007 [Page 6] Internet-Draft SSH ECC Algorithm Integration October 2006 4. ECDH Key Exchange 4.1. Description The Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm generates a shared secret from an ephemeral elliptic curve private key contributed by the local entity and an ephemeral elliptic curve public key contributed by the remote entity. When this algorithm is applied on both the client and the server both will derive the same shared key. The family of key exchange method names defined for use with this key exchange can be found in Section 6.2. The rest of this section is an informal overview of the ECDH key exchange mechanism. A formal description can be found in Section 4.2. In the following: C is the client, S is the server; NC is the named curve specified in the algorithm name; cPK is the client's ephemeral public key; sPK is the server's ephemeral public key; K_S is the server's public host key; H is the exchange hash; s is the signature on H; and K is the shared secret. 1. C generates an ephemeral elliptic curve key pair on NC and sends the public-key value 'cPK'. 2. S SHOULD validate 'cPK' using, for example, algorithm A.16.10 of [10]. S generates an ephemeral public-key / private-key pair on NC. S uses 'cPK' and S's ephemeral private key value to compute the shared secret K using ECDH. S computes H and the signature 's' on H using its private host key. S sends "K_S || sPK || s". 3. C SHOULD validate 'sPK', for example, algorithm A.16.10 of [10]. C verifies that 'K_S' really is the public host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks. C uses 'sPK' and C's ephemeral private key to compute the shared secret and verifies the signature 's' on H. The size of the named curve specified in the algorithm name SHOULD be greater than 160 bits and preferably at least 224 bits. The size of the curve used SHOULD be in line with the bulk encryption algorithm chosen during algorithm negotiation. Green & Stebila Expires April 19, 2007 [Page 7] Internet-Draft SSH ECC Algorithm Integration October 2006 4.2. Implementation This document is concerned with describing the implementation of ECDH in SSH, not the specification of the algorithm itself. The algorithm used for shared key generation is ECDH, the full specification of which can be found in Section 3.3.2 of SEC1 [6]. The algorithm for generation of EC key pairs can be found in Section 3.2 of SEC1 [6]. This algorithm is necessary to generate the ephemeral EC key pairs needed for ECDH. The elliptic curve points (ephemeral public keys) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in SEC1 Section 2.3 [6]. The hash algorithm HASH for computing the exchange hash is determined by the size of the named curve specified in the method name. The method for choosing a hash function can be seen in the table below where b is the size of the curve [5]: +----------------+----------------+ | Curve Size | Hash Algorithm | +----------------+----------------+ | b <= 256 | SHA-256 | | | | | 256 < b <= 384 | SHA-384 | | | | | 384 < b | SHA-512 | +----------------+----------------+ Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are found in Section 7. Green & Stebila Expires April 19, 2007 [Page 8] Internet-Draft SSH ECC Algorithm Integration October 2006 The ECDH key exchange algorithm is implemented with the following messages. The public key algorithm for signing is negotiated with the KEXINIT messages. The client sends: byte SSH_MSG_KEX_ECDH_INIT string cPK, the octet string formed from the client's ephemeral public key. The server responds with: byte SSH_MSG_KEX_ECDH_REPLY string K_S, server public host key and/or certificates string sPK, the octet string formed from the server's ephemeral public key. string s, the signature of H The exchange hash H is computed as the HASH of the concatenation of the following. string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the server's public host key string cPK, the client's ephemeral public key octet string. string sPK, the server's ephemeral public key octet string. mpint K, the shared secret Green & Stebila Expires April 19, 2007 [Page 9] Internet-Draft SSH ECC Algorithm Integration October 2006 5. ECMQV Key Exchange and Verification 5.1. Description The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm generates a shared secret from two elliptic curve key pairs owned by one entity and two elliptic curve public keys owned by another entity. Both entities' roles are analogous in the algorithm. Using it's key pairs and the other entity's public keys, both entities' will derive the same secret. The family of key exchange method names defined for use with this key exchange can be found in Section 6.3. The following is an informal discussion of ECMQV key exchange and verification for a formal description see Section 5.2. The client doesn't necessarily have a long term key under the existing SSH protocol. Instead of generating two ephemeral key pairs the client generates one ephemeral key pair and uses it for all the keys it is required to supply. This is illustrated below considering the ECMQV algorithm in terms of a black box: Local Keys |-----|-|-----| Remote Keys ECMQV Block: _______ Key Pair ----| |---- Public Key | ECMQV | Key Pair ----|_______|---- Public Key | shared secret Server Configuration: _______ Server Host Key ----| |---- Pair | ECMQV | |-- Client Ephemeral Server Ephemeral Key ----|_______|---- Public Key Pair | shared secret Client Configuration: _______ ----| |---- Server Public Host Key Client Ephemeral --| | ECMQV | Key Pair ----|_______|---- Server Ephemeral Public | Key shared secret Green & Stebila Expires April 19, 2007 [Page 10] Internet-Draft SSH ECC Algorithm Integration October 2006 In the following: C is the client; S is the server; NC is the curve from the method name; K_S is the server's public host key; sPK is the server's ephemeral public key; cPK is the client's ephemeral public key; H is the exchange hash; T is the HMAC tag of H; and K is the shared secret. 1. C uses the domain parameters associated with NC to generate an ephemeral ECC public/private key pair. C sends 'cPK'. 2. S SHOULD validate 'cPK' using, for example, algorithm A.16.10 of [10]. S generates an ephemeral public/private key pair using NC. S generates K using its private host key, its private ephemeral key and 'cPK'. S computes H and the message authentication code (MAC) tag 'T' on H using K as the key. S then sends "K_S || sPK || T". 3. C SHOULD validate 'sPK' and 'K_S' as above. C verifies that 'K_S' really is the public host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks. C generates K using its private ephemeral key, 'sPK' and 'K_S'. C independently computes H and verifies the tag 'T' is valid. We use a MAC tag with K as a key for verification of communication with S because the private host key was used to create K, eliminating the need for a costly signing algorithm. 5.2. Implementation This document is concerned with describing the implementation of ECMQV in SSH, not the specification of the algorithm itself. A full description of ECMQV can be found in Section 3.4 of SEC1 [6]. An implementation of SSH supporting ECMQV MUST support the ECC Public Key Algorithm (Section 3). If during the key exchange algorithm negotiation ECMQV is chosen as the key exchange algorithm then the ECC Public Key Algorithm MUST be selected as the server host key algorithm. This is due to the fact that ECMQV uses the servers ECC host keys within the key exchange. The server's host keys are used in shared key generation; therefore, the named curve used to generate them is the curve that must be used by the ECMQV algorithm. Care should be taken that the server's host key is sufficiently strong to ensure that the ECMQV algorithm isn't the weakest point in the SSH encryption suite. Green & Stebila Expires April 19, 2007 [Page 11] Internet-Draft SSH ECC Algorithm Integration October 2006 The elliptic curve points (public keys) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in SEC1 Section 2.3 [6]. The hash algorithm HASH for computing the exchange hash is determined by the strength of the named curve used by ECMQV. The method for choosing a hash function can be seen in the table below where b is the size of the curve [5]: +----------------+----------------+ | Curve Size | Hash Algorithm | +----------------+----------------+ | b <= 256 | SHA-256 | | | | | 256 < b <= 384 | SHA-384 | | | | | 384 < b | SHA-512 | +----------------+----------------+ The hash function chosen above is also the hash function that is used to implement the HMAC used for server identification and verification. The algorithm for implementing HMAC with any of the above hash functions can be found in [5]. The specification of the message numbers SSH_MSG_ECMQV_INIT and SSH_MSG_ECMQV_REPLY can be found in Section 7. The algorithm for generation of EC key pairs can be found in SEC1 Section 3.2 [6]. This algorithm is necessary to generate the ephemeral EC key pairs needed for ECMQV. Green & Stebila Expires April 19, 2007 [Page 12] Internet-Draft SSH ECC Algorithm Integration October 2006 This key exchange algorithm is implemented with the following messages. The client sends: byte SSH_MSG_ECMQV_INIT string cPK, The octet string formed from the client's ephemeral public key. The server sends: byte SSH_MSG_ECMQV_REPLY string K_S, Server public host key octet string string sPK, Server ephemeral public key octet string string T, The HMAC tag computed on H using the shared secret The hash H is formed by applying the algorithm HASH on a concatenation of the following: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string cPK, client's ephemeral public key octet string K_S, server's public host key octet string sPK, server's ephemeral public key octet mpint K, the shared secret Green & Stebila Expires April 19, 2007 [Page 13] Internet-Draft SSH ECC Algorithm Integration October 2006 6. IANA Considerations This document defines two new families of key exchange method names and one new family of public key algorithm name in the SSH name registry. These additions to the SSH name space will have to be approved the IANA. The specification of these families is found below. 6.1. ECC Public Key Algorithm Identifiers The ECC Public Key Algorithm specifies a family of identifiers. The general format for this family of identifiers is the string "secg- ecc-" concatenated with the ASN.1 OID, in dotted decimal format, of the named curve domain parameters that are associated with the server's ECC host keys [8]. There are two other identifiers in the ECC Public Key family that are only to be used only by the client during algorithm negotiation in SSH_MSG_KEXINIT messages. These identifiers can: not be used at all, used on their own, or used in concert with normal "secg-ecc-[oid]" identifiers to specify additional supported named curves that the are not included in the special identifiers. "secg-ecc-standard" tells the server that the clients local security policy has not disabled any of the required curves specified in Appendix A and is analogous to sending "secg-ecc-1.3.132.0.37,secg- ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-ecc-1.2.840.10045.3.1.7". "secg-ecc-extended" tells the server that the client supports all of the curves specified in Appendix A and is analogous to sending "secg- ecc-1.3.132.0.38,secg-ecc-1.3.132.0.35,secg-ecc-1.3.132.0.37,secg- ecc-1.3.132.0.36,secg-ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg- ecc-1.2.840.10045.3.1.7,secg-ecc-1.3.132.0.27,secg-ecc- 1.3.132.0.26,secg-ecc-1.3.132.0.33,secg-ecc-1.2.840.10045.3.1.1,secg- ecc-1.3.132.0.1". 6.2. ECDH Key Exchange Method Names The Elliptic Curve Diffie-Hellman key exchange is defined by a family of method names. Each method name consists of the string "ecdh- sha2-" concatenated with the ASN.1 OID of the named curve, in dotted decimal notation, to be used for ephemeral key generation within the key exchange algorithm [8]. Information on the named curves that are required and recommended can be found in Appendix A. Green & Stebila Expires April 19, 2007 [Page 14] Internet-Draft SSH ECC Algorithm Integration October 2006 6.3. ECMQV Key Exchange and Verification Method Names The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by a family of method names that specify what named curve will be used within the key exchange. Each method name consists of the string "ecmqv-sha2-" concatenated with the ASN.1 OID of the named curve to be used in dotted decimal notation. Information on the named curves that are required and recommended can be found in Appendix A [8]. When the server forms its 'server_host_key_algorithms' name-list it MUST include only the algorithm from the "ecmqv-sha2-*" family that corresponds to the named curve used to produce its ECC host keys. If the server doesn't have an ECC host key then the server MUST NOT put any members of the "ecmqv-sha2-*" family of algorithms in the 'server_host_key_algorithms' name-list. Green & Stebila Expires April 19, 2007 [Page 15] Internet-Draft SSH ECC Algorithm Integration October 2006 7. Key Exchange Messages The message numbers 30-49 are key exchange-specific and in a private namespace defined in RFC4250 [4] that may be redefined by any key exchange method [3] without being granted IANA permission. The following message numbers have been defined in this document: 7.1. ECDH Message Numbers #define SSH_MSG_KEX_ECDH_INIT 30 #define SSH_MSG_KEX_ECDH_REPLY 31 7.2. ECMQV Message Numbers #define SSH_MSG_ECMQV_INIT 30 #define SSH_MSG_ECMQV_REPLY 31 Green & Stebila Expires April 19, 2007 [Page 16] Internet-Draft SSH ECC Algorithm Integration October 2006 8. Security Considerations The Elliptic Curve Diffie-Hellman key agreement algorithm is defined in [6], [10] and [11]. The appropriate security considerations of those documents apply. The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is defined in [6]. The security considerations raised in that document also apply. A more detailed discussion of security considerations can be found in The Guide to Elliptic Curve Cryptography section 4.7 [14]. The methods defined in Section 4 rely on the SHA family of hashing functions as defined in [15]. The appropriate security considerations of that document apply. Additionally a good general discussion of the security considerations that must be taken into account when creating an ECC implementation can be found in The Guide to Elliptic Curve Cryptography section 5 [14]. Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and thus arbitrary security strength, it is important that the size of elliptic curve be chosen to match the security strength of other elements of the SSH handshake. In particular, host key sizes, hashing algorithms and bulk encryption algorithms must be chosen appropriately. Information regarding estimated equivalence of key sizes is available in [9]. Green & Stebila Expires April 19, 2007 [Page 17] Internet-Draft SSH ECC Algorithm Integration October 2006 Appendix A. Named Elliptic Curve Domain Parameters Implementations may support any ASN.1 object identifier (OID) in the ASN.1 object tree that defines a set of elliptic curve domain parameters [8]. Appendix A.1. Required and Recommended Curves Every SSH ECC implementation MUST support the named curves below, these curves are defined in SEC2 [7]. These curves should always be enabled unless specifically disabled by local security policy. secp256r1 sect283k1 secp384r1 sect409k1 It is RECOMMENDED that SSH ECC implementations also support the following curves. sect163k1 secp192r1 sect233k1 secp224r1 sect233r1 sect409r1 secp521r1 sect571k1 Appendix A.2. SEC Equivalent NIST Curves and OIDs +-----------+----------+---------------------+ | SEC | NIST[12] | OID[7] | +-----------+----------+---------------------+ | sect163k1 | nistk163 | 1.3.132.0.1 | | | | | | secp192r1 | nistp192 | 1.2.840.10045.3.1.1 | | | | | | secp224r1 | nistp224 | 1.3.132.0.33 | | | | | | sect233k1 | nistk233 | 1.3.132.0.26 | | | | | | sect233r1 | nistb233 | 1.3.132.0.27 | | | | | | secp256r1 | nistp256 | 1.2.840.10045.3.1.7 | | | | | | sect283k1 | nistk283 | 1.3.132.0.16 | | | | | | secp384r1 | nistp384 | 1.3.132.0.34 | | | | | | sect409k1 | nistk409 | 1.3.132.0.36 | | | | | | sect409r1 | nistb409 | 1.3.132.0.37 | | | | | | secp521r1 | nistp521 | 1.3.132.0.35 | | | | | | sect571k1 | nistk571 | 1.3.132.0.38 | +-----------+----------+---------------------+ Green & Stebila Expires April 19, 2007 [Page 18] Internet-Draft SSH ECC Algorithm Integration October 2006 9. Acknowledgements Douglas Stebila wishes to thank Sheueling Chang and Vipul Gupta of Sun Microsystems. The work on draft-stebila-secsh-ecdh-01, of which this work is a derivative document, was largely performed during a student internship at Sun Microsystems Laboratories from the University of Waterloo. Jon Green would like to thank Robert Lambert of Certicom for all the help and knowledge he provided. This document was written during an internship at Certicom from Queens University. Green & Stebila Expires April 19, 2007 [Page 19] Internet-Draft SSH ECC Algorithm Integration October 2006 10. References 10.1. Normative References [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Protocol Architecture", RFC 4251, January 2006. [3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Transport Layer Protocol", RFC 4253, January 2006. [4] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell Protocol Assigned Numbers", RFC 4250, January 2006. [5] Eastlake, 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [6] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1 v1.0, September 2000. [7] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2 v1.0, September 2000. [8] International Telecommunication Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680 , July 2002. Green & Stebila Expires April 19, 2007 [Page 20] Internet-Draft SSH ECC Algorithm Integration October 2006 10.2. Informative References [9] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1", NIST Special Publication 800-57. [10] Institute of Electrical and Electronics Engineers, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000. [11] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: Key Agreement and key Transport Using Elliptic Curve Cryptography", ANSI X9.63, November 2001. [12] National Institute of Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", August 1999. [13] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry The Elliptic Curve Digital Signature Algorithm", ANSI X9.62, 1998. [14] Hankerson, Menezes, and Vanstone, "Guide to Elliptic Curve Cryptography", 2004, . [15] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, August 2002. Green & Stebila Expires April 19, 2007 [Page 21] Internet-Draft SSH ECC Algorithm Integration October 2006 Authors' Addresses Jon Green Certicom 5520 Explorer Drive 4th Floor Mississauga, ON L4W 5L1 Canada Email: jgreen@certicom.com Douglas Stebila Department of Combinatorics and Optimization University of Waterloo Waterloo, ON N2L 3G1 Canada Email: douglas@stebila.ca Green & Stebila Expires April 19, 2007 [Page 22] Internet-Draft SSH ECC Algorithm Integration October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Green & Stebila Expires April 19, 2007 [Page 23] --=-K3l0fjndAW2ez/XMnRcS-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 17 18:02:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZx1J-00062X-01 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 17 Oct 2006 18:02:45 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZx1H-0001cd-MH for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 17 Oct 2006 18:02:44 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 841C763B393; Tue, 17 Oct 2006 22:02:28 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 6E3CC63B115 for ; Tue, 17 Oct 2006 22:02:26 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1GZx0y-0003k9-00; Tue, 17 Oct 2006 23:02:24 +0100 From: Ben Harris To: jgreen@certicom.com Subject: Re: ECC in SSH draft version -01 In-Reply-To: <1161018566.28037.13.camel@merlot.certicom.com> References: <1161018566.28037.13.camel@merlot.certicom.com> Organization: Linux Unlimited Cc: ietf-ssh@netbsd.org Message-Id: Date: Tue, 17 Oct 2006 23:02:24 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da In article <1161018566.28037.13.camel@merlot.certicom.com> you write: >Specifically I addressed the problems with double negotiation within the >protocol and in doing so, made the ASN.1 in the document redundant, so I >moved away from ASN.1 messages. > >I'm would appreciate any comments you have on the revised version of the >draft. The changes generally seem quite sensible, and in particular they address a problem I hadn't even got around to articulating with the old draft -- that a server's host key might use a curve not supported by the client. >4.2. Implementation > > This document is concerned with describing the implementation of ECDH > in SSH, not the specification of the algorithm itself. The algorithm > used for shared key generation is ECDH, the full specification of > which can be found in Section 3.3.2 of SEC1 [6]. I feel that it might be worth referring to the primitive specified in that section by name, especially since it's not the one that SEC1 calls "elliptic curve Diffie-Hellman". I note that the output of ECDH is a field element, so you should probably specify how that gets transformed into the integer K required by SSH. I'd guess that you use the FieldElement-to-Integer conversion in section 2.3.9 of SEC1, but you don't seem to say so. The same applies to ECMQV. > The server's host keys are used in shared key generation; therefore, > the named curve used to generate them is the curve that must be used > by the ECMQV algorithm. Care should be taken that the server's host > key is sufficiently strong to ensure that the ECMQV algorithm isn't > the weakest point in the SSH encryption suite. _Something_ has to be the weakest point. Why shouldn't it be ECMQV? > "secg-ecc-standard" tells the server that the clients local security > policy has not disabled any of the required curves specified in > Appendix A and is analogous to sending "secg-ecc-1.3.132.0.37,secg- > ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-ecc-1.2.840.10045.3.1.7". > > "secg-ecc-extended" tells the server that the client supports all of > the curves specified in Appendix A and is analogous to sending "secg- > ecc-1.3.132.0.38,secg-ecc-1.3.132.0.35,secg-ecc-1.3.132.0.37,secg- > ecc-1.3.132.0.36,secg-ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg- > ecc-1.2.840.10045.3.1.7,secg-ecc-1.3.132.0.27,secg-ecc- > 1.3.132.0.26,secg-ecc-1.3.132.0.33,secg-ecc-1.2.840.10045.3.1.1,secg- > ecc-1.3.132.0.1". I'm a little suspicious of these. They make it harder to use existing code for processing algorithm lists for the sake aof a few bytes in each KEXINIT, which I think is a poor trade-off. > When the server forms its 'server_host_key_algorithms' name-list it > MUST include only the algorithm from the "ecmqv-sha2-*" family that > corresponds to the named curve used to produce its ECC host keys. That seems to require that any used with an ECC host key MUST support ECMQV. I doubt that is what you intended. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 23 14:32:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4b7-0001bX-IY for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 23 Oct 2006 14:32:29 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc4aw-0000jt-4I for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 23 Oct 2006 14:32:29 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4E7F063B303; Mon, 23 Oct 2006 18:32:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 21F4863B100 for ; Mon, 23 Oct 2006 18:32:02 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 814154; Mon, 23 Oct 2006 12:32:01 -0600 Message-ID: <453D0AA0.4010406@vandyke.com> Date: Mon, 23 Oct 2006 12:32:00 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ben Harris CC: jgreen@certicom.com, ietf-ssh@netbsd.org Subject: Re: ECC in SSH draft version -01 References: <1161018566.28037.13.camel@merlot.certicom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Ben Harris wrote: > In article <1161018566.28037.13.camel@merlot.certicom.com> you write: >> Specifically I addressed the problems with double negotiation within the >> protocol and in doing so, made the ASN.1 in the document redundant, so I >> moved away from ASN.1 messages. >> >> I'm would appreciate any comments you have on the revised version of the >> draft. > > The changes generally seem quite sensible, and in particular they > address a problem I hadn't even got around to articulating with the old > draft -- that a server's host key might use a curve not supported by the > client. > >> 4.2. Implementation >> >> This document is concerned with describing the implementation of ECDH >> in SSH, not the specification of the algorithm itself. The algorithm >> used for shared key generation is ECDH, the full specification of >> which can be found in Section 3.3.2 of SEC1 [6]. > > I feel that it might be worth referring to the primitive specified in > that section by name, especially since it's not the one that SEC1 calls > "elliptic curve Diffie-Hellman". > > I note that the output of ECDH is a field element, so you should > probably specify how that gets transformed into the integer K required > by SSH. I'd guess that you use the FieldElement-to-Integer conversion > in section 2.3.9 of SEC1, but you don't seem to say so. > > The same applies to ECMQV. > >> The server's host keys are used in shared key generation; therefore, >> the named curve used to generate them is the curve that must be used >> by the ECMQV algorithm. Care should be taken that the server's host >> key is sufficiently strong to ensure that the ECMQV algorithm isn't >> the weakest point in the SSH encryption suite. > > _Something_ has to be the weakest point. Why shouldn't it be ECMQV? > >> "secg-ecc-standard" tells the server that the clients local security >> policy has not disabled any of the required curves specified in >> Appendix A and is analogous to sending "secg-ecc-1.3.132.0.37,secg- >> ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-ecc-1.2.840.10045.3.1.7". >> >> "secg-ecc-extended" tells the server that the client supports all of >> the curves specified in Appendix A and is analogous to sending "secg- >> ecc-1.3.132.0.38,secg-ecc-1.3.132.0.35,secg-ecc-1.3.132.0.37,secg- >> ecc-1.3.132.0.36,secg-ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg- >> ecc-1.2.840.10045.3.1.7,secg-ecc-1.3.132.0.27,secg-ecc- >> 1.3.132.0.26,secg-ecc-1.3.132.0.33,secg-ecc-1.2.840.10045.3.1.1,secg- >> ecc-1.3.132.0.1". > > I'm a little suspicious of these. They make it harder to use existing > code for processing algorithm lists for the sake aof a few bytes in each > KEXINIT, which I think is a poor trade-off. I thought there was a ceiling on the length of the name-list strings during key exchange (something like 256), but I can't find it now. If I'm blind and not dreaming, then the string above is probably a bit on the long side... If I dreaming and not blind on the other hand, than I think I agree... the 'meta-names' will just make implementation more difficult. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 23 19:30:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc9Fx-0008Du-9a for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 23 Oct 2006 19:30:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc5G3-0005cx-Bo for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 23 Oct 2006 15:14:47 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc51P-00089f-7E for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 23 Oct 2006 14:59:44 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 9970163B3FD; Mon, 23 Oct 2006 18:59:23 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 439FC63B3F0 for ; Mon, 23 Oct 2006 18:59:22 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA13017; Mon, 23 Oct 2006 14:59:21 -0400 (EDT) From: der Mouse Message-Id: <200610231859.OAA13017@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 23 Oct 2006 14:55:02 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: ECC in SSH draft version -01 In-Reply-To: <453D0AA0.4010406@vandyke.com> References: <1161018566.28037.13.camel@merlot.certicom.com> <453D0AA0.4010406@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 > I thought there was a ceiling on the length of the name-list strings > during key exchange (something like 256), but I can't find it now. There is a ceiling, in that too large a list will blow out the 35000-octet minimum packet size limit. But it's a long way from 256. My own implementation offers arcfour-64k@rodents.montreal.qc.ca blowfish-ctr aes128-ctr blowfish-cbc aes128-cbc aes192-cbc aes192-ctr aes256-cbc aes256-ctr idea-cbc arcfour128-draft-00@putty.projects.tartarus.org arcfour256-draft-00@putty.projects.tartarus.org 3des-cbc 3des-ctr arcfour rijndael-k4b4-cbc@rodents.montreal.qc.ca rijndael-k4b6-cbc@rodents.montreal.qc.ca rijndael-k4b8-cbc@rodents.montreal.qc.ca rijndael-k6b4-cbc@rodents.montreal.qc.ca rijndael-k6b6-cbc@rodents.montreal.qc.ca rijndael-k6b8-cbc@rodents.montreal.qc.ca rijndael-k8b4-cbc@rodents.montreal.qc.ca rijndael-k8b6-cbc@rodents.montreal.qc.ca rijndael-k8b8-cbc@rodents.montreal.qc.ca rijndael-k4b4-ctr@rodents.montreal.qc.ca rijndael-k4b6-ctr@rodents.montreal.qc.ca rijndael-k4b8-ctr@rodents.montreal.qc.ca rijndael-k6b4-ctr@rodents.montreal.qc.ca rijndael-k6b6-ctr@rodents.montreal.qc.ca rijndael-k6b8-ctr@rodents.montreal.qc.ca rijndael-k8b4-ctr@rodents.montreal.qc.ca rijndael-k8b6-ctr@rodents.montreal.qc.ca rijndael-k8b8-ctr@rodents.montreal.qc.ca rijndael-cbc@lysator.liu.se which is just a hair under 1K of algorithm names, and, while I haven't tested it extensively against a wide variety of implementations, I haven't run into anything that either objects or breaks in response to that. > If I dreaming and not blind on the other hand, than I think I > agree... the 'meta-names' will just make implementation more > difficult. That is my own take on it. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B