Subject: Re: [Netconf] Comments on draft-badra-netconf-rfc5539bis-02.txt

From: Alan Luchuk <[email-masked]>
Date: Mon, 24 Sep 2012 13:21:06 -0400 (EDT)

Hello,

I've deleted the text for nested replies to items that probably do not
need further discussion.

>Alan Luchuk <[email-masked]> wrote:
>
>> > o  3.2.1.2
>> > 
>> >   OLD:
>> > 
>> >    On the server side, this PSK identity is used to look up the key 
>> >    corresponding to the presented PSK identity.  
>> > 
>> >    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.
>> >
>> 
>> Proposed new text:
>> 
>>    On the server side, this PSK identity is used to look up the key 
>>    corresponding to the PSK identity presented by the client.
>>    The server iterates through the psk list in the psk-map container in
>>    the ietf-netconf-tls YANG module.  It searches for a psk list entry 
>>    with a psk-identity leaf that matches the PSK identity presented by 
>>    the client.  If the server finds a matching entry, and the pre-shared 
>>    keys match, then this authenticates the client.  The server uses the 
>>    value from the user-name leaf in the psk list as the NETCONF username.
>>    If the server cannot find a psk-identity leaf that matches the PSK 
>>    identity presented by the client, or if the pre-shared keys do not
>>    match, then the server terminates the connection.
>
>Since the 'psk-identity' is the key in the 'psk', I think the text
>about iterating and matching is confusing.  It makes it sound as if
>there are potentially multiple matching entries.  I suggest:
>
>    On the server side, this PSK identity is used to look up an
>    entry in the psk list.  If such an entry is found, and the pre-shared 
>    keys match, then the client is authenticated.  The server uses the 
>    value from the user-name leaf in the psk list as the NETCONF username.
>    If the server cannot find an entry in the psk list, or if the
>    pre-shared keys do not match, then the server terminates the
>    connection.

Sounds good.

>>         NETCONF messages over it.
>> 
>>         Non-consecutive values of index are acceptable and implementations
>>         should continue to the next highest numbered cert-map list entry.  
>>         It is recommended that administrators skip index values to leave 
>>         room for the insertion of future list entries (for example, use 
>>         values of 10 and 20 when creating initial list entries).
>> 
>>         Security administrators are encouraged to make use of certificates
>>         with subjectAltName fields that can be used as NETCONF usernames
>>         so that a single root CA certificate can allow all child
>>         certificate's subjectAltName to map directly to a NETCONF
>>         usernames via a 1:1 transformation.";
>
>Ok, but see below.
>
>I also beleive that anvert-map entry must have a fingerprint, right?
>If so, the choice should be mandatory:
>
>    container fingerprint {
>      choice algorithm-and-hash {
>        mandatory true;
>        ...

Good point.

Not sure, but I think the map-type from the cert-map entry, and the 
psk-identity, user-name, and key from the psk-map all should be 
mandatory as well.

>
>
>> > o  YANG module
>> >
>> > 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>
>> 
>> I prefer to leave the YANG objects as proposed.
>
>Can you provide some motivation for this?  To me, this looks like a
>rather direct translation from a MIB structure (which the document
>also says it is).  

That's pretty much the reason.  I prefer making the newer standard 
similar to the existing standard to ease the transition to the newer 
standard.

>I (pyang) also found a syntax error in the current version of the
>module:
>
> revision "2012-09-13" {
>   description
>     "rename host-part to domain-part in the description of RFC822".
>
>The '.' above should be ';'.

Thanks.  Another revision statement should probably be added as well.

Regards,
--Alan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2012 19:41:38 +0200

> similar to the existing standard to ease the transition to the newer 

I think it is most important that we do here is consistent with
what will be in draft-ietf-netmod-snmp-cfg.

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