Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539)

From: Alan Luchuk <[email-masked]>
Date: Fri, 30 Sep 2011 10:29:40 -0400 (EDT)

Hello,

>The fingerprint described in RFC 5425 would be more than enough for our
>case.
>
>Our issue is when multiple subjectAltNames are presented in the
>certificate. Shall we exporte all of them to the NETCONF message layer. No,
>simply because RFC6241 doens't provide that service to the transport.
>
>We shall then define our order when exporting the SubjectAltName fields.
>Consider we agreed on assigning the order on the following types
>1= dNSName
>2=rfc822Name
>3= iPAddress
>
>(I believe we shall limit our set of acceptable SubjectAltName to the above
>three types)
>
>Suppose the order is 1, 2, 3
>
>If 1 is set, we extract only 1,
>ElseIf 2 is set, we extract 2,
>ElseIf if 3 is set we extract 3
>Else, drop the TLS session
>
>Once we agree on the order, I can extend the above algorithm and define
>a loop iterating over the set a set of SubjectAltName. This may be useful if
>we want to find a match in any of the exported subjectAltNames.
>
>P.S. In RFC 6353, the use of CommonName field is NOT deprecated, whereas we
>agreed on not recommend this usage here.
>
>Best regards,
>Badra

I can align with this suggestion, but I have no clue how generally useful 
it would be to NETCONF over TLS users.  Because I think alot of really 
experienced people already discussed mapping certificates to security
names when RFC 6353 was developed, I consider the mechanism proposed in 
RFC 6353 is likely useful to the NETCONF over TLS user community as well.  
Thus, for a proposed standard, my _preference_ would be to implement 
something similar to RFC 6353 in NETCONF over TLS.

In RFC 6353, for each configured fingerprint, there is another configu-
ration parameter that specifies:

-  Map the fingerprint to a specific security name (the interim solution);
-  Choose any specific one of the subjectAltName fields above;
-  Check all three of the subjectAltName fields above, and check them
   in the priority order of rfc822Name, dNSName, iPAddress;
-  Choose the CommonName field (because the CommonName portion of the
   Subject field is deprecated, perhaps this should NOT be included
   in NETCONF over TLS.)

I would propose using this model in NETCONF, and adding at least one 
additional choice to the list:

-  Check all three of the subjectAltName fields above, and check them
   in the priority order of dNSName, rfc822Name, iPAddress, to satisfy
   your envisioned need described above;

I think that another pretty important feature from RFC 6353 is the ability 
to specify the fingerprint of one of the CA certificates in the trust chain.  
This way, for example, all of the certificates signed by the CA for the
Network Management group would be mapped the same way, without requiring
explicit mappings for each certificate issued to each member of the
Network Management group.

(It's been awhile since I worked with or thoroughly read RFC 6353, so
someone please jump in and correct any technical errors.)

Using these features from RFC 6353, all foreseen possible mappings from
certificates to NETCONF over TLS usernames could be covered.  The NETCONF
over TLS users could choose the scheme that works best in their deployment;
they would not be constrained by a more restricted scheme specified by
the NETCONF over TLS specification developers.

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: Badra <[email-masked]>
Date: Fri, 30 Sep 2011 19:05:06 +0200

> the NETCONF over TLS specification developers.
Dear Alan,

I think this is what we do need.
How  does RFC 6353 deal when certificates include multiple instances of the
subjectAltName (refer to Wes example, multiple rfc822Names)?

Best regards
Badra

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 Sep 2011 10:59:36 -0700

>>>>> On Fri, 30 Sep 2011 19:05:06 +0200, Badra <[email-masked]> said:

B> How does RFC 6353 deal when certificates include multiple instances
B> of the subjectAltName (refer to Wes example, multiple rfc822Names)?

First hit wins.
-- 
Wes Hardaker
SPARTA, Inc.