Subject: [Netconf] review of draft-badra-netconf-rfc5539bis-01

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2012 13:57:23 +0200 (CEST)

Hi,

Here are my comments on draft-badra-netconf-rfc5539bis-01:

o  3.2
  
  OLD:

   The server MUST verify the identity of the client to ensure that the
   incoming client request is legitimate before any configuration or
   state data is sent to or received from the client.

  NEW:

   The server MUST verify the identity of the client to ensure that the
   incoming client request is legitimate before the NETCONF session is
   started.

o  3.2.1

    The NETCONF server MAY
    use any of the following algorithms to produce the NETCONF username
    from the certificate presented by the NETCONF client:

  This sounds as the server also may use some other algorithm?

o  3.2.1.1

    If a locally held copy of a trusted CA certificate is configured in
    the transformation container,

  What is "the transformation container"?

    and that CA certificate was used to
    validate the path to the presented certificate, then the NETCONF
    server SHOULD use that list entry in the transformation container.

  What should the server use that list entry for?   And since this is
  a SHOULD, it seems it doesn't have to use it?  During which
  circumstances can it choose not to use it?

o  3.2.1.2

    If the selected pre-shared keys match and the key is
    valid, then the client is authenticated and the NETCONF username
    associated with the PSK identity.

  Bad sentence.

o  3.2.1.2

    For details on how the PSK
    identity MAY be encoded in UTF-8, see section 5.1. of RFC [RFC6241].

  Wrong reference.

o  YANG module

  The YANG module is not valid:

  ietf-netconf-tls.yang:376: error: prefix "nacm" is not defined (reported only once)

o  data model

    leaf certificate-to-username-transform-count {

    leaf certificate-to-username-transform-last-changed {

  Are these leafs really necessary...?

o  container certificate-to-username-transforms

      This
      is done by considering each active list entry from this container
      in prioritized order according to its index value. 

  s/active//

o  container certificate-to-username-transforms

             The NETCONF server requires only a single container
             entry to configure this behavior.

   s/container entry/list entry/

o  list certificate-to-username-transform

  Instead of using an integer key, I suggest you use an ordered-by
  user list with an arbitratry string as key.   This use case is why
  ordered-by user lists exist.

o leaf map-type {

  Instead of enumerating all different combinations, I suggest you use
  an ordered-by user leaf-list.  Also, I think the following structure
  would be more natural:

    choice map-type {
      leaf specified {
        type nacm:user-name-type;  // note the new type
        // replaces your "data" leaf
      }
      leaf-list from-certificate {
        type enumeration {
          enum rfc822Name;
          enum dNSName;
          enum ipAddress;
        }
        ordered-by user;
      }
    }

  Then you can use for example:

    <specified>bob</specified>

  or

    <from-certificate>dnsName</from-certificate>
    <from-certificate>rfc822Name</from-certificate>

o  container psk-map

  I suggest you align the name of this container with the other
  container.  Currently you have:

     +--rw certificate-to-username-transforms
     +--rw psk-map

  Also, you should have a sinlge top-level container with a
  descriptive name, under which you can stuff these two containers.

o     leaf valid-not-before {
      leaf valid-not-after {

  Why are these needed?

o  features

  Do you expect that all implementations of this document implement
  both certs and psk?   If not, consider adding features.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Mar 2012 17:17:51 +0200

>      +--rw certificate-to-username-transforms

Yang written by different people. ;-) I liked shorter names... 
 
> o     leaf valid-not-before {

The idea is that you can provision multiple keys that are valid for
different time spans.

>   both certs and psk?   If not, consider adding features.

Good point. Our code will likely only do psk for any time soon.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2012 23:33:01 +0200 (CEST)

> The idea is that you can provision multiple keys that are valid for

So why is this important for this particular use case?  Why not for
certs?  passwords and keys in the system module?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Mar 2012 23:47:36 +0200

> certs?  passwords and keys in the system module?

Certs include this information in the cert.

SSH keys are usually (correct me if I am wrong) not time limited.

Operating system accounts may be time limited (the whole account) as
well as the passwords on some systems. But so far, my understanding
was that in this space we focus on basic things that are common across
platforms.

/js