draft-ietf-rtgwg-yang-key-chain was: Re: [Netconf] Draft Charter Proposal for NETCONF WG

[t.petch <[e-mail]>]

Acee

Changing the title and switching to rtgwg! and inserting after <tp>

Tom Petch

----- Original Message -----
From: "Acee Lindem (acee)" <[e-mail]>
Sent: Thursday, March 23, 2017 9:01 PM


Hi Kent, Tom, et al,

On 3/23/17, 4:40 PM, "Kent Watsen" <[e-mail]> wrote:

>Hi Tom,
>
>> Sorry about mixing up keystore and keychain - I did download the
>> updated draft last week but failed to find it when I was drafting
>> my post. However, while I know the English semantics of store and
>> chain, I do find it more difficult to attach different semantics
>> to keystore and key-chain, and I do find the Abstracts of the two
>> I-Ds rather similar which leaves me uncertain about the scope of
>> the work in Netconf.
>
>understood.
>
>> When the proposed charter says
>> "  1. Finalize the YANG data module for a system-level keystore
>>       mechanism, that can be used to hold onto asymmetric private
>>       keys and certificates that are trusted by the system
>>       advertising support for this module."
>>
>> I am still uncertain.
>
>understood.
>
>> You are saying symmetric keys may come in future but should this
>> be part of the charter now? I am divided on this.
>
>I'm also divided on it, but it is the case that we had passwords
>(read "symmetric keys")

I wouldn¹t equate a password with a symmetric key.

>in the previous version of the keystore
>draft and, the reason that they're not there now is because we
>moved the passwords to the ietf-ssh-client module in the current
>version of the draft...a decision that I consider to be "under
>review" and to be discussed in Chicago.
>
>> You are saying you are unsure about system-level but what is it
>> then, not that I have ever realised what is meant by system-level
>> (unless it means not just for routers, but then the Abstract of
>> key-chain, for the first five sentences, sounds like a system-wide
>> model with sentence six only saying it is commonly used for routing
>> protocols, it does not say it is not also for system-wide use!).
>>
>> I would then avoid system-level, since I do not understand it:-(
>
>I agree, for the reasons you mentioned, hence why I've resisted
>putting "system" into the draft's or the module's name.  Admittedly,
>the draft's abstract/intro currently say "system", which should
>probably be removed.
>
>> "Generic keystore mechanism" perhaps.
>
>Perhaps, or just "keystore" with some more words around its
>common uses, kind of like how Acee's key-chain draft says that
>it's commonly used in routing protocols.
>
>> I note that the charter does say 'asymmetric' which I think needs
>> saying and also adding to the I-D; and I do think that the Netconf
>> I-D should recognise the existence of other I-Ds relating to the
>> storage of  keys, although that detail is not a matter for the
>> charter.
>
>The draft currently says "private keys", which a veiled reference
>to asymmetric keys.  It certainly can say this more overtly.
>
>The draft used to have some words regarding the key-chain draft,
>but Acee didn't think such sections were useful and so I took it
>out in the most recent version.  If we add something back in now,
>it would be along the lines of how the key-chain module is
>specialized for a narrow purpose, while the keystore module is
>useful in several contexts.

That would be fine. I have added ³applications using symmetric keys² to
the Abstract and Introduction of the key-chain draft. While one could
conceivably use key-chains for other purposes, I fully believe there are
much more straight-forward ways to model keys and/or other security
objects required for these usages. I don¹t see key-chains ever evolving
to
more than exactly as the Abstract describes them:

   This document describes the key chain YANG data model.  A key chain
   is a list of elements each containing a key string, send lifetime,
   accept lifetime, and algorithm (authentication or encryption).  By
   properly overlapping the send and accept lifetimes of multiple key
   chain elements, key strings and algorithms may be gracefully updated.
   By representing them in a YANG data model, key distribution can be
   automated.  Key chains are commonly used for routing protocol
   authentication and other applications requiring symmetric keys.  In
   some applications, the protocols do not use the key chain element key
   directly, but rather a key derivation function is used to derive a
   short-lived key from the key chain element key (e.g., the Master Keys
   used in the TCP Authentication Option(TCP-AO)).

<tp>

Yes, I like all key references to say either symmetric key or asymmetric
key, such as 'the private key of an asymmetric key pair' a comment which
I will make on the Netconf list for the Netconf I-D.

For the rtgwg I-D, I would like you to reorder the Abstract to make its
applicability clearer for the casual reader, to whit,

NEW
 This document describes the key chain YANG data model.
 Key chains are commonly used for routing protocol
   authentication and other applications requiring symmetric keys.
A key chain
   is a list of elements each containing a key string, send lifetime,
   accept lifetime, and algorithm (authentication or encryption).  By
   properly overlapping the send and accept lifetimes of multiple key
   chain elements, key strings and algorithms may be gracefully updated.
   By representing them in a YANG data model, key distribution can be
   automated.
In
   some applications, the protocols do not use the key chain element key
   directly, but rather a key derivation function is used to derive a
   short-lived key from the key chain element key (e.g., the Master Keys
   used in the TCP Authentication Option(TCP-AO)).

as I have implied on the Netconf list, the current layout has me reading
the first five sentences and thinking that this is an all-embracing key
related model, then I get to sentence six and think, well, I am confused
now.  Putting that sentence about routing protocols earlier would leave
me less confused.

Tom Petch
The only augmentations I¹d envision would be additional algorithms and
potentially other key attributes. Of course, one can never fully predict
the future.

Thanks,
Acee



>
>
>Kent
>
>