Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames

From: Alan Luchuk <[email-masked]>
Date: Tue, 1 Nov 2011 14:24:42 -0400 (EDT)

Hello,

Thanks for the comments.  The comments are helpful, and most have been 
addressed in the updated draft.  Hopefully the updated text clarifies 
and strengthens the proposal.

>From: "Randy Presuhn" <[email-masked]>
>To: <[email-masked]>
>Date: Thu, 27 Oct 2011 10:50:22 -0700
>Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames
>
>
>> Additionally, the NETCONF protocol [RFC6241] requires that the 
>> transport protocol's authentication process MUST result in an 
>> authenticated client identity whose permissions are known to the 
>> server.  The authenticated identity of a client is commonly 
>> referred to as the NETCONF username.  Thus, an algorithm for 
>> transforming certificates to NETCONF usernames is needed.
>
>I think someone else has already commented on how the "MUST"
>here is a bit odd. 
><complex sentence alert>
>Is it attempting to say that
>it is impossible
>for the permissions
>of an authenticated client identity
>to *not* be known
>to the server?
></complex sentence alert>

This text above was copied, with slight changes, from RFC 6241, Section 
2.2.  I left it unchanged in the latest update.

>> The algorithm for deriving NETCONF usernames from TLS certificates
>> is patterned after the algorithm for deriving tmSecurityNames from
>> TLS certificates specified in Transport Layer Security (TLS) 
>> Transport Model for the Simple Network Management Protocol (SNMP)
>> [RFC6353].  RFC6353 specifies that an SNMP engine must implement
>> several algorithms for transforming a certificate to a tmSecurityName, 
>> and lets the SNMP engine deployer choose and configure the algorithm 
>> most suitable for the deployer's environment.
>
>Recapping RFC6353 does be helpful, but it's more important to answer the
>question of what *this* specification requires.  All this paragraph says is
>"patterned after", which means "similar but likely different", and the
>paragraph does not spell out what the differences are.

OK.  The second sentence of the paragraph has been replaced.  The
updated paragraph now reads:

    The algorithm for deriving NETCONF usernames from TLS certificates
    is patterned after the algorithm for deriving tmSecurityNames from
    TLS certificates specified in Transport Layer Security (TLS)
    Transport Model for the Simple Network Management Protocol (SNMP)
    [RFC6353].  Both RFC 6353 and this document require several
    different algorithms for deriving usernames from TLS certificates,
    and allow the security administrator to choose and deploy the
    algorithm that works best in his environment.

> 
>> When a NETCONF server accepts a TLS connection from a NETCONF client, 
>> the NETCONF server must produce a NETCONF username from the certificate 
>> presented by the NETCONF client.  The NETCONF server may use any of 
>> the following algorithms to produce the NETCONF username from the 
>> certificate presented by the NETCONF client:
>
>Is the use of "must" and "may deliberate?  I think what you mean is:
>  When a NETCONF server accepts a TLS connection from a NETCONF client, 
>  the NETCONF server attempts to derive a NETCONF username from the 
>  certificate presented by the NETCONF client.  The NETCONF server MAY 
>  use any of the following algorithms to produce the NETCONF username 
>  from the certificate presented by the NETCONF client:

Yes, your suggested text captures the intent.  The updated paragraph reads:

    When a NETCONF server accepts a TLS connection from a NETCONF client,
    the NETCONF server attempts to derive a NETCONF username from the
    certificate presented by the NETCONF client.  If the NETCONF server
    cannot derive a valid NETCONF username from the client's presented
    certificate, then the NETCONF server MUST close the TLS connection,
    and MUST NOT accept NETCONF messages over it.  The NETCONF server MAY
    use any of the following algorithms to produce the NETCONF username
    from the certificate presented by the NETCONF client:

>
>> -  Map a certificate directly to a NETCONF username;
>
>What transforms are permitted in this mapping?

The updated text reads:

    -  Map a certificate directly to a specified, pre-configured,
       NETCONF username;

>> -  Examine the subjectAltName's rfc822Name, dnsName, and iPAddress
>>    fields in a pre-defined order, then use the first matching
>>    subjectAltName value.  
>
>"matching" what?

The updated text reads:

    -  Examine the subjectAltName's rfc822Name, dnsName, and iPAddress
       fields in a pre-defined order.  Return the value from the first
       subjectAltName field that is examined, defined, and populated
       with a non-empty value.  If no subjectAltName field of a specific
       type is defined, then the examination skips that field and proceeds
       to examine the next field type.  If a subjectAltName field is
       defined, but the value is not populated, or is populated by an
       empty value, then the examination skips that field and proceeds
       to examine the next field type.

>> The NETCONF server MUST implement all of these algorithms, and 
>> allow the deployer to choose and configure the algorithm used.
>
>"and configure" - are there additional inputs to any of these algorithms?
>If so, they need to be spelled out.
>
>> The problem with using the entire certificates as the identity is 
>> that they are difficult for people to use.  It is generally accepted 
>> that a fingerprint of a certificate is not likely to come up with a 
>> collision against a fingerprint of another (different) certificate.  
>> Thus, assuming a good hash algorithm, using fingerprints is a safe 
>> way to compare two certificates.
>
>"Compare" is the wrong word.  I'd suggest replacing the last phrase
>with "a fingerprint can be a safe short-hand for identifying a certificate."

Done.  The updated text reads:

    Thus, assuming a good hash algorithm, a fingerprint can be a safe
    short-hand for identifying a certificate.

>I would recommend that someone actually do the math to figure out
>what a "safe" fingerprint size would be.  Since this would be used for
>configuration, interoperability is a concern, so the fingerprint algorithm
>needs to be spelled out.

