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

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Aug 2012 09:41:55 -0700 (PDT)

Hi,

Here are my comments on draft-badra-netconf-rfc5539bis-02.

Almost all of them are the same as my review of -01, but I never saw
any reply to them - except for a few that Juergen replied to and
fixed.

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 MUST implement the algorithms for deriving NETCONF
   usernames from presented certificates that are documented in the
   ietf-netconf-tls YANG module. 

  Add a forward reference, like:

   ietf-netconf-tls YANG module, defined in Section ??.

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?  Is
  this intentional?

o  3.2.1.1

   A client certificate has an identity: the certificate.  The TLS and
   corresponding protocols provide an identity.

  Did you mean "The TLS and corresponding protocols provides this
  identity"?  If not, please clarify.

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

   On the server side, this PSK
   identity is used to look up the key 

  Where?  I think this section needs to mention the data model nodes
  defined in the YANG module.

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:389: error: unexpected keyword "pattern"

  (pattern should be a substatement to string)

o  feature map-certificates

    "The :map-certificates capability implements mapping X.509
     certificates to NETCONF user names.";

  This is not a capability, and the ":" notation is confusing.

  NEW:

    "The map-certificates feature indicates that the server implements
     mapping X.509 certificates to NETCONF user names.";

 (ditto for map-pre-shared-keys)

o  container cert-mappings

  OLD:

     On an incoming TLS connection, the client's presented certificate
     MUST either be validated based on an established trust anchor, or
     it MUST directly match a fingerprint in this container.  This
     container does not provide any mechanisms for configuring the
     trust anchors;

  NEW:

     On an incoming TLS connection, the client's presented certificate
     MUST either be validated based on an established trust anchor, or
     it MUST directly match a fingerprint in the 'cert-map' list.  This
     module does not provide any mechanisms for configuring the
     trust anchors;

  The term "this container" is used several times in this text where
  the list 'cert-map' is meant.  Please check the text and rephrase.
   
     However, this container is
     flexible to allow for situations where existing deployed
     certificate infrastructures do not provide adequate subjectAltName
     values for use as NETCONF usernames."

  How is this flexibility done?  This needs to be clarified.

o  list cert-map

  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>

/martin