[netmod] SSH keys - draft-ietf-netmod-system-mgmt
Martin Bjorklund <mbj@tail-f.com> Tue, 29 April 2014 20:05 UTC
Return-Path: <mbj@tail-f.com>
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 9010E1A097F for <netmod@ietfa.amsl.com>; Tue, 29 Apr 2014 13:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 xBaFBH01n9HN for <netmod@ietfa.amsl.com>; Tue, 29 Apr 2014 13:05:21 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id DDAD91A098F for <netmod@ietf.org>; Tue, 29 Apr 2014 13:05:08 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id EDC453F4007; Tue, 29 Apr 2014 22:05:05 +0200 (CEST)
Date: Tue, 29 Apr 2014 22:05:05 +0200
Message-Id: <20140429.220505.221212226.mbj@tail-f.com>
To: ietf-ssh@NetBSD.org
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs
Cc: netmod@ietf.org
Subject: [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: Tue, 29 Apr 2014 20:05:25 -0000
Hi, The NETMOD WG has produced draft-ietf-netmod-system-mgmt-15, which contains a YANG data model for system management. This document today enters a second IETF Last Call. Among other things, it has a data model for the definition of SSH public keys for local users on a device. Stephen Farrell suggested that this list might be able to help us with an SSH-specific question. We would be very grateful for any expert help. First some background. The data model in question has this structure (objects unrelated to SSH keys removed) +--rw user* [name] +--rw name string +--rw ssh-key* [name] +--rw name string +--rw algorithm string +--rw key-data binary This means that there is a list of users, identified by name. Each user has a list of public SSH keys, identified by an arbitrary name. Zooming in on the ssh-key list, it looks like this: list ssh-key { key name; description "A list of public SSH keys for this user."; reference "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; leaf name { type string; description "An arbitrary name for the ssh key."; } leaf algorithm { type string; mandatory true; description "The public key algorithm name for this ssh key. Valid values are the values in the IANA Secure Shell (SSH) Protocol Parameters registry, Public Key Algorithm Names"; reference "IANA Secure Shell (SSH) Protocol Parameters registry, Public Key Algorithm Names"; } leaf key-data { type binary; mandatory true; description "The binary key data for this ssh key."; } } Now to the problem. During implementation of ssh key handling, we realized that the description of these objects need at least some clarification. The intention was that the separation of the key with two leafs, "algorithm" and "key-data" makes it easy to cut-and-paste from keys generated with ssh-keygen etc. (The encoding of type binary in YANG is base64, which happen to match the key format. So the operator can set the "algorithm" and pase the base64 encoded blob into "key-data".) First of all, it is not entirely clear what goes into the "key-data" leaf. Common file formats (open ssh proprietary, RFC4716) follow the same rules; defined in RFC4716: The body of a public key file is the base64 encoded ([RFC2045]) public key data as specified by [RFC4253], Section 6.6: string certificate or public key format identifier byte[n] key/certificate data The open ssh internal format is this: <algorithm> <base64 key data> e.g.: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBNX... The base64 blob is encoded as described above, i.e. it contains the string "ssh-rsa", even though this is already specified at the start of the line. So this format is redundant, and it seems the implementation detects and rejects keys that have different values for the <algorithm> and the public key format identifier. The RFC 4716 format does not have this redundancy: ---- BEGIN SSH2 PUBLIC KEY ---- AAAAB3NzaC1yc2EAAAADAQABAAABAQDBNX... ... ---- END SSH2 PUBLIC KEY ---- So we have some options: 1) Clarify that the leaf "key-data" contains: string certificate or public key format identifier byte[n] key/certificate data This allows for simple copy-and-paste from normal open ssh and rfc4716 files. 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. 2) Like 1, but remove the "leaf algorithm". 3) Keep "leaf algorithm" and specify that the leaf "key-data" contains: byte[n] key/certificate data This is NOT copy-and-paste friendly and probably pretty confusing to operators. Some other issues, probably less important. o If we do 1 or 2 above, is the name "key-data" really correct; shouldn't it be changed to just "key", in order to use the same terminology as RFC 4253: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data Which says that a "key" is encoded as "format id" + "key data". o Should list "ssh-key" be called "ssh-public-key"? The description says it is public keys only, so shouldn't this be reflected in the name of the list? We are leaning towards option 2 above, and would very much appreciate any comments on this matter! /martin
- [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