Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis

From: Alan Luchuk <[email-masked]>
Date: Mon, 12 Mar 2012 15:22:40 -0400 (EDT)

Hello,

>Section 3.2.1 - What happens if subjectAltName contains more than one 
>ipAddress, dnsName, or rfc822Name - as allowed by RFC 5280 section 4.2.1.6?

Only the first ipAddress, dnsName, or rfc822Name is used; subsequent ones
are ignored.  How about the following text (note the new paragraph)?

   o  Extract the subjectAltName's rfc822Name from the certificate, then
      use the extracted rfc822Name as the NETCONF username;

   o  Extract the subjectAltName's dnsName from the certificate, then
      use the extracted dnsName as the NETCONF username;

   o  Extract the subjectAltName's iPAddress from the certificate, then
      use the extracted iPAddress as the NETCONF username;

   o  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.

   If the subjectAltName contains more than one rfc822Name, dnsName, or 
   iPAddress, then only the first rfc822Name, dnsName, or iPAddress is
   extracted and used.  Subsequent rfc822Names, dnsNames, or iPAddresses
   are ignored.

   The NETCONF server MUST implement all of these algorithms, and allow
   the deployer to choose the algorithm used.  The certificate-to-
   username-transforms container in the ietf-netconf-tls YANG module
   specifies how a NETCONF server transforms a certificate into a
   NETCONF username.

>Section 3.2.1.1 - This whole section should be rewritten - it's hard to 
>follow as is.  I think there is an implicit assumption that the client's 
>certificate is trusted; that is, that the TLS layer would not have allowed 
>the connection if couldn't validate the certificate. Does this assumption 
>need to be stated explicitly?   Third paragraph is about being able to 
>apply transformation based on the identification of the issuing CA, a 
good idea, but shouldn't this be after exhausting all direct-match options. 
Lastly, what is a "transformation container"?

How about completely replacing the existing text in section 3.2.1.1 with 
the following text:

3.2.1.1.  Identifying a Certificate

   The ietf-netconf-tls YANG module identifies the TLS certificate by
   the "fingerprint" of the certificate presented by the peer.  The 
   certificate fingerprint is a string of octets composed of a 1-octet 
   hashing algorithm identifier followed by the results of the hashing 
   algorithm.  The 1-octet hashing algorithm identifier is encoded with 
   values taken from the IANA TLS HashAlgorithm Registry (RFC 5246).
   Implementations are not required to implement all of the hash
   algorithms listed in the IANA TLS HashAlgorithm Registry (RFC 5246).

   If a locally held copy of a trusted CA certificate is configured in
   the certificate-to-username-transforms container of the ietf-netconf-tls 
   YANG module, and that CA certificate was used to validate the path to 
   the presented certificate, then the NETCONF server SHOULD derive the
   NETCONF username from that entry in the certificate-to-username-transforms 
   container of the ietf-netconf-tls YANG module.  In this case, the same
   NETCONF username will be derived from all presented certificates 
   that have been validated by the CA certificate configured in the 
   certificate-to-username-transforms container of the ietf-netconf-tls 
   YANG module.

>Section 3.2.1.3:
>
>Regarding "description" - Is the second sentence redundant? "It specifies 
>how NETCONF servers transform X.509 certificates presented by clients into 
>NETCONF usernames.  It also specifies how NETCONF clients transform NETCONF 
>usernames into X.509 certificates for presentation to NETCONF servers."

Yes, the second sentence is redundent and should be deleted.  The text 
should read:

 description
   "This module applies to NETCONF over TLS.  It specifies how
    NETCONF servers transform X.509 certificates presented by
    clients into NETCONF usernames.

>Regarding "tls-fingerprint-type" - how can it be of length '0'?  - the last 
>paragraph says it's to support containers where the fingerprint may be 
>optional, but shouldn't those containers simply not specific "mandatory 
>true"?  The 2nd paragraph regards an encoding, does this mean that 
>implementations MUST support all the hash algorithms listed in IANA's 
>registry?
>
>Regarding certificate-fingerprint - why is the length on 
>"tls-fingerprint-type" further constrained?

