From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Jul 31 07:51:59 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8507312D0F0 for ; Sun, 31 Jul 2016 07:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbTIBoBcv4X8 for ; Sun, 31 Jul 2016 07:51:58 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9E612D0BF for ; Sun, 31 Jul 2016 07:51:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E93E485EB0; Sun, 31 Jul 2016 14:51:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id A6B1185E44; Sun, 31 Jul 2016 14:51:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 35DC085EFF for ; Sat, 30 Jul 2016 01:29:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id R9LJjWRzviSN for ; Sat, 30 Jul 2016 01:29:35 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A8C8B85E57 for ; Sat, 30 Jul 2016 01:29:35 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) for ietf-ssh@netbsd.org; Sat, 30 Jul 2016 02:29:17 +0100 Message-ID: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> From: "denis bider \(Bitvise\)" To: Subject: rsa-sha2-256/512: handling of incorrect signature encoding Date: Fri, 29 Jul 2016 19:28:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hey everyone, last month, we released versions 7.xx of Bitvise SSH Server and Client, which implement the new rsa-sha2-256 and rsa-sha2-512 signatures. We thought we worked out any compatibility issues prior to release – the algorithms interoperate with the OpenSSH 7.2p2 versions we’ve tried. However, we’ve now learned of a user who is connecting from Arch Linux using OpenSSH 7.2 (without p2), and it appears that this version encodes tha rsa-sha2-512 signature (and probably also -256) in a different way than our implementation expects. The problem is related to the multiple instances of algorithm names encoded in a “publickey” authentication request. First, the algorithm is encoded in the immediate request itself: byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication string signature In this case: - "public key algorithm name" should be either "rsa-sha2-256" or "rsa-sha2-512" - "public key to be used for authentication" should be an "ssh-rsa" public key, like this: string "ssh-rsa" mpint e mpint n - "signature" should be an "rsa-sha2-256" or "rsa-sha2-512" signature, like this: string "rsa-sha2-256" / "rsa-sha2-512" string rsa_signature_blob To summarize, there are three algorithm names being encoded, and they are in sequence: (1) "rsa-sha2-256" or "-512" or "ssh-rsa" (2) "ssh-rsa" (3) "rsa-sha2-256" or "-512" or "ssh-rsa" The invariants our implementation currently expects are: - name 1, in the USERAUTH request, can be any of the RSA signature algorithm names - name 2, in the public key blob, must be "ssh-rsa" - name 3, in the signature blob, must match name 1 However, what actually happens in OpenSSH 7.2 (not p2) is that name 1 is "rsa-sha2-512", but name 3 is "ssh-rsa". This causes a mismatch and an authentication failure with our implementation, because name 1 does not match name 3. My questions are: (A) Should we add "ssh-rsa" - and "ssh-rsa" only, not any other name - as a possible alias in name 3, which should be interpreted as an acceptable alternative if "rsa-sha2-256" or "rsa-sha2-512" is sent in name 1? Is this harmless? or (B) Should we deny an attempt to authenticate using mismatched name 1 and name 3, and inform the user to look into upgrading their software? Note that software often cannot be easily upgraded, and the practical alternative will be to disable the new signature algorithms, and continue to use "ssh-rsa". If we decide to do (A), should we allow "ssh-rsa" to be accepted in ALL situations where the verifier has out-of-band knowledge that the actual signature algorithm is "rsa-sha2-256" or "-512"? For example, should a server be able to send an "ssh-rsa" signature that's actually "rsa-sha2-512" because the negotiated algorithm is "rsa-sha2-512"? Or should the accommodation be restricted to client authentication only? Regardless of what we think is best - should we put a paragraph about this in the rsa-sha2 draft? denis