From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 7 02:55:45 2011 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0BE11E8083 for ; Tue, 7 Jun 2011 02:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.763 X-Spam-Level: * X-Spam-Status: No, score=1.763 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr1CKrVYPKGA for ; Tue, 7 Jun 2011 02:55:44 -0700 (PDT) Received: from mail.netbsd.org (ns.NetBSD.org [IPv6:2001:4f8:3:7::53]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75D11E807A for ; Tue, 7 Jun 2011 02:55:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0823014A145; Tue, 7 Jun 2011 09:55:36 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D018314A12E for ; Tue, 7 Jun 2011 09:55:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id DA-er7kk-daw for ; Tue, 7 Jun 2011 09:55:34 +0000 (UTC) Received: from secure19.cwsit.com (secure19.cwsit.com [198.66.140.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "secure19.securesites.net", Issuer "secure19.securesites.net" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 133D114A10F for ; Tue, 7 Jun 2011 09:55:33 +0000 (UTC) Received: from lime (d-69-161-109-70.cpe.metrocast.net [69.161.109.70]) (authenticated bits=0) by secure19.cwsit.com (8.14.4/8.13.6) with ESMTP id p578gALj097030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 7 Jun 2011 04:42:21 -0400 (EDT) From: "xoranon" To: Subject: Date: Tue, 7 Jun 2011 04:42:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hello, The ssh-keygen utility only makes 1024 bit keys and says that it is to comply with FIPS 186-2. I understand that NIST 800-57 recommends DSA keys larger than 1024. Could you point me to a dissucssion of this. Kindest regards, John From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 8 21:28:50 2011 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A380821F8525 for ; Wed, 8 Jun 2011 21:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpqupeUxOjoC for ; Wed, 8 Jun 2011 21:28:49 -0700 (PDT) Received: from mail.netbsd.org (ns.NetBSD.org [IPv6:2001:4f8:3:7::53]) by ietfa.amsl.com (Postfix) with ESMTP id D51E721F8524 for ; Wed, 8 Jun 2011 21:28:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 39AB514A1B1; Thu, 9 Jun 2011 04:28:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A15DB14A1B0 for ; Thu, 9 Jun 2011 04:28:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0a-eSxM49dR0 for ; Thu, 9 Jun 2011 04:28:38 +0000 (UTC) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "USERTrust Legacy Secure Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 6154F14A1AD for ; Thu, 9 Jun 2011 04:28:38 +0000 (UTC) Received: from [128.2.184.182] (JHUTZ-DYN5.PC.CS.CMU.EDU [128.2.184.182]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p592ppf9023824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jun 2011 22:51:51 -0400 (EDT) Subject: Re: [saag] draft-kwatsen-reverse-ssh-01 submission for review From: Jeffrey Hutzelman To: Kent Watsen Cc: jhutz@cmu.edu, "saag@ietf.org" , "ietf-ssh@NetBSD.org" In-Reply-To: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> References: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Jun 2011 22:51:51 -0400 Message-ID: <1307587911.7092.331.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 2011-06-08 at 16:43 -0700, Kent Watsen wrote: > I've updated the Reverse SSH draft per suggestions: > > - now uses IANA-assigned SSH port 22 > - now defines proper client and server roles (Reverse SSH client, Reverse SSH server) So, let's make sure I have this right. A device "calling home" is going to connect to some server on port 22, and expect the server to immediately pick up the role of being an SSH client? How is the server to distinguish between such a device and a normal ssh client being used by an admin who wants to log in to the server? Or by some other protocol that runs over ssh? I'm pretty sure I recall the discussion on this point involving some sort of negotiation, rather than a requirement that both sides know a priori which protocol variant they're going to speak. In fact, I seem to recall der Mouse suggesting use of a pre-kex extension packet to indicate this. > - definition of a new family of public host key algorithms (hmac-*) This is not the way to achieve what you're trying to do. Nor is specifying use of only particular host key algorithms, which rather badly breaks modularity. Further, what you've done doesn't actually buy anything. If the HMAC is precomputed before the device that will act as SSH server is deployed, then there is no operational advantage over X.509 certificates. On the other hand, if the HMAC is computed at the time of the connection, then both the client and server must know the key _and_ there must be a different key for each client/server pair (so one device cannot impersonate another). In which case, you may as well preshare per-device RSA keys instead of per-device HMAC keys. Except in cases like X.509 (where a host key is associated with a long-term signature by some trusted third party), SSH proves server identity and authenticates host keys as part of key exchange. If none of the already-defined KEX methods are suitable for your needs, then it might be possible to define a new one along the lines of what you've described. However, I seriously doubt its utility, for the reasons described above. It sounds to me like you really _don't_ want the device to be the SSH server at all; you only think you do. I suspect you really want the device to be the SSH _client_, except that once the connection is up, you want the server to open some sort of session to the client to execute commands, transfer files, run netconf or SNMP, or whatever. Interestingly, this role reversal -- allowing the SSH server to open sessions and run commands on the SSH client, requires no change to the SSH protocol at all. It simply requires that the client sit around waiting for a channel-open request from the server and accept it when it comes around. This is exactly the sort of situation in which it is appropriate to behave contrary to the SHOULD in RFC4254 section 6.1. FWIW, I'm fairly concerned about the hmac-* algorithms described in this document, which don't seem to provide any guarantee of freshness. I'm concerned that there is no description in this document as to how the SSH client is expected to authenticate itself to the device. This is fairly important, particularly since in the described deployment scenario, the device is likely about to give nearly unlimited power to the SSH client. Finally, I'm very concerned about the statements in the first paragraph of section 7, which assert that the proposed role reversal does not introduce any new security concerns. On the contrary, the proposed protocol is very nearly akin to calling someone up and saying "Give me your password", later followed by "by the way, I might be your bank". We've discussed "reverse SSH" ideas before*, and they haven't gained any traction. Part of the problem is that server and client authentication is not symmetric in the SSH protocol, and there is a basic assumption that a client knows a priori what server it intends to talk to, while the server does not know what client will be talking to it. Attempting to falsify this assumption and still have things work typically results in warping the protocol rather badly. I'm not saying a reverse SSH is not possible, and with a few more iterations this document might well become one. However, as mentioned above, I think it's probably not the right approach to solving the stated problem. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Jun 9 11:31:48 2011 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113B111E8203 for ; Thu, 9 Jun 2011 11:31:48 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBtVnIvBO7e2 for ; Thu, 9 Jun 2011 11:31:47 -0700 (PDT) Received: from mail.netbsd.org (ns.NetBSD.org [IPv6:2001:4f8:3:7::53]) by ietfa.amsl.com (Postfix) with ESMTP id 521D811E80F3 for ; Thu, 9 Jun 2011 11:31:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 18F0C14A1CA; Thu, 9 Jun 2011 18:31:43 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C169C14A1C8; Thu, 9 Jun 2011 18:31:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3F3E114A177 for ; Wed, 8 Jun 2011 23:44:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id E0MW79Xe1HC2 for ; Wed, 8 Jun 2011 23:44:25 +0000 (UTC) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) (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 418CA14A174 for ; Wed, 8 Jun 2011 23:44:24 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTfAJVyuVuRmo/lWt6RjQUgGyLfP9dh11@postini.com; Wed, 08 Jun 2011 16:44:25 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 8 Jun 2011 16:43:55 -0700 From: Kent Watsen To: "saag@ietf.org" , "ietf-ssh@NetBSD.org" Date: Wed, 8 Jun 2011 16:43:52 -0700 Subject: draft-kwatsen-reverse-ssh-01 submission for review Thread-Topic: draft-kwatsen-reverse-ssh-01 submission for review Thread-Index: AcwmNexl1MkTfarBS+uDUm42L3SQIQ== Message-ID: <84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I've updated the Reverse SSH draft per suggestions: - now uses IANA-assigned SSH port 22 - now defines proper client and server roles (Reverse SSH client, Rever= se SSH server) - now uses in-band negotiation to automatically authenticate the SSH Se= rver's host key=20 Key aspects used to achieve this update include: - contextual awareness to set SSH client/server roles - definition of a new family of public host key algorithms (hmac-*) My own thoughts: - I like how now the host key and MAC algorithm are negotiated for hmac= -* use - I'm glad to find a solution minimizing the impact to existing SSH imp= lementations Link: - http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-01 Thanks, Kent