The suggestions sound reasonable.  How about changing the typedef and
YANG object to:

 typedef tls-fingerprint-type {
   type binary {
     length "1..255";
   }
   description
     "A fingerprint value that can be used to uniquely reference
      other data of potentially arbitrary length.

      An tls-fingerprint-type value is composed of a 1-octet hashing
      algorithm identifier followed by the fingerprint value.  The
      octet value encoded is taken from the IANA TLS HashAlgorithm
      Registry (RFC 5246).  The remaining octets are filled using the
      results of the hashing algorithm.

      Implementations are not required to implement all of the hash
      algorithms listed in the IANA TLS HashAlgorithm Registry (RFC 5246).
 }

     leaf certificate-fingerprint {
       type tls-fingerprint-type;
       mandatory true;
       description
         "A cryptographic hash of a X.509 certificate.  The results of
          a successful matching fingerprint to either the trusted CA in
          the certificate validation path or to the certificate itself
          is dictated by the map-type leaf.";
     }

>Regarding "certificate-to-username-transform-count" - this type doesn't 
>seem to be referenced anywhere - remove it?
>
>Regarding "certificate-to-username-transform-last-changed" - this type 
>doesn't seem to be referenced anywhere - remove it?  Besides, why reset 
>the value to '0' just because the NetConf server restarted?

These are patterned after informational objects in the SNMP-TLS-TM-MIB.  
I have no strong preference whether or not these are retained in the 
YANG module.  Resetting the value to 0 is intended to allow implementation 
on devices that cannot keep time across reboots.  

>Regarding "certificate-to-username-transforms"
>  1) the statement "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."  is surprising - does this 
>     mean that the TLS server MUST be coded to allow connections having 
>     client certificates that cannot be authenticated at the TLS-level?  
>     I had assumed that this RFC was only proscribing how to extract an 
>     identity, but this proscribes an authentication strategy - is that 
>     right?

I think you understand correctly -- this is an OR choice.  This text is 
strongly patterned after the description clause of the snmpTlstmCertTo-
TSNTable on Page 41 of RFC 6353.  I have no preference about how this 
should work, but people with more security experience than I thought it 
was a useful idea for mapping certificates to usernames, so it was copied
in the ietf-netconf-tls YANG module.

>
>  2) the statement "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." - 
>     what is the "path"? - do you mean the certificate chain? - how does 
>     the server know this?  I need to see an example.  

I think the words "path" and "certificate chain" are used interchangably
in RFC 6353.  Would changing "path" to "certificate chain" be sufficient
here?  

The basic idea is that multiple certificates can easily be mapped to a 
single NETCONF username.  In some situations, this is conceptually easier 
and reduces the configuration of the certificate-to-username-transforms 
container.  

For example, let's say a network operations group has 10 network operators, 
each of which has a personal certificate that identifies a single operator.
Let's also say that the network operations group has a CA that signs these
personal certificates.  Rather than having to configure 10 individual 
certificate-to-username-transforms in a NETCONF server, one for each network
operator, a single certificate-to-username-transform could be configured
for the network operations CA certificate.  This single entry might be
mapped to the NETCONF username "NetworkOperator", and access rights granted
to this single NETCONF username.

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 13 Mar 2012 07:18:06 -0700

AL> Only the first ipAddress, dnsName, or rfc822Name is used; subsequent ones
AL> are ignored.  How about the following text (note the new paragraph)?

That's pretty much what we ended up doing in ISMS, and I certainly think
it's good to have cross-protocol equality when possible.

The only different is that for the case of searching for "Any":

   o  Examine the subjectAltName's rfc822Name, dnsName, and iPAddress
      fields in a pre-defined order.

you're not specifying what the pre-defined order is.  I assume that
really means that the user can pick between 1 of 6 or maybe 7 options?

  1) rfc822Name then dnsName then iPAddress
  2) dnsName then rfc822Name then iPAddress
  3) iPAddress then ...
  
and maybe:
  7) dnsName, rfc822Name, iPAddress always taking the first occurring.

For ISMS, we chose to do only #7 for the "any" case as anything else
meant a fair amount of complexity and it was less likely to help
interchangeability.
-- 
Wes Hardaker
SPARTA, Inc.