From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 11 09:08:46 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19E928C1B5 for ; Tue, 11 Nov 2008 09:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fR902fNeB2K for ; Tue, 11 Nov 2008 09:08:44 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 672D03A6A5B for ; Tue, 11 Nov 2008 09:08:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id A271363B171; Tue, 11 Nov 2008 17:08:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id DD99B63B159 for ; Tue, 11 Nov 2008 17:08:31 +0000 (UTC) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mABFxWOq025016 for ; Tue, 11 Nov 2008 15:59:43 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA600001D6RVV00@fe-emea-09.sun.com> (original mail from Jan.Pechanec@Sun.COM) for ietf-ssh@NetBSD.org; Tue, 11 Nov 2008 15:59:32 +0000 (GMT) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA600CQLF359M70@fe-emea-09.sun.com>; Tue, 11 Nov 2008 15:59:30 +0000 (GMT) Date: Tue, 11 Nov 2008 16:59:19 +0100 (CET) From: Jan Pechanec Subject: Re: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer In-reply-to: <7327DF90-C0CB-45E9-8606-64854CAD4431@stebila.ca> X-X-Sender: jp161948@fossa.czech.sun.com To: Douglas Stebila Cc: ietf-ssh@NetBSD.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT References: <7327DF90-C0CB-45E9-8606-64854CAD4431@stebila.ca> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 1 Oct 2008, Douglas Stebila wrote: > A new version of the ECC in SSH draft is now available for review. > > http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-03.txt hi Douglas, I like the draft, and have some comments. - section 1, ECMQV has been dropped from the National Security Agency's Suite B. I don't know when but it's not there now: http://www.nsa.gov/ia/industry/crypto_suite_b.cfm I'm wondering if an inclusion of that in this draft may not cast some shadow on it in general as including something that might have potential legal issues if used. - section 4, this might be just a language issue; does this imply that the remote key pair is ephemeral as well or not? Or would it be better to say "and ephemeral remote public key"? The Elliptic Curve Diffie-Hellman (ECDH) key exchange method generates a shared secret from an ephemeral elliptic curve local private key and remote public key. - section 4, you may want to reference RFC 4251, 4.1 (Host Keys) and section 9.3.4 (Man-in-the-middle) in the "*" paragraph. Same in section 5. Or it could be at one common place so that it's not duplicated. - section 4, "The exchange hash H is computed as the hash of the concatenation of the following.", please change NL to LF. NL is EBCDIC's notation, not ASCII. - section 4, you may want to change "version string" to "identification string" since that's what RFC 4253 almost exclusively uses. Same in 5. - section 5. I don't know very much about ECC so I have a question. I understand that we can use implicit server authentication since server's private key is already involved in the generation of the shared secret. So, HMAC instead of the ECDSA is then used just because it's faster? - is it needed to include shared secret in the hash input when we already use it in HMAC on the resulting hash? I'd say to break it is equally difficult whether the secret is there or not. - section 9.2, I like that you put the command sequence that generates Base64(MD5(DER(OID))). However, claiming that you can run it on many unix-like systems seems quite strong to me. "oid" is not found on any system I tried, be it FreeBSD 6.1, Gentoo 1.12.11.1, or OpenSolaris. What's more, "xxd" is part of ViM. Not sure if those details should be part of the RFC but at least "oid" is quite generic name, I can't find what "oid -i" is supposed to do exactly; I just guess "-i" means an input file, not a specific type of output. wrt the SSH protocol I think it should work as defined but obviously a reference implementation might reveal more. cheers, J. -- Jan Pechanec From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 11 10:34:56 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421F728C1C1 for ; Tue, 11 Nov 2008 10:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.688 X-Spam-Level: X-Spam-Status: No, score=-8.688 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk5gRaPM27mX for ; Tue, 11 Nov 2008 10:34:52 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A4E0728C1CE for ; Tue, 11 Nov 2008 10:34:50 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3D0E163B12D; Tue, 11 Nov 2008 18:34:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 1DDCB63B101 for ; Tue, 11 Nov 2008 18:34:41 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA03924; Tue, 11 Nov 2008 13:34:38 -0500 (EST) From: der Mouse Message-Id: <200811111834.NAA03924@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: Tue, 11 Nov 2008 12:24:44 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer In-Reply-To: References: <7327DF90-C0CB-45E9-8606-64854CAD4431@stebila.ca> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > - section 4, this might be just a language issue; does this imply > that the remote key pair is ephemeral as well or not? Or would it be better > to say "and ephemeral remote public key"? > > The Elliptic Curve Diffie-Hellman (ECDH) key exchange method > generates a shared secret from an ephemeral elliptic curve local > private key and remote public key. Maybe "...from ephemeral elliptic curve local private and remote public keys"? > wrt the SSH protocol I think it should work as defined but obviously > a reference implementation might reveal more. I think reference implementations are a bad idea; I much prefer sample implementations. (The difference is that a reference implementation by definition _is_ the spec in an operational form, and if it disagrees with some other spec, there's no a priori way to tell which is wrong. If a sample implementation disagrees with the spec, there's no question - the sample implementation is wrong.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ 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 Nov 15 17:55:43 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780C83A67B6 for ; Sat, 15 Nov 2008 17:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVOj4QGOWesY for ; Sat, 15 Nov 2008 17:55:42 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8F2933A63EC for ; Sat, 15 Nov 2008 17:55:40 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id A37E163B1A4; Sun, 16 Nov 2008 01:55:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id 9E3D463B10D for ; Sun, 16 Nov 2008 01:55:31 +0000 (UTC) Received: from [192.168.3.10] (bas1-kitchener06-1167865389.dsl.bell.ca [69.156.54.45]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id mAG1tPxg005720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Nov 2008 20:55:29 -0500 (EST) Cc: ietf-ssh@NetBSD.org Message-Id: From: Douglas Stebila To: Jan Pechanec In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer Date: Sat, 15 Nov 2008 20:55:20 -0500 References: <7327DF90-C0CB-45E9-8606-64854CAD4431@stebila.ca> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Sat, 15 Nov 2008 20:55:29 -0500 (EST) X-Miltered: at mailchk-w02 with ID 491F7D8D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on localhost X-Virus-Status: Clean X-UUID: e39ca5dc-2cb5-4fe1-8854-a27e808e7f05 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Thanks for the comments, Jan. I've implemented all of the changes you suggested and am responding to your other questions below. A new draft will appear next week when the Internet Draft submission tool is back online. > - section 1, ECMQV has been dropped from the National Security > Agency's Suite B. I don't know when but it's not there now: > > http://www.nsa.gov/ia/industry/crypto_suite_b.cfm > > I'm wondering if an inclusion of that in this draft may not cast > some shadow on it in general as including something that might have > potential legal issues if used. While it's no longer part of NIST Suite B, it is a useful protocol that I am to understand a number of organizations wish to use. I have added language clarifying that the ECMQV portion is optional. > - section 5. I don't know very much about ECC so I have a question. > I understand that we can use implicit server authentication since > server's > private key is already involved in the generation of the shared > secret. So, > HMAC instead of the ECDSA is then used just because it's faster? That's right. > - is it needed to include shared secret in the hash input when we > already use it in HMAC on the resulting hash? I'd say to break it is > equally > difficult whether the secret is there or not. I suppose it's not strictly necessary in the context of HMAC. If the value H in that section is ever used for another purpose in the context of the SSH protocol, then it would be necessary to have it in there for authentication purposes. It doesn't hurt to keep it in, so that is my preference. > - section 9.2, I like that you put the command sequence that > generates Base64(MD5(DER(OID))). However, claiming that you can run > it on > many unix-like systems seems quite strong to me. "oid" is not found > on any > system I tried, be it FreeBSD 6.1, Gentoo 1.12.11.1, or OpenSolaris. > What's > more, "xxd" is part of ViM. Not sure if those details should be part > of the > RFC but at least "oid" is quite generic name, I can't find what "oid > -i" is > supposed to do exactly; I just guess "-i" means an input file, not a > specific type of output. I've clarified the language to be clear that these are not standard Unix commands but could be installed from the URLs given. Thanks, Douglas From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 17 08:30:21 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778DE28C1A5 for ; Mon, 17 Nov 2008 08:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEPqhLziuL1I for ; Mon, 17 Nov 2008 08:30:20 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8E12A28C19C for ; Mon, 17 Nov 2008 08:30:20 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id D04E763B108; Mon, 17 Nov 2008 16:30:00 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id AE0B563B101 for ; Mon, 17 Nov 2008 16:29:59 +0000 (UTC) Received: from [192.168.3.10] (bas1-kitchener06-1167865389.dsl.bell.ca [69.156.54.45]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id mAHGTsDv017122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Nov 2008 11:29:57 -0500 (EST) Message-Id: From: Douglas Stebila To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Fwd: New Version Notification for draft-green-secsh-ecc-04 Date: Mon, 17 Nov 2008 11:29:48 -0500 References: <20081117162907.5053C3A69C5@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Mon, 17 Nov 2008 11:29:57 -0500 (EST) X-Miltered: at minos with ID 49219C02.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on localhost X-Virus-Status: Clean X-UUID: cd157bb4-7c41-472e-9333-7d3bf92c1101 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Begin forwarded message: > From: IETF I-D Submission Tool > Date: November 17, 2008 11:29:07 AM GMT-05:00 > To: douglas@stebila.ca > Subject: New Version Notification for draft-green-secsh-ecc-04 > > > A new version of I-D, draft-green-secsh-ecc-04.txt has been > successfuly submitted by Douglas Stebila and posted to the IETF > repository. > > Filename: draft-green-secsh-ecc > Revision: 04 > Title: Elliptic-Curve Algorithm Integration in the Secure Shell > Transport Layer > Creation_date: 2008-11-15 > WG ID: Independent Submission > Number_of_pages: 25 > > 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. > > > > The IETF Secretariat. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 17 09:58:34 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A48B3A692E for ; Mon, 17 Nov 2008 09:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUMJnPXFz2+b for ; Mon, 17 Nov 2008 09:58:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 01F693A6831 for ; Mon, 17 Nov 2008 09:58:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8A15463B11F; Mon, 17 Nov 2008 17:58:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id E05F363B101 for ; Mon, 17 Nov 2008 17:58:20 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mAHGd95l020163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 18:39:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAHGd9AC022647; Mon, 17 Nov 2008 18:39:09 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18721.40493.335603.386542@fireball.kivinen.iki.fi> Date: Mon, 17 Nov 2008 18:39:09 +0200 From: Tero Kivinen To: draft-igoe-secsh-aes-gcm@tools.ietf.org CC: iesg@ietf.org, secdir@ietf.org, ietf-ssh@netbsd.org Subject: Review of draft-igoe-secsh-aes-gcm-00.txt X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes how to use combined mode aes-gcm ciphers in the secure shell. I think this document have several problems: 1) The draft does not define how the per encryption IV is defined. I assume it is some kind of counter with most likely initial value and fixed part taken from the appropriate IV generated by the secsh key derivation part, but also things like byte order of the counter etc needs to be defined. RFC 5116 provides just generic instructions for the nonce generation (generation of distinct nonces for each operation for given key) in section 3.1 and then provides recommended format for the nonce in section 3.2, and then there is another format for the nonce in section 3.2.1, but nothing in this document says which format is used. 2) This is first combined mode cipher for the secsh, so it should also provide information required to support combined mode ciphers in secsh. For example it should say that combined mode encryption is run only once and what key it is using (most likely the encryption key from section 7.2 from RFC 4253 etc). It also needs to say that mac generation DOES NOT follow section 6.4 of RFC 4253 (i.e. no MAC(key, sequence_number || unencrypted_packet)). 3) I am not sure if there is need adding sequence_number to the authenticated data of the combined mode. That sequence_number is added to the mac of the normal secsh modes, but as I think the aes-gcm mode will provide same protection by using the IV in a format of counter, but I am not sure if that is enough. At least it should be mentioned why it is not needed. 4) Section 7 says that it is "SHOULD" to use same aead-aes-*-gcm-ssh for both confidentiality and data integrity mechanism. That implies that it would be valid to use for example 3des as encryption algorithm and aead-aes-128-gcm-ssh as integrity algorithm. This causes few problems, as both of those algorithms require IV, thus the draft needs to defined how the Initial IV of the section 7.2 RFC 4253 needs to be splitted between 3des IV and aead-aes-128-gcm-ssh IV. Another example would be that if someone decides to use aead-aes-256-gcm-ssh as encryption algorithm and aead-aes-128-gcm-ssh for the integrity then the aes-gcm needs to be run twice, and now the key for the aead-aes-256-gcm-ssh is taken from encryption key and the key for the aead-aes-128-gcm-ssh is taken from the integrity key (and the separate IV for both needs to be taken from Initial IV field). I would suggest way mandate that same aead-aes-*-gcm-ssh algorithm MUST be selected for encryption and integrity algorithms (perhaps with only one exception when using none encryption and aead-aes-*-gcm-ssh as integrity algorithm). 5) Next question then if encryption and integrity algorithms happen to be same combined mode ciphers (in case we keep "SHOULD" in point 4, and allow mixing different combined mode ciphers for both encryption and integrity alrogithms), does that still mean that we need to run the aes-gcm twice with different IVs and keys (encryption key and integrity key)? My guess is that you do NOT want to run it twice, but you only want to run it once using the encryption key and one Initial IV and use output of that for both encryption and mac. 6) This should have reference to the RFC 4253, as that is the actual document using the algorithms, and this really actually modifies that documents at least from mac generation part. Also the question is that as this extends standard track document with informational document, that does not just define new ciphers, but also changes the base document, should this document be on the standard track also? In general I think this document requires still quite a lot of more text to describe how to use combined mode ciphers in the secsh. Bit like we needed to have much more description in the RFC 5282 when the AEAD modes where defined to be used in the IKEv2 SAs (I do not think secsh needs that much text as RFC5282 as secsh case is simplier, but it still needs something). -- kivinen@iki.fi From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 27 03:09:24 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B49328C173 for ; Thu, 27 Nov 2008 03:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1B7-8ARcmFr for ; Thu, 27 Nov 2008 03:09:23 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1EDE63A6BA2 for ; Thu, 27 Nov 2008 03:09:21 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3017563B13F; Thu, 27 Nov 2008 11:09:12 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from smtpsal.upv.es (marfik.cc.upv.es [158.42.249.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 9D7D363B128 for ; Thu, 27 Nov 2008 11:08:52 +0000 (UTC) Received: from pop.upv.es (deneb.cc.upv.es [158.42.3.51]) by smtpsal.upv.es (8.13.6/8.13.6) with ESMTP id mARA2UAC032683; Thu, 27 Nov 2008 11:02:30 +0100 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id mARA2TA04270;; Thu, 27 Nov 2008 11:02:29 +0100 (MET) Received: from [158.42.53.40] (nohara.disca.upv.es [158.42.53.40]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id mARA0owT005891; Thu, 27 Nov 2008 11:00:51 +0100 Message-ID: <492E6FCF.2090800@upv.es> Date: Thu, 27 Nov 2008 11:00:47 +0100 From: eaeeie09 User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: eaeeie09@upv.es Subject: call for papers EAEEIE09 Conference Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list (We apologize for multiples copies) (Please distribute) Dear colleagues: The 20th EAEEIE Annual Conference will take place in Valencia (22-24 June 2009), organized by the Technical University of Valencia. The objective of the Conference is to bring together lecturers, researchers and professionals in the field of Electrical and Information Engineering (EIE) all over Europe with the aim to exchange ideas and information and contribute to the development of EIE education. We cordially invite you to participate and submit your contribution to EAEEIE 2009, which includes (but is not limited to), the following topics: · Innovation in pedagogical way of teaching · Application of ICTs in Education · European Curricula in Electrical and Information Engineering · International Partnerships in Teaching · Cooperation with Industry in Teaching · Gender Issues, Women in Engineering · The Student Perspective of Electrical and Information Engineering · Virtual Learning Environments in Electrical and Information Engineering · Lifelong Learning in Electrical and Information Engineering A website is available at the next url: http://www.cfp.upv.es/EAEEIE09/ Best regards,