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

[[e-mail] (Niels Möller )]

Martin Bjorklund <[e-mail]> writes:

> [e-mail] (Niels Möller) wrote:

>> So then the right choice is 1),
>> 
>> : 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.
>
> But Jeffrey Hutzelman wrote:
>
>    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."

It would have made some sense for the RFC 4716 public key format to
include some other header for the algorithm, but I'm not sure it's
"broken". I think one reasonable interpretation of "The key type MUST
always be explicitly known." is that it's inappropriate to define
mechanisms *within* the ssh protocol which accept a key of arbitrary
type, without any algorithm negotiation or advertisement, so that the
receiver has to take the key apart and then do some dispatch on the
embedded algorithm type.

But that doens't necessarily rule out passing around arbitrary keys
*outside* of the ssh wire protocol, without specifying key type
explicitly.

> I am a bit confused by the terminology.  What is the difference
> between "key", "key data", and "key blob"?

Sorry about that. I think the data for the "key-data" leaf should be as
you specify it above. E.g., for an RSA key, the ssh transport encoding
of

      string    "ssh-rsa"
      mpint     e
      mpint     n

The one thing that seems clear to me is that you shouldn't strip that
algorithm field from your "key-data" leaf.

> So if we introduce the clarification (1) above, aren't we doing the
> same mistake as RFC 4716?

If you also include the string "ssh-rsa" in the "algorithm" leaf, you
*do* have that extra information, missing from RFC 4716. So if it's a
mistake, it's a different mistake.

A small practical problem is that if you want to do simple
copy-and-paste from rfc4716 files, you also need a tool to extract the
algorithm identifier, so you can set the "algorithm" leaf correctly. And
I see nothing wrong in doing that; it is properly specified in both RFC
4716 and RFC4253 how to do that, and any tools handing RFC4716 files at
all can be expected to have some knowledge of ssh specifics.

I have to admit I'm also a bit confused at this point... it's getting
less and less clear to me if it really is the right thing to include
algorithm info separately. My gut reaction was no, and then Jeffrey
convinced me it's necessary, and now I just don't know.

Pro: Having the algorithm separately simplifies some use cases. Say, you
want to compare the information in your files to the configuration of an
ssh implementation to see if available keys are supported.

Cons: You could get subtle failure modes if you do the above, and the
data is inconsistent. Say some program ignores your algorithm leaf
(e.g., you export the key data in RFC 4716 format), and some doesn't
(e.g., the algorithm leaf makes it through to the ssh configuration, and
then the key is invalid, and results in an error locally or remotely).

Probably no *big* problems either way.

In case you use this data to keep track of authorized user or host keys,
I think it's prudent to make sure than any key-data leaf not matching
the corresponding "algorithm" leafs is treated as an invalid key. And,
e.g., refuse to export it in RFC 4716 format.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.