Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

From: Jeff Tantsura <[email-masked]>
Date: Tue, 21 Mar 2017 04:21:41 -0700

Tom,

Including RTGWG, the draft-ietf-rtgwg-yang-key-chain home.
In general, there’s no interactions, rtgwg-yang-key-chain work has been focused on data model for routing protocols key-chain’s configuration and management.

Thanks!
 
Cheers,
Jeff

On 3/21/17, 03:08, "Netconf on behalf of t.petch" <[email-masked] on behalf of [email-masked]> wrote:

    What interaction, if any, is there between
    
    draft-ietf-rtgwg-yang-key-chain-15.txt
    This document describes the key chain YANG data model.
    file "[email-masked]"
    
    currently in IETF Last Call, and
    
    draft-ietf-netconf-system-keychain-00
    This document defines a YANG data module for a system-level keychain
    mechanism
    file "[email-masked]"
    
    ?
    
    Tom Petch

    ----- Original Message -----
    From: "Mehmet Ersue" <[email-masked]>
    To: "'Benoit Claise'" <[email-masked]>; "'Susan Hares'"
    <[email-masked]>
    Sent: Monday, March 20, 2017 4:32 PM
    
    > Dear All,
    >
    >
    >
    > based on the recent discussion and proposals please find below the
    updated
    > charter proposal for NETCONF WG.
    >
    > Please comment before March 24, 2017.
    >
    >
    > Following Benoit's support the I2RS-related additions have been added
    as a
    > separated item.
    >
    > Being dependent on netmod-revised-datastores point 6 and 7 have been
    defined
    > as a goal without a deadline.
    >
    >
    > Mehmet
    >
    >
    > Network Configuration (netconf)
    >
    > -------------------------------
    >
    >
    >
    > Charter
    >
    >
    >
    > Current Status: Active
    >
    >
    >
    > Chairs:
    >
    >      Mahesh Jethanandani <[email-masked]>
    >
    >     Mehmet Ersue <[email-masked]>
    >
    >
    >
    > Operations and Management Area Directors:
    >
    >      Benoit Claise <[email-masked]>
    >
    >      Joel Jaeggli <[email-masked]>
    >
    >
    >
    > Operations and Management Area Advisor:
    >
    >      Benoit Claise <[email-masked]>
    >
    >
    >
    > Mailing Lists:
    >
    >      General Discussion: [email-masked]
    >
    >      To Subscribe:    https://www.ietf.org/mailman/listinfo/netconf
    >
    >      Archive:
    <https://mailarchive.ietf.org/arch/browse/netconf/>
    > https://mailarchive.ietf.org/arch/browse/netconf/
    >
    >
    >
    > Description of Working Group:
    >
    >
    >
    >   Configuration of networks of devices has become a critical
    requirement
    >
    >   for operators in today's highly interconnected networks. Large and
    >
    >   small operators alike have developed their own mechanisms or have
    used
    >
    >   vendor specific mechanisms to transfer configuration data to and
    from
    >
    >   a device and to examine device state information which may impact
    the
    >
    >   configuration. Each of these mechanisms may be different in various
    >
    >   aspects, such as session establishment, user authentication,
    >
    >   configuration data exchange, and error responses.
    >
    >
    >
    >   The NETCONF protocol (RFC 6241) provides mechanisms to install,
    >
    >   manipulate, and delete the configuration of network devices. NETCONF
    >
    >   is based on the secure transport (SSH is mandatory to implement
    while
    >
    >   TLS is an optional transport). The NETCONF protocol is data modeling
    >
    >   language independent, but YANG (RFC 7950) is the recommended NETCONF
    >
    >   modeling language, which introduces advanced language features for
    >
    >   configuration management.
    >
    >
    >
    >   NETCONF WG recently finalized the development of RESTCONF protocol
    >
    >   (RFC 8040) which provides an interface over HTTPs for accessing data
    >
    >   defined in YANG. RESTCONF is based on the capabilities and uses the
    >
    >   datastore concept defined in the NETCONF protocol specification. In
    >
    >   support of RESTCONF the YANG-Patch (RFC 8072) mechanism has been
    >
    >   provided for applying patches to configuration datastores. The YANG
    >
    >   Module Library (RFC 7895) provides information about all YANG
    modules
    >
    >   used by a network management server.
    >
    >
    >
    >   Last but not least NETCONF and RESTCONF Call Home (RFC 8071) have
    been
    >
    >   developed, which enable a server to initiate a secure connection to
    a
    >
    >   NETCONF or RESTCONF client respectively.
    >
    >
    >
    >   In the current phase of NETCONF's incremental development the
    >
    >   workgroup will focus on following items:
    >
    >
    >
    >   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.
    >
    >   Based on the known dependencies this draft has the highest priority
    >
    >   for the WG.
    >
    >
    >
    >   2. Finalize Server and Client Configuration YANG modules for both
    >
    >   NETCONF and RESTCONF as well as the Client and Server Models for SSH
    >
    >   and TLS.
    >
    >
    >
    >   3. Finalize the Zero-touch provisioning for NETCONF or
    RESTCONF-based
    >
    >   Management as a technique to establish a secure network management
    >
    >   relationship between a newly delivered network device configured
    with
    >
    >   just its factory default settings, and the Network Management
    System)
    >
    >
    >
    >   4. Provide a revised version of RFC 6536 (NETCONF Access Control
    >
    >   Model) by adding support for RESTCONF and the YANG 1.1. constructs
    >
    >   like "action" and the "notification" statements.
    >
    >
    >
    >   5. Provide a set of documents enabling advanced notification/
    >
    >   subscription capabilities, which gracefully co-exist in a deployment
    >
    >   of RFC 5277. The new capabilities include e.g. transport
    independence,
    >
    >   multiple dynamic and configured subscriptions in a transport
    >
    >   session. RFC 5277 will be obsoleted in parallel to the publication
    of
    >
    >   the new document set. Following specifications will be addressed:
    >
    >    - Protocol-neutral notification framework, i.e., explaining the
    >
    >      concepts of subscriptions, filters, subscription state
    >
    >      notifications, replay, etc. and defining the associated YANG data
    >
    >      model, RPCs, etc.
    >
    >    - Definition of notifications sent over NETCONF and how YANG
    >
    >      notifications are encoded in XML and JSON. Include considerations
    >
    >      for parallel support / implementation compatibility with
    RFC-5277.
    >
    >    - Definition of notifications sent over RESTCONF and HTTP2 and how
    >
    >      YANG notifications are encoded in XML and JSON. Include specifics
    >
    >      of call-home and heartbeat for subscriptions.
    >
    >    - The subscription and push mechanism for YANG datastores allowing
    >
    >      subscriber applications to request updates from a YANG datastore.
    >
    >
    >
    >   6. Provide a revision for the NETCONF and RESTCONF protocols and the
    >
    >   used datastore framework building on the datastore concept in NETMOD
    >
    >   revised datastores work. Bug fixing will be done and potential
    >
    >   extensions will be added. Provide guidance on how to adapt and use
    >
    >   YANG with NETCONF and RESCONF protocols. NETCONF XML Encoding Rules
    >
    >   from RFC 7950 will be moved to RFC6241bis.
    >
    >
    >
    >   7. Define capabilities for NETCONF and RESTCONF to support I2RS
    protocol
    >
    >   and ephemeral state datastore requirements.
    >
    >
    >
    >   Based on the implementation, deployment experience and inter-
    >
    >   operability testing, the WG aims to produce a NETCONF status report
    >
    >   in a later stage. The result may be clarifications for RFC6241 and
    >
    >   RFC6242 and addressing any reported errata.
    >
    >
    >
    >
    >
    > Goals and Milestones:
    >
    >   Done     Submit NETCONF/RESTCONF Call Home to AD/IESG for
    consideration as
    > Proposed Standard
    >
    >   Done     Submit YANG Library to AD/IESG for consideration as
    Proposed
    > Standard
    >
    >   Done     Submit RESTCONF to AD/IESG for consideration as Proposed
    Standard
    >
    >   Done     Submit YANG Patch to AD/IESG for consideration as Proposed
    > Standard
    >
    >
    >
    >   May 2017  WGLC for Zero-touch configuration mechanism
    >
    >   Jun 2017  Submit Zero-touch configuration to AD/IESG for
    consideration as
    > Proposed Standard
    >
    >   May 2017  WGLC for system-level keystore mechanism
    >
    >   Jun 2017  Submit keystore mechanism to AD/IESG for consideration as
    > Proposed Standard
    >
    >   May 2017  WGLC for Server and Client models for NETCONF and RESTCONF
    >
    >   Jun 2017  Submit Server and Client Configuration models to AD/IESG
    for
    > consideration as Proposed Standard
    >
    >   May 2017  WGLC for Client and Server Models for SSH and TLS
    >
    >   Jun 2017  Submit Client and Server Models for SSH and TLS to AD/IESG
    for
    > consideration as Proposed Standard
    >
    >   Jun 2017  WGLC for RFC 6536bis (NETCONF Access Control Model)
    >
    >   Jul 2017  Submit RFC 6536bis to AD/IESG for consideration as
    Proposed
    > Standard
    >
    >   Jun 2017  WGLC for advanced Notification/Subscription specifications
    >
    >   Jul 2017  Submit Notification/Subscription specifications to AD/IESG
    for
    > consideration as Proposed Standard
    >
    >
    >
    >
    >
    > From: Benoit Claise [mailto:[email-masked]]
    > Sent: Friday, March 17, 2017 4:49 PM
    > To: Kent Watsen <[email-masked]>; Mehmet Ersue
    <[email-masked]>;
    > 'Susan Hares' <[email-masked]>; 'Andy Bierman' <[email-masked]>
    > Cc: 'Netconf' <[email-masked]>
    >
    >
    >
    > On 3/8/2017 12:57 AM, Kent Watsen wrote:
    >
    > I agree with Mehmet, any changes to the NC/RC protocols should be done
    in
    > the NETCONF WG.
    > +1.
    > Regards, Benoit
    
    <snip>

    _______________________________________________
    Netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 21 Mar 2017 14:22:40 +0000

Tom,
If you read the two drafts and look at the data nodes in the two models,
you¹ll quickly realize that they have entirely different purposes.
Thanks,
Acee 

On 3/21/17, 7:21 AM, "rtgwg on behalf of Jeff Tantsura"
<[email-masked] on behalf of [email-masked]> wrote:

>In general, there¹s no interactions, rtgwg-yang-key-chain work has been
>focused on data model for routing protocols key-chain¹s configuration and
>management.
>
>Thanks!
> 
>Cheers,
>Jeff
>
>On 3/21/17, 03:08, "Netconf on behalf of t.petch"
><[email-masked] on behalf of [email-masked]> wrote:
>
>rtgwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtgwg

---

From: t.petch <[email-masked]>
Date: Fri, 24 Mar 2017 10:24:16 +0000

Acee

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

Tom Petch

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

Hi Kent, Tom, et al,

On 3/23/17, 4:40 PM, "Kent Watsen" <[email-masked]> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 24 Mar 2017 12:46:36 +0000

Hi Tom, 

>   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