Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt
Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 30 April 2014 18:14 UTC
Return-Path: <jhutz@cmu.edu>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEE51A091A for <netmod@ietfa.amsl.com>; Wed, 30 Apr 2014 11:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 fhAD_vREkqEO for <netmod@ietfa.amsl.com>; Wed, 30 Apr 2014 11:14:24 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id 701A61A04B6 for <netmod@ietf.org>; Wed, 30 Apr 2014 11:14:24 -0700 (PDT)
Received: from [192.168.1.132] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s3UIEKn9024313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 14:14:21 -0400 (EDT)
Message-ID: <1398881659.20380.39.camel@destiny.pc.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Date: Wed, 30 Apr 2014 14:14:19 -0400
In-Reply-To: <20140430175031.GC31746@elstar.local>
References: <20140429.220505.221212226.mbj@tail-f.com> <nnlhunqplp.fsf@bacon.lysator.liu.se> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <20140430175031.GC31746@elstar.local>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.4-0ubuntu1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.200
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SD0bAtTGhrVinyIoeGBQWE2JHlI
Cc: ietf-ssh@NetBSD.org, Niels Möller <nisse@lysator.liu.se>, netmod@ietf.org, jhutz@cmu.edu
Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Apr 2014 18:14:26 -0000
On Wed, 2014-04-30 at 19:50 +0200, Juergen Schoenwaelder wrote: > On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote: > > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > > > However, if we also keep the leaf algorithm, we need to specify > > > > what happens if the leaf algorithm has a value that is different > > > > from the value embedded in the key blob. > > > > > > Right, eliminating this redundancy makes things simpler. > > > > It would, except you can't eliminate it. The second copy of the > > algorithm name is part of the key data format for _certain public key > > algorithms_, but not necessarily for all of them. > > > > Hm. Are you saying RFC 4716 is broken or only applicable to certain > subset of public key algorithms? In which case would the public key > not follow [RFC4253], Section 6.6: > > string certificate or public key format identifier > byte[n] key/certificate data > > I am just trying to understand this. Section 6.6 is actually quite specific on this: The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. It then goes on to define two key types ("ssh-dss" and "ssh-rsa") which each begin with a fixed string that is the same as the key type name, and two more which are unfortunately rather vague, but which I don't think are commonly used. I seem to recall this being an issue in the past, because someone made an assumption that keys would always be self-describing when in fact they were not. Unfortunately, I no longer remember the exact circumstances. But yes, I believe RFC4716 is broken, because it relies on the encoding described above, rather than being consistent with the requirement "The key type MUST always be explicitly known." IMHO, things that are not implementations of SSH should not need to be aware of SSH's encoding or of the details of particular public key formats. They should treat the opaque key data as opaque, and separate from the key type. -- Jeff
- [netmod] SSH keys - draft-ietf-netmod-system-mgmt Martin Bjorklund
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Niels Möller
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Jeffrey Hutzelman
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Juergen Schoenwaelder
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Jeffrey Hutzelman
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Juergen Schoenwaelder
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Niels Möller
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Martin Bjorklund
- Re: [netmod] SSH keys - draft-ietf-netmod-system-… Niels Möller