SSH keys - draft-ietf-netmod-system-mgmt

[Martin Bjorklund <mbj%tail-f.com@localhost>]

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