I'm not a crypto-guru, but I trust  1) the crypto-gurus already know what
"safe" fingerprint sizes are;  2) the safe fingerprint sizes vary depending 
upon the hash algorithm;  3) crypto-tools and libraries return fingerprints
of "safe" sizes.

If more needs to be said here, I'm open to suggested text.  

>> If if a locally held copy of a trusted CA certificate is configured
>> in 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.  
>> All presented certificates validated by the configured CA certificate 
>> will be transformed to NETCONF usernames using the same transformation 
>> algorithm.
>
>This paragraph is just plain baffling in context.  It sounds like it presumes
>a bunch of stuff spelled out in the Yang.

Agreed.  The important content of this paragraph also appears in the 
YANG module, so I deleted it from here.

>
>...
>>   leaf certificate-to-username-transform-count {
>>     type yang:gauge32;
>>     description
>>       "A count of the number of certificate-to-username-transforms.";
>>     config false;
>>   }
>
>Why is this needed?
>
>>   leaf certificate-to-username-transform-last-changed {
>>     type yang:date-and-time;
>>     description
>>       "The date and time when the certificate-to-username-transforms
>>        was last modified through any means.  The value 0 means the
>>        certificate-to-username-transforms has not been modified since
>>        the NETCONF server was started.";
>>     config false;
>>   }
>
>Why is this needed?  If it's there for the reason I think it's there, limiting it
>to "since the NETCONF server was started" defeats the purpose.

Fixed.  Deleted the certificate-to-username-transform-count, and updated
the certificate-to-username-transform-last-changed description.

>>        NETCONF username to identify with the remote connection.  This
>
>perhaps s/identify/associate/

Done.

>>        is done by considering each active list entry from this container 
>>        in prioritized order according to its index value.
>>        Each list entry's certificate-fingerprint value determines
>>        whether the list entry is a match for the incoming connection:
>> 
>>            1) If the list entry's certificate-fingerprint value
>>               identifies the presented certificate, then consider the
>
>s/identifies/matches that of/

Done.

>>            2) If the list entry's certificate-fingerprint value
>>               identifies a locally held copy of a trusted CA
>
>s/identifies/matches that of/

Done.

>
>>               certificate and that CA certificate was used to
>>               validate the path to the presented certificate, then
>>               consider the list entry as a successful match.
>
>This seems just a bit odd.  Why should CAs be treated as NETCONF users?

Added the second paragraph of text to clarify the intent.  The section
now reads:

    2) If the list entry's certificate-fingerprint value
       matches that of a locally held copy of a trusted CA
       certificate, and that CA certificate was used to
       validate the path to the presented certificate, then
       consider the list entry as a successful match.

       This feature lets the NETCONF server derive NETCONF
       usernames from all certificates signed by the trusted
       CA certificate.  The NETCONF server will derive all
       NETCONF usernames using the same derivation algorithm.
       The NETCONF server requires only a single container
       entry to configure this behavior.

>>        Once a matching list entry has been found, the NETCONF server uses 
>>        the map-type value to determine how the NETCONF username associated 
>>        with the session should be determined.  See the map-type column's
>
>General note - is "column" the preferred terminology here and elsewhere?
>It sounds rather MIB-ish.

Changed "column" to "leaf" throughout.

>>        If no matching and valid list entry can be found, the connection MUST
>>        be closed and NETCONF messages MUST NOT be accepted over it.
>
>This seems quite reasonable, but contradicts the statement from above
>"Additionally, the NETCONF protocol [RFC6241] requires that the 
>transport protocol's authentication process MUST result in an 
>authenticated client identity whose permissions are known to the 
>server."

I left this as-is.  I think the intent is clear.  If others think a 
different behavior would be better, I think the options are:

-  Terminate the connection if no valid NETCONF username can be produced;
-  Continue the connection with an invalid NETCONF username;
-  Produce a default NETCONF username;
-  Others?

>>        Missing values of index are acceptable and implementations 
>
>How can the value of index be missing?  It's a key, with a simple integer range.

Changed "missing" to "non-consecutive."

>>        recommended that administrators skip index values to leave room 
>
>Do you mean "RECOMMENDED"?

Not sure this recommendation is as strong as "RECOMMENDED" in RFC 2119.
I left it lowercase, but have no preference, if anyone believes it should
be upper case.

>>        Users are encouraged to make use of certificates with
>
>By "users" do you mean "security administrators"?

Yes.  Thanks.  Changed "Users" to "Security administrators".

>>       leaf data {
>>         type string {
>>           length "1..max";
>>         }
>>         description
>>           "Auxiliary data used as optional configuration information for
>>           a given mapping specified by the map-type column.  Only some 
>>           mapping systems will make use of this column.  The value in this 
>>           column MUST be ignored for any mapping type that does not require 
>>           data present in this column.";
>
>What does "MUST be ignored" mean?  During get-config?  During edit-config?

Changed the text of the second sentence to read:

          When the NETCONF server derives the NETCONF username from the 
          client's presented certificate, the value in this leaf MUST be 
          ignored for any mapping type that does not require data present 
          in this column.

>
>...
>> Implementations may optionally support TLS Pre-Shared Key (PSK)
>> authentication.  RFC 4279 describes pre-shared key ciphersuites for
>> TLS. During the TLS Handshake, the client indicates which key to use
>> by including a PSK identity in the TLS ClientKeyExchange message
>> [RFC4279]. On the server side, this PSK identity is used to lookup the
>
>s/lookup/look up/

Changed.

Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 [email-masked]           Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------