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

From: Kent Watsen <[email-masked]>
Date: Tue, 3 Apr 2012 15:34:18 -0700

Hi Alan,

Delayed response, but hopefully still helpful

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

That addresses the ambiguity issue, but is it OK?  I mean, what happens if by bad luck the device is multi-homed and the ipAddress or dnsName facing the NETCONF server happens to not be the first listed?  - it is possible, right?  Maybe not very likely though...  It think it's OK, assuming the probability is near zero.  To Wes's point, it certainly good to have cross-protocol equality when possible...

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

The first paragraph reads much better - thanks!

But I feel there are a number of unanswered questions from my paragraph above.  Stated another way, I still don't understand how to implement it.

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

Looks good, thanks

>The suggestions sound reasonable.  How about changing the typedef and
>YANG object to:
>
> typedef tls-fingerprint-type {
>   type binary {
>     length "1..255";
>   }

Better now that min-length has been bumped from '0' to '1'

>>Regarding "certificate-to-username-transform-count"... 
>>Regarding "certificate-to-username-transform-last-changed"...
>
> 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.  

If they're not referenced, then I don't believe they have any value and thus imagine they should be removed.

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

Matching RFC 6353 is good - thanks for pointing that out

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

To resolve the ambiguity question, yes, thanks

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

I understood that part.  When I said "see an example", I meant regarding how the cert chain is passed.  Let's say we have an Issuer called myTrustedCA, that signs a cert for someUnknownCA, that signs someUserCert.  The device is configured to trust myTrustedCA and the client logging in presents someUserCert - how can the device allow this connection is the cert chain isn't passed?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Apr 2012 09:52:45 +0200

> Better now that min-length has been bumped from '0' to '1'

I had a discussion about this with Martin. While SNMP adds the byte
identifying the has algorithm to the hash value so that updates are
atomic, I think in a YANG world this looks kind of awkward. I would
rather see something like this in a config representation:

  <fingerprint>
    <sha1>de:ad:...:be:ef</sha1>
  </fingerprint>

Most tools that compute fingerprints do not seem to produce the format
with the embedded code for the hash algorithm. To achieve the above,
we would need an IANA controlled grouping such that we achieve crypto
agility.

> If they're not referenced, then I don't believe they have any value and thus imagine they should be removed.

The last one we do not really need since we have config change
notifications (in case someone is interested to be notified). The
counter - well not really essential either; I guess I prefer to keep
this data model config true only.

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