From ayelkovich@mcsdga.net Sat Oct 9 14:47:45 2010 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 E6FF13A692E for ; Sat, 9 Oct 2010 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.269 X-Spam-Level: ** X-Spam-Status: No, score=2.269 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_FROMEML_NOTLD=2.268] 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 dI120BOLBZHQ for ; Sat, 9 Oct 2010 14:47:39 -0700 (PDT) Received: from MCSDSPAM02.muscogee.k12.ga.us (mcsdspam02.muscogee.k12.ga.us [96.38.231.248]) by core3.amsl.com (Postfix) with ESMTP id F30B93A68FB for ; Sat, 9 Oct 2010 14:47:38 -0700 (PDT) X-ASG-Debug-ID: 1286660858-3281b7610001-PhLuXZ Received: from mail.mcsdga.net ([172.16.2.6]) by MCSDSPAM02.muscogee.k12.ga.us with ESMTP id BkKkoqUxvQ3CuHkA; Sat, 09 Oct 2010 17:47:38 -0400 (EDT) X-Barracuda-Envelope-From: ayelkovich@mcsdga.net X-ASG-Whitelist: Client Received: from localhost (172.16.2.6 [172.16.2.6]) by mail.mcsdga.net (MCSD Mail) with SMTP id RFE60737; Sat, 09 Oct 2010 17:47:37 -0400 Date: Sat, 09 Oct 2010 17:47:37 -0400 From: Reply-To: Subject: Upgrade Your Email Account Message-ID: <59e2c999718ade08c8ce531086d7ba75@mcsdga.net> X-ASG-Orig-Subj: Upgrade Your Email Account X-Mailer: IceWarp Web Mail 5.6.7 X-Originating-IP: 115.242.252.247 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Barracuda-Connect: UNKNOWN[172.16.2.6] X-Barracuda-Start-Time: 1286660858 X-Barracuda-URL: http://172.16.2.67:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at muscogee.k12.ga.us To: undisclosed-recipients:; You have reached the limit of your email quota. You will not be able to send or receive new mail until you boost your mailbox size. Click the below link and fill the form to upgrade your account. http://use.my/%20system-helpdesk5/ Technical Support 192.168.0.1 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 11 07:03:30 2010 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 78E113A6A69 for ; Mon, 11 Oct 2010 07:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 qJS-UbWjZtH6 for ; Mon, 11 Oct 2010 07:03:30 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id F12303A6A29 for ; Mon, 11 Oct 2010 07:03:26 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 28BA371798 for ; Mon, 11 Oct 2010 14:04:38 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 2E1FC63B100; Mon, 11 Oct 2010 14:04:24 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) (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 852D063B101 for ; Mon, 11 Oct 2010 14:04:21 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o9BE49en019826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 10:04:16 -0400 (EDT) Date: Mon, 11 Oct 2010 10:04:09 -0400 From: Jeffrey Hutzelman To: turners@ieca.com cc: jhutz@cmu.edu, draft-igoe-secsh-x509v3.all@tools.ietf.org, ietf-ssh@netbsd.org, iesg-secretary@ietf.org Subject: draft-igoe-secsh-x509v3-06.txt Message-ID: <143AAAED7B6A687505B926A1@atlantis.pc.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a request for the IESG to approve publication of "X.509v3 Certificates for Secure Shell Authentication", draft-igoe-secsh-x509v3-06.txt, as a Proposed Standard. This document is an individual submission to the IESG. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for this document is Jeffrey Hutzelman, . I have reviewed this document, and I believe it is ready for IETF-wide review and publication as a Proposed Standard. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? While the SECSH working group concluded in 2006, its mailing list remains an active forum for SSH implementation developers and other interested parties. This draft has been discussed in that forum and has evolved as a part of that discussion. I am satisfied that it has received sufficient review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I don't believe any particular additional review is needed. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns or issues with this document. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There seems to be a solid consensus among those who have been active in the discussions of this document. There has long been interest in the SSH community in supporting X.509 certificates within the SSH protocol; in fact, such work was being pursued in the SECSH working group prior to its conclusion (see draft-ietf-secsh-x509-03.txt). While not everyone active on the mailing list has participated in discussions of the present document, there seems to be a solid consensus to move forward among those who have. Participants who have been active in this discussion include several SSH implementors and one of the co-authors of the previously mentioned document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) I am not aware of any such threats or indications of discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? This document satisfies the idnits tool and all of the requirements called out in ID-Checklist.html. No additional formal review criteria apply. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References in this document are appropriately split. There is a downward reference to RFC3447, an Informational document which is a republication of PKCS#1 v2.1. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section is correct and consistent with the body of the document. This document registers three SSH public key algorithm names and one family of SSH public key algorith names; it does not create any new registries. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document contains no sections written in formal machine-readable languages. It does define protocol messages in the form traditionally used for the SSH protocol and its extensions, including use of data types taken from section 5 of RFC4251; these are used correctly. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. Working Group Summary When the Secure Shell working group concluded in 2006, active work on defining use of X.509 certificates in the SSH protocol was left uncompleted. However, there was and continues to be community interest in extending the SSH protocol to provide this functionality. Further, although the working group concluded, its mailing list remains active as a forum for discussion among SSH protocol implementors and other interested parties. This document was discussed extensively on that list, and seems to represent the consensus of participants in that discussion. Document Quality A number of SSH implementors have been active in reviewing and discussing this extension. While no one has explicitly said whether they intend to implement, it seems likely that several will do so. From accountupgrade@email.net Mon Oct 11 17:53:04 2010 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 6223E3A688A for ; Mon, 11 Oct 2010 17:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.026 X-Spam-Level: ** X-Spam-Status: No, score=2.026 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_TW=1.335, SARE_RECV_IP_140117=0.69] 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 AoI2g0E3U27O for ; Mon, 11 Oct 2010 17:53:02 -0700 (PDT) Received: from staff.mail.fju.edu.tw (staff.mail.fju.edu.tw [140.136.247.38]) by core3.amsl.com (Postfix) with ESMTP id 375453A6863 for ; Mon, 11 Oct 2010 17:53:00 -0700 (PDT) Received: (from staff.mail.fju.edu.tw [216.218.211.51]) by staff.mail.fju.edu.tw (MOS 3.10.7-GA) with HTTP/1.0 id BYP06535 (AUTH fj00017); Tue, 12 Oct 2010 08:51:22 +0800 (CST) From: Email Support Team Subject: Dear E-mail User Reply-To: accountupgradeservice@info.al X-Mailer: Mirapoint Webmail Direct 3.10.7-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20101012085122.BYP06535@staff.mail.fju.edu.tw> Date: Tue, 12 Oct 2010 08:51:22 +0800 (CST) To: undisclosed-recipients:; Dear E-mail User Please note that we are upgrading our webmail account plus two months free subscription service To complete your Account Verification process, you are to reply this message and enter your Username and Password respectively in the space provided below this email.You are required to do this before the next 48hrs of receipt of this e-mail or else your email will be erase and delete from our data base. Username ( ) Password ( ) Help Support Team From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 11:19:00 2010 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 41F1E3A68EC for ; Tue, 26 Oct 2010 11:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.851 X-Spam-Level: X-Spam-Status: No, score=-6.851 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 rI46mthXEdvK for ; Tue, 26 Oct 2010 11:18:59 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 11E403A6877 for ; Tue, 26 Oct 2010 11:18:59 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 537997177C for ; Tue, 26 Oct 2010 18:20:46 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id DA82F63B100; Tue, 26 Oct 2010 18:20:30 +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 317C463B102 for ; Tue, 26 Oct 2010 18:20:28 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA20000; Tue, 26 Oct 2010 14:20:27 -0400 (EDT) Date: Tue, 26 Oct 2010 14:20:27 -0400 (EDT) From: der Mouse Message-Id: <201010261820.OAA20000@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. X-Composition-Start-Date: Tue, 26 Oct 2010 13:59:31 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: "too many auth failures"? Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I recently ran into some ssh behaviour that strikes me as broken and thought I'd see what the list thought. This is a semi-embedded commercial implementation; I'm not naming the vendor here because this hasn't been reported to them yet, so it's hardly fair to do anything even vaguely like name-&-shame now. The symptom was that ssh to the device worked fine once, but when I tried later, form a slightly different environment, I would consistently get a "protocol error" failure. Upon turning on cleartext packet tracing, it turned out that my client offered six public keys (four in the agent and two from files), none of which were accepted. When my client then tried to go keyboard-interactive in response to the sixth key failure, the remote end sent an SSH_MSG_DISCONNECT with reason code 2, SSH_DISCONNECT_PROTOCOL_ERROR, and a description string saying there had been too many authentication failures for that user. Disabling publickey auth in the client (which the client I was using can do on the command line) got me a password prompt and I was able to log in normally (thus indicating this did not mean "too many failures, account locked"). The first attempts, the ones which worked without any fuss, came from a different login, one which had only one key in the agent and two in files. This strikes me as wrong in two respects: (1) it's (apparently) counting each failed public key as a separate "authentication" (okay, three respects; that should be "authorization") failure, and (2) it's claiming a protocol error for an error condition which is not in fact a protocol error. It seems to me that it either should use a better disconnet code (SERVICE_NOT_AVAILABLE, maybe?), or it should fail in a userauth way - perhaps SSH_MSG_USERAUTH_FAILURE with an empty list of authentication methods. (Hm, that's a botch in the RFCs I missed when we were hammering them out; the "Authentication Protocol" is actually more of an authorization protocol than an authentication protocol.) So, thoughts? Am I missing something, or is this really as ill-behaved as I think? /~\ 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 Tue Oct 26 11:36:08 2010 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 0CA0E3A6927 for ; Tue, 26 Oct 2010 11:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 K4Ok-O+I6OwT for ; Tue, 26 Oct 2010 11:36:04 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id BDBD13A6928 for ; Tue, 26 Oct 2010 11:35:43 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 0CF5971799 for ; Tue, 26 Oct 2010 18:37:24 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 2B28963B101; Tue, 26 Oct 2010 18:37:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id E6A9563B100 for ; Tue, 26 Oct 2010 18:37:07 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9QIawqR000735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Oct 2010 18:37:00 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9QHf0v5013467; Tue, 26 Oct 2010 18:36:57 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 724991651288118117; Tue, 26 Oct 2010 11:35:17 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Oct 2010 11:35:16 -0700 Date: Tue, 26 Oct 2010 13:35:12 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? Message-ID: <20101026183511.GS6536@oracle.com> References: <201010261820.OAA20000@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010261820.OAA20000@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Oct 26, 2010 at 02:20:27PM -0400, der Mouse wrote: > I recently ran into some ssh behaviour that strikes me as broken and > thought I'd see what the list thought. Yes, I've seen this a lot. Some implementations treat all userauth method failures as contributing equally to a max-failures counter. This is really, really wrong. Only "password" and "keyboard-interactive" failures should count for the traditional max-failures counter, with a separate counter for GSS, pubkey, and hostbased userauth. What's really galling is that "none" failures also count -- there's too many clients that start by attempting "none" userauth. And, of course, clients try the non-interactive/ password methods first, as you'd expect. So you might have 1 "none" failure, 2 "hostbased" failures (if the client has DSS and RSA keys), N "publickey" failures, and never get to "keyboard-interactive" nor "password" userauth. If the server has a 6 failures max counter your client will get disconnected when it tries the third publickey that is rejected. Whenever I run into such a server I have to resort to enabling only the userauth method I expect to see succeed. I hate having to do that. I also hate the fact that keyex is not re-tryiable. I'm all for publishing an RFC saying "don't do such stupid things". Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 19:03:48 2010 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 DE1943A68F1 for ; Tue, 26 Oct 2010 19:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.937 X-Spam-Level: X-Spam-Status: No, score=-4.937 tagged_above=-999 required=5 tests=[AWL=1.662, 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 bQKi5E+-zPqY for ; Tue, 26 Oct 2010 19:03:47 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 762463A6825 for ; Tue, 26 Oct 2010 19:03:47 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 47C96717A8 for ; Wed, 27 Oct 2010 02:05:35 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id BD3ED63B100; Wed, 27 Oct 2010 02:05:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.auckland.ac.nz", Issuer "AusCERT Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 197BD63B101 for ; Wed, 27 Oct 2010 02:05:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1288145118; x=1319681118; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ietf-ssh@netbsd.org,=20mouse@Rodents-Montreal.ORG |Subject:=20Re:=20"too=20many=20auth=20failures"? |In-Reply-To:=20<201010261820.OAA20000@Sparkle.Rodents-Mo ntreal.ORG>|Message-Id:=20|Date:=20Wed,=2027=20Oct=202010=2015:05:07 =20+1300; bh=4wP5r1hIOLWw8zCFycQkN/3OW9APPPhK4RXjMbP1zgw=; b=RvNQgxg06Uv5LsAjXxVp5GWM1eOiwxtXFCRfZUQuVJdYi1n6fE3dtIH8 nnELXRbsOiAxiQYfGGsAPn56pTbBvoEbI2C6bMrJ/Gela9eCtuQBddtgM 8Z/FpIzepuf9jmVMx1I6O5yrqhgqKpNrG64Xy9AsKvt/4jxwF6RlEZuoL I=; X-IronPort-AV: E=Sophos;i="4.58,244,1286103600"; d="scan'208";a="32989244" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Oct 2010 15:05:08 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PAvNz-0005gX-IO; Wed, 27 Oct 2010 15:05:07 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PAvNz-0001Ib-L4; Wed, 27 Oct 2010 15:05:07 +1300 From: Peter Gutmann To: ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? In-Reply-To: <201010261820.OAA20000@Sparkle.Rodents-Montreal.ORG> Message-Id: Date: Wed, 27 Oct 2010 15:05:07 +1300 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list der Mouse writes: >So, thoughts? Am I missing something, or is this really as ill-behaved as I >think? I don't think it is. If you've set the server up to allow three tries at auth then you get three tries (I'm assuming it's set up to allow six here, which is a bit non-traditional, I would have expected three). Stepping back a bit, why are you sending *six* keys to the server? Shouldn't the client know which key it's supposed to use? It seems more like the client is broken than the server. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 20:35:20 2010 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 536BD3A68A8 for ; Tue, 26 Oct 2010 20:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.96 X-Spam-Level: X-Spam-Status: No, score=-4.96 tagged_above=-999 required=5 tests=[AWL=1.639, 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 SumS0MZvgoLl for ; Tue, 26 Oct 2010 20:35:01 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id B03DF3A6958 for ; Tue, 26 Oct 2010 20:35:00 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id EF0A3717CC for ; Wed, 27 Oct 2010 03:36:48 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 4ACFA63B101; Wed, 27 Oct 2010 03:36:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.auckland.ac.nz", Issuer "AusCERT Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 9D37E63B100 for ; Wed, 27 Oct 2010 03:36:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1288150594; x=1319686594; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mouse@Rodents-Montreal.ORG,=20Nicolas.Williams@ora cle.com|Subject:=20Re:=20"too=20many=20auth=20failures"? |Cc:=20ietf-ssh@netbsd.org|In-Reply-To:=20<20101026183511 .GS6536@oracle.com>|Message-Id:=20|Date:=20Wed,=2027=20Oct=202010=20 15:06:35=20+1300; bh=uW4wQwUoazkoz2qUUZvvSHrRJlThzsoNHF2Pw0LafME=; b=T6XPHwANALYLwuFfS7AacRb0eO5YBb4jS7h+iGNB33OyHaudcHFHkgQh HUl71mDfcu6b6z3PoiQ32rou79pMoXrx/3iaKs8YQ6gth7kTyRcAByenB glmac2T5wgNQcm2YMU5WsbqC/skcnIY39ZezjjXz2hXTXolxZv9asdSQm 0=; X-IronPort-AV: E=Sophos;i="4.58,244,1286103600"; d="scan'208";a="32989440" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Oct 2010 15:06:35 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PAvPP-0005k5-GL; Wed, 27 Oct 2010 15:06:35 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PAvPP-0001Iy-0P; Wed, 27 Oct 2010 15:06:35 +1300 From: Peter Gutmann To: mouse@Rodents-Montreal.ORG, Nicolas.Williams@oracle.com Subject: Re: "too many auth failures"? Cc: ietf-ssh@netbsd.org In-Reply-To: <20101026183511.GS6536@oracle.com> Message-Id: Date: Wed, 27 Oct 2010 15:06:35 +1300 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Nicolas Williams writes: >I also hate the fact that keyex is not re-tryiable. Wouldn't that defeat having a retry counter? Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 22:20:56 2010 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 593803A67F6 for ; Tue, 26 Oct 2010 22:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 VC6Bh3HJaMjB for ; Tue, 26 Oct 2010 22:20:52 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 8F3903A6875 for ; Tue, 26 Oct 2010 22:20:50 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id E309F717BB for ; Wed, 27 Oct 2010 05:22:38 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 5ACE663B102; Wed, 27 Oct 2010 05:22:24 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 0AD0463B101 for ; Wed, 27 Oct 2010 05:22:22 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9R5MGJe020258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 05:22:18 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9R3lkNo002682; Wed, 27 Oct 2010 05:22:15 GMT Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 726208421288156873; Tue, 26 Oct 2010 22:21:13 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Oct 2010 22:21:13 -0700 Date: Wed, 27 Oct 2010 00:21:08 -0500 From: Nicolas Williams To: Peter Gutmann Cc: mouse@Rodents-Montreal.ORG, ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? Message-ID: <20101027052108.GV6536@oracle.com> References: <20101026183511.GS6536@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 03:06:35PM +1300, Peter Gutmann wrote: > Nicolas Williams writes: > > >I also hate the fact that keyex is not re-tryiable. > > Wouldn't that defeat having a retry counter? The two issues are unrelated. The SSHv2 initial key exchange cannot be retried if it fails. It can only really fail if you use the SSHv2 w/ GSS-API keyex, and it does happen, often because of Kerberos configuration issues. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 22:22:51 2010 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 BC0493A6875 for ; Tue, 26 Oct 2010 22:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 O+J78fQgQF1M for ; Tue, 26 Oct 2010 22:22:48 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 029573A67F6 for ; Tue, 26 Oct 2010 22:22:48 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 54B93717DE for ; Wed, 27 Oct 2010 05:24:36 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 3EBA763B101; Wed, 27 Oct 2010 05:24:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id CA83063B100 for ; Wed, 27 Oct 2010 05:24:21 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9R5OHbV023689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 05:24:18 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9R1uWjj021387; Wed, 27 Oct 2010 05:24:17 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 726211251288156989; Tue, 26 Oct 2010 22:23:09 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Oct 2010 22:23:08 -0700 Date: Wed, 27 Oct 2010 00:23:04 -0500 From: Nicolas Williams To: Peter Gutmann Cc: ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? Message-ID: <20101027052304.GW6536@oracle.com> References: <201010261820.OAA20000@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 03:05:07PM +1300, Peter Gutmann wrote: > der Mouse writes: > > >So, thoughts? Am I missing something, or is this really as ill-behaved as I > >think? > > I don't think it is. If you've set the server up to allow three tries at auth > then you get three tries (I'm assuming it's set up to allow six here, which is > a bit non-traditional, I would have expected three). Stepping back a bit, why > are you sending *six* keys to the server? Shouldn't the client know which key > it's supposed to use? It seems more like the client is broken than the > server. My view is that servers should have two failure counters: one for password and keyboard-interactive, another one for all others. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 22:38:50 2010 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 D6A143A6875 for ; Tue, 26 Oct 2010 22:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.981 X-Spam-Level: X-Spam-Status: No, score=-4.981 tagged_above=-999 required=5 tests=[AWL=1.618, 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 jj4l59tmVpU3 for ; Tue, 26 Oct 2010 22:38:45 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 1F0D33A67E3 for ; Tue, 26 Oct 2010 22:38:45 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id C8688717BC for ; Wed, 27 Oct 2010 05:40:33 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 6FF3863B101; Wed, 27 Oct 2010 05:40:17 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.auckland.ac.nz", Issuer "AusCERT Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id AFB1D63B100 for ; Wed, 27 Oct 2010 05:40:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1288158016; x=1319694016; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20Nicolas.Williams@oracle.com,=20pgut001@cs.auckland .ac.nz|Subject:=20Re:=20"too=20many=20auth=20failures"? |Cc:=20ietf-ssh@netbsd.org,=20mouse@Rodents-Montreal.ORG |In-Reply-To:=20<20101027052304.GW6536@oracle.com> |Message-Id:=20|Date:=20Wed,=2027=20Oct=202010=2018:40:09=20+1300; bh=WhX3KdxyergwmzTFY0qNVTaSN6eyYkIYeGLvA4eDfPY=; b=n2L9rb3QpmRmsT3IuV/ZijK+OOfRHE7Hckb5Wq7tN6c2ypyT94ZL6Txg xEHzXAAfid6lyTeimZ5xdSzzcTJXevQN4GTWg04KAjydc/X1VLrVd2Eit LT8CAfb2rjdXMcJSB1uHgi8wahbAKs3eLWw3lt2ihWLlNQIFu0fbjDAG7 c=; X-IronPort-AV: E=Sophos;i="4.58,244,1286103600"; d="scan'208";a="33023858" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Oct 2010 18:40:10 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PAyk5-00051t-JG; Wed, 27 Oct 2010 18:40:09 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PAyk5-00082r-Ty; Wed, 27 Oct 2010 18:40:09 +1300 From: Peter Gutmann To: Nicolas.Williams@oracle.com, pgut001@cs.auckland.ac.nz Subject: Re: "too many auth failures"? Cc: ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG In-Reply-To: <20101027052304.GW6536@oracle.com> Message-Id: Date: Wed, 27 Oct 2010 18:40:09 +1300 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Nicolas Williams writes: >My view is that servers should have two failure counters: one for password >and keyboard-interactive, another one for all others. Yeah, I'd thought about that too, but where do you stop? Which counter type would a ZKP use? Or EKE? Or IBE? (I still think the real problem isn't the server but the client, how's it managing to try six different keys to get to one server?). Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 22:54:54 2010 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 C4BD63A69A4 for ; Tue, 26 Oct 2010 22:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 EeX+hwf7wdGz for ; Tue, 26 Oct 2010 22:54:41 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 6372C3A698C for ; Tue, 26 Oct 2010 22:54:40 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 210C0717B4 for ; Wed, 27 Oct 2010 05:56:22 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id D00A463B101; Wed, 27 Oct 2010 05:56:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 9778C63B100 for ; Wed, 27 Oct 2010 05:56:05 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9R5twIS031790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 05:55:59 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9R0lTdJ001140; Wed, 27 Oct 2010 05:55:57 GMT Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 720794531288158857; Tue, 26 Oct 2010 22:54:17 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Oct 2010 22:54:16 -0700 Date: Wed, 27 Oct 2010 00:54:12 -0500 From: Nicolas Williams To: Peter Gutmann Cc: ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? Message-ID: <20101027055411.GZ6536@oracle.com> References: <20101027052304.GW6536@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 06:40:09PM +1300, Peter Gutmann wrote: > Nicolas Williams writes: > > >My view is that servers should have two failure counters: one for password > >and keyboard-interactive, another one for all others. > > Yeah, I'd thought about that too, but where do you stop? Which counter type > would a ZKP use? Or EKE? Or IBE? The distinction relates to password guessing. ZKP -> same retry counter as password and keyboard-interactive; same for EKE. IBE (ID based encryption?) is not like a password-based method at all. Methods that might result in MITMs getting material suitable for off-line dictionary attacks are not special here as no counter on the server side can help prevent such MITM attacks, but because such methods are subject to password guessing, they should be subject to the same counter as password and keyboard-interactive. > (I still think the real problem isn't the server but the client, how's it > managing to try six different keys to get to one server?). Why not? SSH user public keys are effectively pseudonyms, so you can see why users might have many of them. Nothing wrong with that... On the server side you don't want a client sucking up resources testing whether some pubkey or another might work... so the server says all might work and the client has to actually sign with those keys, and the server also has to implement resource controls pre-authentication (including a timer to disconnect if the client takes too long to authenticate). Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 26 23:41:59 2010 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 33B423A6879 for ; Tue, 26 Oct 2010 23:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=1.597, 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 lBAyjgMgKmgX for ; Tue, 26 Oct 2010 23:41:57 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 05FBE3A67D1 for ; Tue, 26 Oct 2010 23:41:57 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 908F5717A0 for ; Wed, 27 Oct 2010 06:43:45 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 4456C63B101; Wed, 27 Oct 2010 06:43:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.auckland.ac.nz", Issuer "AusCERT Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 9E9E263B100 for ; Wed, 27 Oct 2010 06:43:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1288161811; x=1319697811; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20Nicolas.Williams@oracle.com,=20simon@josefsson.org |Subject:=20Re:=20"too=20many=20auth=20failures"?|Cc:=20i etf-ssh@netbsd.org,=20mouse@Rodents-Montreal.ORG,=0D=0A =20=20=20=20pgut001@cs.auckland.ac.nz|In-Reply-To:=20<87z ku02lyg.fsf@latte.josefsson.org>|Message-Id:=20|Date:=20Wed,=2027=20 Oct=202010=2019:43:18=20+1300; bh=HWBiuBPq7Mz3faBSCQQgAB3zKK4naZupoXtu0ZJ7vOY=; b=ODf9ah+Df+gcucrBoklY7AMs67v/0TqH9Tuvy3Fw3JS4Y5zVBC28lpSl KzdbDQN0gl/HjQsgHDJeJnIkA5AOvats5c8jgKw4f4UCKyNNtw3Ipvb/p IAO5okcgXx0n5bdOq0AOaIZ/4fgLhUW3zwxILALU4g73y18yX75AFqVox U=; X-IronPort-AV: E=Sophos;i="4.58,245,1286103600"; d="scan'208";a="33027425" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Oct 2010 19:43:19 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PAzjC-0006tO-JI; Wed, 27 Oct 2010 19:43:18 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PAzjC-0001Ql-UH; Wed, 27 Oct 2010 19:43:18 +1300 From: Peter Gutmann To: Nicolas.Williams@oracle.com, simon@josefsson.org Subject: Re: "too many auth failures"? Cc: ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG, pgut001@cs.auckland.ac.nz In-Reply-To: <87zku02lyg.fsf@latte.josefsson.org> Message-Id: Date: Wed, 27 Oct 2010 19:43:18 +1300 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Josefsson writes: >Isn't this another problem? Often private keys are protected by a password >or requires a PIN to unlock a smartcard, and iterating to sign with all keys >becomes a user interface issue quickly. This is how libssh2 works, and I >couldn't think of any way to avoid it. That's been a major issue for S/MIME deployments in the past, as soon as you enable message signing/encryption you get bombarded with requests to insert smart cards, enter PINs and passwords, and generally end up being a crypto bookkeeper for your mail app. The usual solution is to use S/MIME gateways, where the organisational mail gateway holds your key and signs/decrypts on your behalf, more or less defeating the point of personal message security since now you're just doing a STARTTLS for SMTP-equivalent in a really awkward way. (The lesson there is that the app should do all it can to minimise the load on the user, otherwise security gets sacrificed in exchange for functionality). Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 00:36:51 2010 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 0852A3A68D2 for ; Wed, 27 Oct 2010 00:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.644 X-Spam-Level: X-Spam-Status: No, score=-104.644 tagged_above=-999 required=5 tests=[AWL=1.955, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 UguG1SDhaIhs for ; Wed, 27 Oct 2010 00:36:49 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id A52B83A6830 for ; Wed, 27 Oct 2010 00:36:49 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 243DC717E4 for ; Wed, 27 Oct 2010 07:38:38 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 279C363B101; Wed, 27 Oct 2010 07:38:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "yxa-v.extundo.com", Issuer "CAcert Class 3 Root" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 4C88963B100 for ; Wed, 27 Oct 2010 07:38:21 +0000 (UTC) Received: from latte.josefsson.org (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9R6NILe032228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Oct 2010 08:23:20 +0200 From: Simon Josefsson To: Nicolas Williams Cc: Peter Gutmann , ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101027:pgut001@cs.auckland.ac.nz::f+eruIIqh/naqz5E:1EIH X-Hashcash: 1:22:101027:ietf-ssh@netbsd.org::wDQ7+YkKD72NaoLZ:6Hi+ X-Hashcash: 1:22:101027:mouse@rodents-montreal.org::MKEDbhUpw+e+dB39:9zb4 X-Hashcash: 1:22:101027:nicolas.williams@oracle.com::4GFjZmCM+dlj6VA+:ArZ1 Date: Wed, 27 Oct 2010 08:23:19 +0200 In-Reply-To: <20101027055411.GZ6536@oracle.com> (Nicolas Williams's message of "Wed, 27 Oct 2010 00:54:12 -0500") Message-ID: <87zku02lyg.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Nicolas Williams writes: >> (I still think the real problem isn't the server but the client, how's it >> managing to try six different keys to get to one server?). > > Why not? SSH user public keys are effectively pseudonyms, so you can > see why users might have many of them. Nothing wrong with that... On > the server side you don't want a client sucking up resources testing > whether some pubkey or another might work... so the server says all > might work and the client has to actually sign with those keys, and the > server also has to implement resource controls pre-authentication > (including a timer to disconnect if the client takes too long to > authenticate). Isn't this another problem? Often private keys are protected by a password or requires a PIN to unlock a smartcard, and iterating to sign with all keys becomes a user interface issue quickly. This is how libssh2 works, and I couldn't think of any way to avoid it. /Simon From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 07:11:44 2010 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 0307A3A6A39 for ; Wed, 27 Oct 2010 07:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[AWL=-0.243, 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 WAFz8Fx01l47 for ; Wed, 27 Oct 2010 07:11:42 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id CB7963A6AA9 for ; Wed, 27 Oct 2010 06:57:14 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id C6FD071802 for ; Wed, 27 Oct 2010 13:59:03 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id E2F8063B101; Wed, 27 Oct 2010 13:58:48 +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 4A69763B100 for ; Wed, 27 Oct 2010 13:58:46 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA00108; Wed, 27 Oct 2010 09:58:46 -0400 (EDT) Date: Wed, 27 Oct 2010 09:58:46 -0400 (EDT) From: der Mouse Message-Id: <201010271358.JAA00108@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. X-Composition-Start-Date: Wed, 27 Oct 2010 09:43:31 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> So, thoughts? Am I missing something, or is this really as >> ill-behaved as I think? > I don't think it is. If you've set the server up to allow three > tries at auth then you get three tries (I'm assuming it's set up to > allow six here, which is a bit non-traditional, I would have expected > three). I didn't set it up; this is, as far as I know, out-of-the-box vendor defaults for the system in question. > Stepping back a bit, why are you sending *six* keys to the server? > Shouldn't the client know which key it's supposed to use? How should it know that? It's got four keys in the agent; when they're exhausted, it tries the two it finds in files. I could have configured it differently, but, since I didn't give it any particular configuration, it has no reason to think any key is more likely to work than any other. As for retries, I conjecture that the retry limit is something more normal like three or five, but, while the implementation counts publickey failures (or, more precisely, keys offered which the server finds unacceptable) against the limit, it doesn't actually *test* the limit until the client tries to use keyboard-interactive. But that's just conjecture. /~\ 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 Wed Oct 27 07:14:04 2010 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 50FF63A6A26 for ; Wed, 27 Oct 2010 07:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.834 X-Spam-Level: X-Spam-Status: No, score=-6.834 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 3WwKkDYjGNH0 for ; Wed, 27 Oct 2010 07:14:03 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 5AE103A6A55 for ; Wed, 27 Oct 2010 07:13:40 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id DBB5471802 for ; Wed, 27 Oct 2010 14:15:29 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id C0A3563B101; Wed, 27 Oct 2010 14:15:15 +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 01C2863B100 for ; Wed, 27 Oct 2010 14:15:12 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA00237; Wed, 27 Oct 2010 10:15:12 -0400 (EDT) Date: Wed, 27 Oct 2010 10:15:12 -0400 (EDT) From: der Mouse Message-Id: <201010271415.KAA00237@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. X-Composition-Start-Date: Wed, 27 Oct 2010 10:12:02 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> My view is that servers should have two failure counters: one for >> password and keyboard-interactive, another one for all others. > Yeah, I'd thought about that too, but where do you stop? Which > counter type would a ZKP use? Or EKE? Or IBE? The "all others". Think about the point of those failure counters: they're designed to slow down password-guessing attacks. publickey, ZKP, etc, don't have anything like password-guessing risks, so it's arguably inappropriate to do failure counters for them. /~\ 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 Wed Oct 27 07:33:05 2010 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 E579D3A6784 for ; Wed, 27 Oct 2010 07:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.826 X-Spam-Level: X-Spam-Status: No, score=-6.826 tagged_above=-999 required=5 tests=[AWL=-0.227, 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 nhhlznizBIxx for ; Wed, 27 Oct 2010 07:33:03 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 4C3883A6A2F for ; Wed, 27 Oct 2010 07:33:02 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id B2ABE717A0 for ; Wed, 27 Oct 2010 14:34:51 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id E860A63B101; Wed, 27 Oct 2010 14:34:37 +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 506A763B100 for ; Wed, 27 Oct 2010 14:34:36 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA00321; Wed, 27 Oct 2010 10:34:35 -0400 (EDT) Date: Wed, 27 Oct 2010 10:34:35 -0400 (EDT) From: der Mouse Message-Id: <201010271434.KAA00321@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. X-Composition-Start-Date: Wed, 27 Oct 2010 10:15:46 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? In-Reply-To: <20101027055411.GZ6536@oracle.com> References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> [trying six publickey keys] > On the server side you don't want a client sucking up resources > testing whether some pubkey or another might work... That's actually a relatively cheap operation on most servers, and ssh specifically supports it: see the first form of SSH_MSG_USERAUTH_REQUEST (RFC4252, section 7). > so the server says all might work and the client has to actually sign > with those keys, This was not the behaviour I saw. My packet traces show the server refusing the keys without asking the client to perform PK operations, and my agent has an interface that, among other things, prints something every time it actually performs a publickey operation, which didn't show anything during my failed login attempts. > and the server also has to implement resource controls > pre-authentication (including a timer to disconnect if the client > takes too long to authenticate). The delay from my attempting the login to my getting the failure was less than any reasonable timeout - less than the time it would take for me to type a password I didn't know by heart, certainly. /~\ 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 Wed Oct 27 07:34:48 2010 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 A33CD3A6A2F for ; Wed, 27 Oct 2010 07:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.818 X-Spam-Level: X-Spam-Status: No, score=-6.818 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 L1nm-SohsaMk for ; Wed, 27 Oct 2010 07:34:45 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id E81823A6925 for ; Wed, 27 Oct 2010 07:34:44 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 18134717D1 for ; Wed, 27 Oct 2010 14:36:34 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 048EE63B101; Wed, 27 Oct 2010 14:36:21 +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 A165C63B100 for ; Wed, 27 Oct 2010 14:36:19 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA00339; Wed, 27 Oct 2010 10:36:18 -0400 (EDT) Date: Wed, 27 Oct 2010 10:36:18 -0400 (EDT) From: der Mouse Message-Id: <201010271436.KAA00339@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. X-Composition-Start-Date: Wed, 27 Oct 2010 10:34:46 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? In-Reply-To: <87zku02lyg.fsf@latte.josefsson.org> References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> <87zku02lyg.fsf@latte.josefsson.org> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Isn't this another problem? Often private keys are protected by a > password or requires a PIN to unlock a smartcard, and iterating to > sign with all keys becomes a user interface issue quickly. Indeed. If you are faced with such an implementation, you probably should tell your client which key to use (possibly directly, possibly via some sort of configuration). /~\ 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 Wed Oct 27 10:50:21 2010 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 BDCF13A6A28 for ; Wed, 27 Oct 2010 10:50:21 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDNEK20GD3Rc for ; Wed, 27 Oct 2010 10:50:20 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id E4A743A6A13 for ; Wed, 27 Oct 2010 10:50:19 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 7448671705 for ; Wed, 27 Oct 2010 17:52:03 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 57B9C63B101; Wed, 27 Oct 2010 17:51:49 +0000 (UTC) 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 39A3163B100 for ; Wed, 27 Oct 2010 17:51:47 +0000 (UTC) Received: from [192.168.1.207] (account galb [192.168.1.207] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 7480310; Wed, 27 Oct 2010 10:51:47 -0600 Message-ID: <4CC858A2.2090108@vandyke.com> Date: Wed, 27 Oct 2010 10:51:46 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Peter Gutmann CC: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 10/26/2010 20:05, Peter Gutmann wrote: > der Mouse writes: > >> So, thoughts? Am I missing something, or is this really as ill-behaved as I >> think? > > I don't think it is. If you've set the server up to allow three tries at auth > then you get three tries (I'm assuming it's set up to allow six here, which is > a bit non-traditional, I would have expected three). Stepping back a bit, why > are you sending *six* keys to the server? Shouldn't the client know which key > it's supposed to use? It seems more like the client is broken than the > server. I don't think the SSH server should count unsigned publickey attempts as failures, since they aren't really an attempt. There are many clients that simply try all the keys they know about as unsigned attempts in an attempt to get connected with less user configuration. A signed publickey attempt with a bad signature probably should be counted as a failure though. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 12:06:19 2010 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 652B13A6844 for ; Wed, 27 Oct 2010 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 tmBzHdwsuBUe for ; Wed, 27 Oct 2010 12:06:18 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 18B8C3A682A for ; Wed, 27 Oct 2010 12:06:18 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id CADE071819 for ; Wed, 27 Oct 2010 19:08:07 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id AA1B063B101; Wed, 27 Oct 2010 19:07:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 83AA063B100 for ; Wed, 27 Oct 2010 19:07:52 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9RJ7YwL021397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 19:07:36 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9RGl1QN031551; Wed, 27 Oct 2010 19:07:33 GMT Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 723455801288206444; Wed, 27 Oct 2010 12:07:24 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 12:07:23 -0700 Date: Wed, 27 Oct 2010 14:07:18 -0500 From: Nicolas Williams To: Simon Josefsson Cc: Peter Gutmann , ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? Message-ID: <20101027190718.GA6536@oracle.com> References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> <87zku02lyg.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zku02lyg.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 08:23:19AM +0200, Simon Josefsson wrote: > Nicolas Williams writes: > > >> (I still think the real problem isn't the server but the client, how's it > >> managing to try six different keys to get to one server?). > > > > Why not? SSH user public keys are effectively pseudonyms, so you can > > see why users might have many of them. Nothing wrong with that... On > > the server side you don't want a client sucking up resources testing > > whether some pubkey or another might work... so the server says all > > might work and the client has to actually sign with those keys, and the > > server also has to implement resource controls pre-authentication > > (including a timer to disconnect if the client takes too long to > > authenticate). > > Isn't this another problem? Often private keys are protected by a > password or requires a PIN to unlock a smartcard, and iterating to sign > with all keys becomes a user interface issue quickly. This is how > libssh2 works, and I couldn't think of any way to avoid it. That's a client-side issue. We're talking about server-side max try counters. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 12:08:00 2010 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 2F36A3A6910 for ; Wed, 27 Oct 2010 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 sqJ70RGtMLwZ for ; Wed, 27 Oct 2010 12:07:59 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 00BD13A691A for ; Wed, 27 Oct 2010 12:07:59 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 078BE7182E for ; Wed, 27 Oct 2010 19:09:49 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id EE32963B101; Wed, 27 Oct 2010 19:09:31 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id CC9A563B100 for ; Wed, 27 Oct 2010 19:09:30 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9RJ9CO3025654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 19:09:13 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9RHb7tL010275; Wed, 27 Oct 2010 19:09:11 GMT Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 723461341288206506; Wed, 27 Oct 2010 12:08:26 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 12:08:26 -0700 Date: Wed, 27 Oct 2010 14:08:21 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Cc: Simon Josefsson , "ietf-ssh@NetBSD.org" , der Mouse Subject: Re: "too many auth failures"? Message-ID: <20101027190821.GB6536@oracle.com> References: <12F5069D-6087-4A21-8675-E7763183FC3D@kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12F5069D-6087-4A21-8675-E7763183FC3D@kth.se> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 06:54:47AM +0000, Love Hörnquist Åstrand wrote: > Simon Josefsson writes: > > Isn't this another problem? Often private keys are protected by a password > > or requires a PIN to unlock a smartcard, and iterating to sign with all keys > > becomes a user interface issue quickly. This is how libssh2 works, and I > > couldn't think of any way to avoid it. > > Maybe I'm missing something, but you don't need to iterate over all > keys since you can ask the ssh server if the public key is ok to use. Yes, but servers can be configured to answer "yes" to all such probes. > To avoid unnecessary processing and user > interaction, the following message is provided for querying whether > authentication using the "publickey" method would be acceptable. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 12:17:43 2010 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 C622F3A682A for ; Wed, 27 Oct 2010 12:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 hUstBYXowjLE for ; Wed, 27 Oct 2010 12:17:42 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id A9DB93A6902 for ; Wed, 27 Oct 2010 12:17:42 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 83B5371835 for ; Wed, 27 Oct 2010 19:19:32 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id E684C63B103; Wed, 27 Oct 2010 19:19:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id F2B5463B101 for ; Wed, 27 Oct 2010 19:18:56 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9RJInsv016192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 19:18:51 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9R9Qah4020977; Wed, 27 Oct 2010 19:18:48 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 723496271288207125; Wed, 27 Oct 2010 12:18:45 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 12:18:45 -0700 Date: Wed, 27 Oct 2010 14:18:39 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? Message-ID: <20101027191838.GF6536@oracle.com> References: <201010271415.KAA00237@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010271415.KAA00237@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 10:15:12AM -0400, der Mouse wrote: > >> My view is that servers should have two failure counters: one for > >> password and keyboard-interactive, another one for all others. > > Yeah, I'd thought about that too, but where do you stop? Which > > counter type would a ZKP use? Or EKE? Or IBE? > > The "all others". > > Think about the point of those failure counters: they're designed to > slow down password-guessing attacks. publickey, ZKP, etc, don't have > anything like password-guessing risks, so it's arguably inappropriate > to do failure counters for them. EKE is password-based, therefore it has a password-guessing problem. I assume ZKP here means zero-knowledge proof, and if it's a proof of a password, then that too falls into the password-based method list that should be subject to a small retry counter. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 12:21:53 2010 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 ECFCB3A68E1 for ; Wed, 27 Oct 2010 12:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 xvYZ8LnWYxOO for ; Wed, 27 Oct 2010 12:21:53 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id C8EC33A6828 for ; Wed, 27 Oct 2010 12:21:52 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id D598971802 for ; Wed, 27 Oct 2010 19:23:42 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 4258F63B101; Wed, 27 Oct 2010 19:23:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id ED5FC63B100 for ; Wed, 27 Oct 2010 19:23:24 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9RJN6vK026825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 19:23:08 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9RHb7tw021343; Wed, 27 Oct 2010 19:23:05 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 723516061288207340; Wed, 27 Oct 2010 12:22:20 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 12:22:19 -0700 Date: Wed, 27 Oct 2010 14:22:13 -0500 From: Nicolas Williams To: Simon Josefsson Cc: Peter Gutmann , ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? Message-ID: <20101027192213.GH6536@oracle.com> References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> <87zku02lyg.fsf@latte.josefsson.org> <20101027190718.GA6536@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101027190718.GA6536@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 02:07:18PM -0500, Nicolas Williams wrote: > On Wed, Oct 27, 2010 at 08:23:19AM +0200, Simon Josefsson wrote: > > Nicolas Williams writes: > > > > >> (I still think the real problem isn't the server but the client, how's it > > >> managing to try six different keys to get to one server?). > > > > > > Why not? SSH user public keys are effectively pseudonyms, so you can > > > see why users might have many of them. Nothing wrong with that... On > > > the server side you don't want a client sucking up resources testing > > > whether some pubkey or another might work... so the server says all > > > might work and the client has to actually sign with those keys, and the > > > server also has to implement resource controls pre-authentication > > > (including a timer to disconnect if the client takes too long to > > > authenticate). > > > > Isn't this another problem? Often private keys are protected by a > > password or requires a PIN to unlock a smartcard, and iterating to sign > > with all keys becomes a user interface issue quickly. This is how > > libssh2 works, and I couldn't think of any way to avoid it. > > That's a client-side issue. We're talking about server-side max try > counters. Also, you could refuse to enter a PIN to get the key skipped... You could specify what key to use... You could specify to not use any keys. You could use an agent that gets the PIN. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 13:02:10 2010 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 3C3933A6912 for ; Wed, 27 Oct 2010 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 5rnAcKQdAs+U for ; Wed, 27 Oct 2010 13:02:08 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 325D23A698F for ; Wed, 27 Oct 2010 13:02:07 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 198CB7184D for ; Wed, 27 Oct 2010 20:03:57 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id F35BD63B101; Wed, 27 Oct 2010 20:03:41 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) (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 6BACA63B100 for ; Wed, 27 Oct 2010 20:03:37 +0000 (UTC) Received: from [18.111.89.246] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o9RIWF8h027041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 14:32:15 -0400 (EDT) Date: Wed, 27 Oct 2010 14:32:15 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith , Peter Gutmann cc: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG, jhutz@cmu.edu Subject: Re: "too many auth failures"? Message-ID: <127BB29787979F81261E7D18@atlantis.pc.cs.cmu.edu> In-Reply-To: <4CC858A2.2090108@vandyke.com> References: <4CC858A2.2090108@vandyke.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, October 27, 2010 10:51:46 AM -0600 Joseph Galbraith wrote: > On 10/26/2010 20:05, Peter Gutmann wrote: >> der Mouse writes: >> >>> So, thoughts? Am I missing something, or is this really as ill-behaved >>> as I think? >> >> I don't think it is. If you've set the server up to allow three tries >> at auth then you get three tries (I'm assuming it's set up to allow six >> here, which is a bit non-traditional, I would have expected three). >> Stepping back a bit, why are you sending *six* keys to the server? >> Shouldn't the client know which key it's supposed to use? It seems more >> like the client is broken than the server. > > I don't think the SSH server should count unsigned publickey attempts as > failures, since they aren't really an attempt. There are many > clients that simply try all the keys they know about as unsigned > attempts in an attempt to get connected with less user configuration. > > A signed publickey attempt with a bad signature probably should be > counted as a failure though. Agree. In fact, I think userauth methods should distinguish between authentication failures and authorization failures (in which authentication succeeded or was not tried), and only count the former. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 13:12:19 2010 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 771973A69A0 for ; Wed, 27 Oct 2010 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 Njptj9d8OnCT for ; Wed, 27 Oct 2010 13:12:16 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 4648F3A698F for ; Wed, 27 Oct 2010 13:12:16 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 2C5B771812 for ; Wed, 27 Oct 2010 20:14:06 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id F196B63B101; Wed, 27 Oct 2010 20:13:48 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 564EB63B100 for ; Wed, 27 Oct 2010 20:13:47 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9RKDOE2030086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 20:13:26 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9RIhEZV019800; Wed, 27 Oct 2010 20:13:24 GMT Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 723689441288210342; Wed, 27 Oct 2010 13:12:22 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 13:12:21 -0700 Date: Wed, 27 Oct 2010 15:12:16 -0500 From: Nicolas Williams To: nisse@lysator.liu.se Cc: Simon Josefsson , Peter Gutmann , ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? Message-ID: <20101027201215.GJ6536@oracle.com> References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> <87zku02lyg.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Oct 27, 2010 at 09:53:39PM +0200, nisse@lysator.liu.se wrote: > Simon Josefsson writes: > > Often private keys are protected by a password or requires a PIN to > > unlock a smartcard, and iterating to sign with all keys becomes a user > > interface issue quickly. > > As far as I understand, the possibility to send a > SSH_MSG_USERAUTH_REQUEST without a signature in it is intended to solve > precisely this problem. But some servers always answer that query positively. A better solution is to have ssh-agent-like facilities that can use your smartcard/token, and to which you give your PIN. Certainly there's no way to prevent the advent of such agents. > The client can store the *public* keys somewhere where you don't need > any user interaction to retrieve them, send a bunch of userauth requests > with these keys and no signatures. When you get a SSH_MSG_USERAUTH_PK_OK > response from the server, you ask the user to unlock the corresponding > private key and send a single SSH_MSG_USERAUTH_REQUEST with both key and > signature. This shouldn't have to cost more than a single network > roundtrip, independent of the number of public keys. Even so users won't like having to interact even that much. > (Since I'd consider that client behaviour perfectly normal, I also think > that the server should *not* increment the failure counter when sending > a SSH_MSG_USERAUTH_PK_OK). Yes. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 13:58:33 2010 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 1DD093A63EC for ; Wed, 27 Oct 2010 13:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 KIoeQqNXPHTh for ; Wed, 27 Oct 2010 13:58:32 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 136EC3A63D3 for ; Wed, 27 Oct 2010 13:58:32 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id DEB047180E for ; Wed, 27 Oct 2010 21:00:21 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id EA3C563B102; Wed, 27 Oct 2010 21:00:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 5BB2163B101 for ; Wed, 27 Oct 2010 21:00:03 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BD2124000C; Wed, 27 Oct 2010 21:53:52 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id B182D40008; Wed, 27 Oct 2010 21:53:52 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 040984000C; Wed, 27 Oct 2010 21:53:43 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4) with ESMTP id o9RJrhBf006301; Wed, 27 Oct 2010 21:53:43 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4/Submit) id o9RJrd1F006300; Wed, 27 Oct 2010 21:53:39 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Simon Josefsson Cc: Nicolas Williams , Peter Gutmann , ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> <87zku02lyg.fsf@latte.josefsson.org> Date: Wed, 27 Oct 2010 21:53:39 +0200 In-Reply-To: <87zku02lyg.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed, 27 Oct 2010 08:23:19 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Josefsson writes: > Often private keys are protected by a password or requires a PIN to > unlock a smartcard, and iterating to sign with all keys becomes a user > interface issue quickly. As far as I understand, the possibility to send a SSH_MSG_USERAUTH_REQUEST without a signature in it is intended to solve precisely this problem. The client can store the *public* keys somewhere where you don't need any user interaction to retrieve them, send a bunch of userauth requests with these keys and no signatures. When you get a SSH_MSG_USERAUTH_PK_OK response from the server, you ask the user to unlock the corresponding private key and send a single SSH_MSG_USERAUTH_REQUEST with both key and signature. This shouldn't have to cost more than a single network roundtrip, independent of the number of public keys. (Since I'd consider that client behaviour perfectly normal, I also think that the server should *not* increment the failure counter when sending a SSH_MSG_USERAUTH_PK_OK). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 14:54:44 2010 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 3FF033A67ED for ; Wed, 27 Oct 2010 14:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 elHoDfhDKl-C for ; Wed, 27 Oct 2010 14:54:42 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 3031B3A63D2 for ; Wed, 27 Oct 2010 14:54:42 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 0E8ED71865 for ; Wed, 27 Oct 2010 21:56:32 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 4A5DA63B101; Wed, 27 Oct 2010 21:56:18 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 B64C763B100 for ; Wed, 27 Oct 2010 21:56:15 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0B7DF4000C; Wed, 27 Oct 2010 23:56:14 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id F08FE4001A; Wed, 27 Oct 2010 23:56:13 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id D8E144000C; Wed, 27 Oct 2010 23:56:13 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4) with ESMTP id o9RLuDJd011400; Wed, 27 Oct 2010 23:56:13 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4/Submit) id o9RLuCjY011399; Wed, 27 Oct 2010 23:56:12 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Nicolas Williams Cc: Simon Josefsson , Peter Gutmann , ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? References: <20101027052304.GW6536@oracle.com> <20101027055411.GZ6536@oracle.com> <87zku02lyg.fsf@latte.josefsson.org> <20101027201215.GJ6536@oracle.com> Date: Wed, 27 Oct 2010 23:56:12 +0200 In-Reply-To: <20101027201215.GJ6536@oracle.com> (Nicolas Williams's message of "Wed, 27 Oct 2010 15:12:16 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Nicolas Williams writes: > On Wed, Oct 27, 2010 at 09:53:39PM +0200, nisse@lysator.liu.se wrote: >> As far as I understand, the possibility to send a >> SSH_MSG_USERAUTH_REQUEST without a signature in it is intended to solve >> precisely this problem. > > But some servers always answer that query positively. Which servers do that? That seems like very broken behaviour to me. It would be somewhat understandable if there were some library function which checks the signature and the authorization as an (to the caller) atomic step. But I'd rather expect an ssh implementation to do something like if (key_authorized(...)) { if (signature_provided) { if (signature_correct(...)) send SSH_MSG_USERAUTH_SUCCESS, and start service else send SSH_MSG_USERAUTH_FAILURE } else send SSH_MSG_USERAUTH_PK_OK } else send SSH_MSG_USERAUTH_FAILURE where signature verification and authorization are independent functions, possibly even in different libraries. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 17:44:49 2010 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 2EC323A67E6 for ; Wed, 27 Oct 2010 17:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.023 X-Spam-Level: X-Spam-Status: No, score=-5.023 tagged_above=-999 required=5 tests=[AWL=1.576, 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 ZLZhUEJlEp7j for ; Wed, 27 Oct 2010 17:44:46 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id B41193A67D9 for ; Wed, 27 Oct 2010 17:44:45 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 0EE587189B for ; Thu, 28 Oct 2010 00:46:36 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id EE9F463B102; Thu, 28 Oct 2010 00:46:21 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.auckland.ac.nz", Issuer "AusCERT Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 05F3E63B100 for ; Thu, 28 Oct 2010 00:46:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1288226780; x=1319762780; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20Nicolas.Williams@oracle.com,=20simon@josefsson.org |Subject:=20Re:=20"too=20many=20auth=20failures"?|Cc:=20i etf-ssh@netbsd.org,=20mouse@Rodents-Montreal.ORG,=0D=0A =20=20=20=20pgut001@cs.auckland.ac.nz|In-Reply-To:=20<201 01027192213.GH6536@oracle.com>|Message-Id:=20|Date:=20Thu,=2028=20Oc t=202010=2013:46:12=20+1300; bh=hbbvZApSn8/aL4KMjaPilVrQISKZU7ZHufGg6KDawfM=; b=ruOr4gkeJv62h6lW6uPQf3WmMdFmlXk7b5mWn+BE4GoK6pTwV1YE9126 E3oDeNtdaFZDs61q2V5c5XtVhh28wN+nntZ9+1bDRFFmwbEpFA7sARaA4 QCE/dnGLJsd3MREgIAn7PEuB1ov4l2wRD6Vjrsm06WcZvCRLJ2kIfgbB9 g=; X-IronPort-AV: E=Sophos;i="4.58,248,1286103600"; d="scan'208";a="33131994" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Oct 2010 13:46:13 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PBGdA-0000KL-Iy; Thu, 28 Oct 2010 13:46:12 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PBGdA-000409-Qy; Thu, 28 Oct 2010 13:46:12 +1300 From: Peter Gutmann To: Nicolas.Williams@oracle.com, simon@josefsson.org Subject: Re: "too many auth failures"? Cc: ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG, pgut001@cs.auckland.ac.nz In-Reply-To: <20101027192213.GH6536@oracle.com> Message-Id: Date: Thu, 28 Oct 2010 13:46:12 +1300 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list [Combining several replies to save space] der Mouse writes: >> Stepping back a bit, why are you sending *six* keys to the server? >> Shouldn't the client know which key it's supposed to use? > >How should it know that? By keeping track of which key belongs to which server. When I sign in to gmail I (meaning Firefox acting on my behalf) don't try forty different passwords in the hope that one fits, I send the exact password that's used for gmail. Why is the SSH client unable to do the same thing for a public key? Simon Josefsson writes: >Also, you could refuse to enter a PIN to get the key skipped... You could >specify what key to use... You could specify to not use any keys. You could >use an agent that gets the PIN. You forgot the one that actually happens, based on extensive real-life experience with S/MIME and SSL: - The user bypasses the annoying security mechanisms in order to get on with their job and avoid all the crap that their (from their perspective) broken software is throwing at them. James Cloos writes: >Ssh(1) will try the key specificed on the command line or in the config files >for the specified remote host, if any. Should that fail, it then tries every >key in the agent in the order they were ssh-add(1)ed. That sounds like really, really broken behaviour. You're saying the client is totally unable to keep track of which key is used to authenticate to which server, and just tries them at random in the hope that one fits? That would be like Firefox (see above) trying every stored password it knows for every site in the hope that one works. There are an awful lot of password managers around for browsers with a huge number of users (the Roboforms one, the last time I checked, claimed 28 million downloads), and none of them resort to this kind of brokenness. This could even be a security problem, because a malicious server can get a client to sign an auth message using any key the client holds, which it can then forward to another server and impersonate the client. The only thing preventing this is the exchange hash, which requires that either the malicious server can create collisions with SHA-1 or that the target server is using a poor RNG *cough*Debian*cough* so you can keep the exchange hash constant. Still, a mechanism that allows the server to have the client act as an arbitrary signing oracle really doesn't seem like a good idea. >From the above it certainly looks to me like the client is badly broken. Fix the client, don't require all sorts of kludgery at the server. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 27 19:46:45 2010 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 069713A67AF for ; Wed, 27 Oct 2010 19:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.812 X-Spam-Level: X-Spam-Status: No, score=-6.812 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 twcpjVTXqyZA for ; Wed, 27 Oct 2010 19:46:42 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 591DC3A65A5 for ; Wed, 27 Oct 2010 19:46:42 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 76524718D9 for ; Thu, 28 Oct 2010 02:48:32 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id E561763B101; Thu, 28 Oct 2010 02:48:16 +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 CAE5363B100 for ; Thu, 28 Oct 2010 02:48:14 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id WAA05056; Wed, 27 Oct 2010 22:48:12 -0400 (EDT) Date: Wed, 27 Oct 2010 22:48:12 -0400 (EDT) From: der Mouse Message-Id: <201010280248.WAA05056@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. X-Composition-Start-Date: Wed, 27 Oct 2010 22:03:54 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: "too many auth failures"? In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>> Shouldn't the client know which key it's supposed to use? >> How should it know that? > By keeping track of which key belongs to which server. When I sign > in to gmail I (meaning Firefox acting on my behalf) don't try forty > different passwords in the hope that one fits, I send the exact > password that's used for gmail. Why is the SSH client unable to do > the same thing for a public key? Well, in the most naïve form, the answer is "because I never implemented it" (mutatis mutandis for those using other implementations). But it's worth thinking about why the difference arises. The biggest difference, I think, is simple: the damage potentially done by trying inappropriate keys is substantially less than that done by trying inappropriate passwords. If you reveal to me the public key for the key pair you to ssh-authenticate yourself to (say) your employer, I don't learn enough to do anything significant. But if you send me your gmail password then I can trivially impersonate you to gmail. This makes it far more reasonable for your ssh client to not bother keeping track of which keys work for which servers - and, at the same time, far more reasonable for you to use the same key for disparate servers. Also relevant: there reasonably can be (and often are) many keys which work for a single login. There rarely are multiple passwords which work for a single login. That said, the ability to for the client to be told, or perhaps even autolearn, what keys work for what servers is probably a desirable thing, even if not particularly valuable in many cases. It does, however, appear to be comon for clients to not do it. >> [...client just tries keys it has available...] > That sounds like really, really broken behaviour. You're saying the > client is totally unable to keep track of which key is used to > authenticate to which server, and just tries them at random in the > hope that one fits? Generally, yes. (Well, for weak values of "random".) > That would be like Firefox (see above) trying every stored password > it knows for every site in the hope that one works. Except significantly less bad; see above. > There are an awful lot of password managers around for browsers with > a huge number of users (the Roboforms one, the last time I checked, > claimed 28 million downloads), and none of them resort to this kind > of brokenness. Because with passwords, you can't really do that; the exposure is too high. One of the nice things about public-key auth is that you _can_ do that without significant ill effects. > This could even be a security problem, because a malicious server can > get a client to sign an auth message using any key the client holds, > which it can then forward to another server and impersonate the > client. This is called a man-in-the-middle attack. Passwords are vulnerable to it (among many other active attacks). ssh is carefully designed to _not_ be vulnerable to it - well, except for first connect in cases where the user incorrectly believes it's safe to trust the peer-presented host key; those in situations where such risks are part of the threat model should take care to not do that. There might even be a place for clients that don't support doing it at all. > Still, a mechanism that allows the server to have the client act as > an arbitrary signing oracle really doesn't seem like a good idea. Then perhaps it's just as well ssh takes care to make sure it can't be abused that way. This is (part of) why client-chosen entropy and server-chosen entropy are both mixed into the data signed during PK auth: the server does not get to have the client sign arbitrary data. > Fix the client, don't require all sorts of kludgery at the server. Fortunately or unfortunately, that ship has sailed: ssh requires that the server include support for this sort of behaviour by the client. Of course, servers may choose to refuse service to clients that take advantage of it, or can go out of their way to be obnoxious to clients that try to use it (by lying, claiming that keys that cannot work might work); as this thread demonstrates, such server behaviour is widely considered problematic, even broken - and, I believe, with good cause. I certainly know I'd file a bug report with the applicable vendor upon encountering such behaviour (as I intend to with the vendor whose server started this off - quite likely would have today except that other issues blew up). /~\ 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 Wed Oct 27 20:59:45 2010 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 790F33A6835 for ; Wed, 27 Oct 2010 20:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 ocUrJg++dmpV for ; Wed, 27 Oct 2010 20:59:44 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 5B4583A680A for ; Wed, 27 Oct 2010 20:59:44 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id CCFE071718 for ; Thu, 28 Oct 2010 04:01:34 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 06DAD63B103; Thu, 28 Oct 2010 04:01:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id C7C7E63B102 for ; Thu, 28 Oct 2010 04:01:17 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9S40xKi030532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 04:01:00 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9S0p990022086; Thu, 28 Oct 2010 04:00:57 GMT Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 729510991288238409; Wed, 27 Oct 2010 21:00:09 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 21:00:08 -0700 Date: Wed, 27 Oct 2010 23:00:04 -0500 From: Nicolas Williams To: Peter Gutmann Cc: simon@josefsson.org, ietf-ssh@netbsd.org, mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? Message-ID: <20101028040003.GN6536@oracle.com> References: <20101027192213.GH6536@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, Oct 28, 2010 at 01:46:12PM +1300, Peter Gutmann wrote: > [Combining several replies to save space] > > Simon Josefsson writes: > > >Also, you could refuse to enter a PIN to get the key skipped... You could > >specify what key to use... You could specify to not use any keys. You could > >use an agent that gets the PIN. I wrote that, not Simon :) > You forgot the one that actually happens, based on extensive real-life > experience with S/MIME and SSL: > > - The user bypasses the annoying security mechanisms in order to get on with > their job and avoid all the crap that their (from their perspective) broken > software is throwing at them. How would they do that from the client side? Anyways, I suspect that SSH keys are rarely stored on smartcards, so this isn't a big problem _yet_. I agree that it will be, ... ...but the most reasonable solution is to hand the smartcard and PIN to an ssh-agent. If the user's not willing even to type a PIN _once_, then smartcards won't succeed. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 28 02:09:37 2010 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 3171E3A681F for ; Thu, 28 Oct 2010 02:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.969 X-Spam-Level: X-Spam-Status: No, score=-5.969 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 LvvYu9BsOfqV for ; Thu, 28 Oct 2010 02:09:36 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id A51523A67EB for ; Thu, 28 Oct 2010 02:09:35 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 55F62717D3 for ; Thu, 28 Oct 2010 09:11:26 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 7E7FD63B100; Thu, 28 Oct 2010 09:11:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 54D0B63B101; Thu, 28 Oct 2010 09:11:08 +0000 (UTC) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by mail.netbsd.org (Postfix) with ESMTP id B770E63B103 for ; Wed, 27 Oct 2010 09:00:34 +0000 (UTC) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 0A63815798F; Wed, 27 Oct 2010 08:54:54 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 87fcM4vWI6Py; Wed, 27 Oct 2010 08:54:51 +0200 (CEST) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 931681558B1; Wed, 27 Oct 2010 08:54:48 +0200 (CEST) Received: from EXDB1.ug.kth.se ([169.254.1.195]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 08:54:47 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: Simon Josefsson CC: Nicolas Williams , Simon Josefsson , "ietf-ssh@NetBSD.org" , der Mouse Subject: Re: "too many auth failures"? Thread-Topic: "too many auth failures"? Thread-Index: AQHLdaI9dLNUSGcCtk+nkH0dxZbFwJNUOuUA Date: Wed, 27 Oct 2010 06:54:47 +0000 Message-ID: <12F5069D-6087-4A21-8675-E7763183FC3D@kth.se> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [99.52.202.108] Content-Type: multipart/signed; boundary="Apple-Mail-434-617643037"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail-434-617643037 Content-Type: multipart/alternative; boundary=Apple-Mail-433-617642966 --Apple-Mail-433-617642966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Simon Josefsson writes: > Isn't this another problem? Often private keys are protected by a = password > or requires a PIN to unlock a smartcard, and iterating to sign with = all keys > becomes a user interface issue quickly. This is how libssh2 works, = and I > couldn't think of any way to avoid it. Maybe I'm missing something, but you don't need to iterate over all keys = since you can ask the ssh server if the public key is ok to use. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the "publickey" method would be acceptable. byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string "publickey" boolean FALSE string public key algorithm name string public key blob Love --Apple-Mail-433-617642966 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Simon = Josefsson <simon@josefsson.org> = writes:

