Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 30 April 2014 16:33 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 ECBC01A8824 for <netmod@ietfa.amsl.com>; Wed, 30 Apr 2014 09:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 Vui0rNJsHMaN for <netmod@ietfa.amsl.com>; Wed, 30 Apr 2014 09:32:56 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id E49981A8839 for <netmod@ietf.org>; Wed, 30 Apr 2014 09:32:55 -0700 (PDT)
Received: from [192.168.1.132] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s3UGWpR6024221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 12:32:52 -0400 (EDT)
Message-ID: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Niels Möller <nisse@lysator.liu.se>
Date: Wed, 30 Apr 2014 12:32:50 -0400
In-Reply-To: <nnlhunqplp.fsf@bacon.lysator.liu.se>
References: <20140429.220505.221212226.mbj@tail-f.com> <nnlhunqplp.fsf@bacon.lysator.liu.se>
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.201
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cSNO0ThQkIUhvsLqDU8C80Qno78
X-Mailman-Approved-At: Wed, 30 Apr 2014 09:54:04 -0700
Cc: ietf-ssh@NetBSD.org, 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 16:33:02 -0000

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.

The right thing here is to leave it as defined - the "algorithm" is a
string naming the public key algorithm, and the "key-data" is an
_opaque_ base64 blob.  The fact that for certain kinds of keys the
opaque blob happens to contain a copy of the algorithm name is
irrelevant.

As for what happens when they're different -- it doesn't work!  If you
say you're providing a key for one algorithm and actually provide key
data for a different one, it's simply not going to work.  You could
check when setting a key that the provided key data is valid for the
specified algorithm, but I would very strongly recommend against that.
Doing so requires that whatever's doing the validation understand all
possible key algorithms, which is impossible, since public key algorithm
names are a vendor-extensible namespace.


> I think it would make more sense to have a name that reflects the
> *purpose* of the list of keys, rather than just the data type. E.g., if
> it's authorization keys for logging in to the users account, it could be
> "authorized-ssh-keys" or something like that.

Yes.