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

["Acee Lindem (acee)" <[e-mail]>]

Hi Tom, 

On 3/24/17, 6:24 AM, "t.petch" <[e-mail]> wrote:

>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)).

Thanks Tom - I agree that this is a better clearer organization of the
Abstract and Introduction. This will be in the update I post next week.

Thanks,
Acee 



>
>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
>>
>>
>