Isn't this another problem? =  Often private keys are protected by a = password
or requires a PIN to = unlock a smartcard, and iterating to sign with all = keys
becomes a user interface = issue quickly.  This is how libssh2 works, and = I
couldn't think of any way to = avoid it.

Maybe I'm missing = something, but you don't need to iterate over all keys since you can ask = the ssh server if the public key is ok to = use.

                              To avoid =
unnecessary processing and user
   interaction, the following message is provided for querying whether
   authentication using the "publickey" method would be acceptable.

      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name in ISO-10646 UTF-8 encoding [RFC3629]
      string    service name in US-ASCII
      string    "publickey"
      boolean   FALSE
      string    public key algorithm name
      string    public key =
blob


Love
<= br>

= --Apple-Mail-433-617642966-- --Apple-Mail-434-617643037 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNzA2 NTQ0OFowIwYJKoZIhvcNAQkEMRYEFFCx+j9osNuU9bUwhJAsxP8QOzLlMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBAJpcizq3UHm25/aqX+sgeRmxxJV1ZXhdPGPSH9NGruFaDKWmPJCa trRlL7KDdkzlYzC57RrhIbSehjr3mCaO/9w8zSV5xqtRdnVWnHVdiNd87/Bc4/wronbsocBxJTuy 0EBTxov5OcSdQJnOiLR1Ve8mN6yciYwAR+wanPO6RMEJDozjPetSXOoCBYClGHk90F3Qq/CrKrO4 Moct8Jh7hf4t+QLCZ+m9XjJL8nDjJETdRes5dqvu5VIy/tZgRtU6qLl4p/OxNboi3DEtBiIwLnjg Mt2EBj5cNX3tovJDxsX7sQajLFBdkHqh7DIW236ctPgSwvOJe/6KqauC5sYHu5oAAAAAAAA= --Apple-Mail-434-617643037-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 28 02:10:28 2010 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 DFB8B3A6879 for ; Thu, 28 Oct 2010 02:10:28 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpnwwbHfltdx for ; Thu, 28 Oct 2010 02:10:28 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id BD8FE3A686D for ; Thu, 28 Oct 2010 02:10:27 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 2DB8C718D9 for ; Thu, 28 Oct 2010 09:12:19 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 5AB9763B101; Thu, 28 Oct 2010 09:12:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8F33063B100; Thu, 28 Oct 2010 09:12:03 +0000 (UTC) Received: from email.mocana.com (email.mocana.com [67.102.231.118]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 669EA63B100 for ; Wed, 27 Oct 2010 15:20:08 +0000 (UTC) Received: from yugi.mocana.local ([10.30.30.118]) by yugi.mocana.local ([10.30.30.118]) with mapi; Wed, 27 Oct 2010 07:19:50 -0700 From: James Blaisdell To: "'mouse@Rodents-Montreal.ORG'" , "'ietf-ssh@netbsd.org'" Date: Wed, 27 Oct 2010 07:19:49 -0700 Subject: Re: "too many auth failures"? Thread-Topic: "too many auth failures"? Thread-Index: Act14Wn5PYtJ+71jTBaJmuqE4KSGKwAAJm9y Message-ID: <50DADDE6B33B1B47904E685AAFDC18241B7A4E600F@yugi.mocana.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list V2hhdCBpZiB0aGVyZSBpcyBsaW1pdCBvbiBudW1iZXIgb2Ygc2ltdWx0YW5lb3VzIHNzaCBzZXNz aW9ucz8gTGV0J3Mgc2F5IHN5c3RlbSBjYW4gb25seSByZWFzb25hYmx5IHN1cHBvcnQgYSBzaW5n bGUgc3NoIHNlc3Npb24uIFNob3VsZG4ndCB0aGVyZSBiZSBhIGxpbWl0IHRvIHByZXZlbnQgZG9z IGF0dGFjay4gDQoNCkFsc28sIHB1YmxpYyBrZXkgYXV0aGVudGljYXRpb24gaXMgbm90IGZyZWUg ZnJvbSBhIGNwdSB1dGxpemF0aW9uIHBlcnNwZWN0aXZlLiBPbiBhIDQwTUh6IDY4SyBwcm9jZXNz b3IsIHRoZSBzaWduYXR1cmUgIGNhbiB0YWtlIHdlbGwgb3ZlciBzZWNvbmQgdG8gdmVyaWZ5LiAN Cg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBpZXRmLXNzaC1vd25lckBO ZXRCU0Qub3JnIDxpZXRmLXNzaC1vd25lckBOZXRCU0Qub3JnPg0KVG86IGlldGYtc3NoQG5ldGJz ZC5vcmcgPGlldGYtc3NoQG5ldGJzZC5vcmc+DQpTZW50OiBXZWQgT2N0IDI3IDA3OjE1OjEyIDIw MTAKU3ViamVjdDogUmU6ICJ0b28gbWFueSBhdXRoIGZhaWx1cmVzIj8NCg0KPj4gTXkgdmlldyBp cyB0aGF0IHNlcnZlcnMgc2hvdWxkIGhhdmUgdHdvIGZhaWx1cmUgY291bnRlcnM6IG9uZSBmb3IN Cj4+IHBhc3N3b3JkIGFuZCBrZXlib2FyZC1pbnRlcmFjdGl2ZSwgYW5vdGhlciBvbmUgZm9yIGFs bCBvdGhlcnMuDQo+IFllYWgsIEknZCB0aG91Z2h0IGFib3V0IHRoYXQgdG9vLCBidXQgd2hlcmUg ZG8geW91IHN0b3A/ICBXaGljaA0KPiBjb3VudGVyIHR5cGUgd291bGQgYSBaS1AgdXNlPyAgT3Ig RUtFPyAgT3IgSUJFPw0KDQpUaGUgImFsbCBvdGhlcnMiLg0KDQpUaGluayBhYm91dCB0aGUgcG9p bnQgb2YgdGhvc2UgZmFpbHVyZSBjb3VudGVyczogdGhleSdyZSBkZXNpZ25lZCB0bw0Kc2xvdyBk b3duIHBhc3N3b3JkLWd1ZXNzaW5nIGF0dGFja3MuICBwdWJsaWNrZXksIFpLUCwgZXRjLCBkb24n dCBoYXZlDQphbnl0aGluZyBsaWtlIHBhc3N3b3JkLWd1ZXNzaW5nIHJpc2tzLCBzbyBpdCdzIGFy Z3VhYmx5IGluYXBwcm9wcmlhdGUNCnRvIGRvIGZhaWx1cmUgY291bnRlcnMgZm9yIHRoZW0uDQoN Ci9+XCBUaGUgQVNDSUkJCQkJICBNb3VzZQ0KXCAvIFJpYmJvbiBDYW1wYWlnbg0KIFggIEFnYWlu c3QgSFRNTAkJbW91c2VAcm9kZW50cy1tb250cmVhbC5vcmcNCi8gXCBFbWFpbCEJICAgICA3RCBD OCA2MSA1MiA1RCBFNyAyRCAzOSAgNEUgRjEgMzEgM0UgRTggQjMgMjcgNEINCg== From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 28 02:13:31 2010 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 52BEC3A6831 for ; Thu, 28 Oct 2010 02:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.836 X-Spam-Level: X-Spam-Status: No, score=-3.836 tagged_above=-999 required=5 tests=[AWL=2.763, 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 MccyiqWfSvw1 for ; Thu, 28 Oct 2010 02:10:59 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 695303A686D for ; Thu, 28 Oct 2010 02:10:58 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 9EF7571818 for ; Thu, 28 Oct 2010 09:12:48 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 9810C63B108; Thu, 28 Oct 2010 09:12:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8E23C63B103; Thu, 28 Oct 2010 09:12:29 +0000 (UTC) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "eagle.jhcloos.com", Issuer "CA Cert Signing Authority" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 8361963B102 for ; Wed, 27 Oct 2010 21:24:21 +0000 (UTC) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 2D77C400D0; Wed, 27 Oct 2010 21:23:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1288214658; bh=eWEYCWaW3gIw/dyUwksfahkMSUOHNtjZj/CD25sJSsQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NfJ/wBez6/YEI0A4uZLwxDkH0RZ+AjDGgLYBAipkVHZf4o9I9YkV1SPbzGIzSIvse OuA20+5Lnp1Dc4koIpvsB89FJyk8oMVHMAYs2teWoZGEiQlh7pVMNGqwHdI2MAU3L4 FhVx+p2VsRV0e3cxvIAN87sT5gTj29yCF1UezQqY= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 62E881E9A96; Wed, 27 Oct 2010 21:18:36 +0000 (UTC) From: James Cloos To: ietf-ssh@netbsd.org Cc: Peter Gutmann , mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? In-Reply-To: (Peter Gutmann's message of "Wed, 27 Oct 2010 15:05:07 +1300") References: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 27 Oct 2010 17:18:36 -0400 Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:101027:ietf-ssh@netbsd.org::Mt9dv4KZW5jZvI/o:00000000000000000000000000000000000000000VZoZn X-Hashcash: 1:30:101027:pgut001@cs.auckland.ac.nz::P9T9jNPicLmqI9/y:00000000000000000000000000000000000AP5Tt X-Hashcash: 1:30:101027:mouse@rodents-montreal.org::ujYjZtc5ty7FW549:0000000000000000000000000000000000f6qrS Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>>>> "PG" == Peter Gutmann writes: PG> I don't think it is. If you've set the server up to allow three PG> tries at auth then you get three tries (I'm assuming it's set up to PG> allow six here, which is a bit non-traditional, I would have PG> expected three). Stepping back a bit, why are you sending *six* PG> keys to the server? Shouldn't the client know which key it's PG> supposed to use? It seems more like the client is broken than the PG> server. I only use openssh clients. I can’t speak for other implementations. If you have speparate key pairs for specific remote sites, it is very easy to end up with several keys loaded into ssh-agent(1). Ssh(1) will try the key specificed on the command line or in the config files for the specified remote host, if any. Should that fail, it then tries every key in the agent in the order they were ssh-add(1)ed. It seems clear that few if any of the early implementers used more than one rsa, one dsa and one ssh1 key per account back when the v2 protocol worked its way through this working group. Else this issue would have been on the radar back then. One implmentation fix would be a way to say not only ‘use this private key for that set of server(s)’, but also ‘use this private key for ONLY that set of server(s)’. I’m not aware of a way to do that in openssh’s config files. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Oct 31 04:02:21 2010 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 C0A9C3A67A2 for ; Sun, 31 Oct 2010 04:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, 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 G9XCvGuyM1wp for ; Sun, 31 Oct 2010 04:02:21 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id C3FA23A6403 for ; Sun, 31 Oct 2010 04:02:20 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id AF2C971A2D for ; Sun, 31 Oct 2010 11:04:18 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id CA86463B102; Sun, 31 Oct 2010 11:04:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 7CAB963B101 for ; Sun, 31 Oct 2010 11:04:02 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 44EAFC4B09; Sun, 31 Oct 2010 22:03:59 +1100 (EST) Received: from fuyu.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 Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 4520CC4AA9; Sun, 31 Oct 2010 22:03:50 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 36AA13F706; Sun, 31 Oct 2010 22:03:49 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 345E33F705; Sun, 31 Oct 2010 22:03:49 +1100 (EST) Date: Sun, 31 Oct 2010 22:03:49 +1100 (EST) From: Damien Miller To: James Cloos cc: ietf-ssh@netbsd.org, Peter Gutmann , mouse@Rodents-Montreal.ORG Subject: Re: "too many auth failures"? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 27 Oct 2010, James Cloos wrote: > One implmentation fix would be a way to say not only ?use this private > key for that set of server(s)?, but also ?use this private key for ONLY > that set of server(s)?. I?m not aware of a way to do that in openssh?s > config files. ~/.ssh/config's IdentityFile and IdentitiesOnly options do what you want. -d