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

From: Alan Luchuk <[email-masked]>
Date: Thu, 29 Sep 2011 16:44:48 -0400 (EDT)

Hello,

>As WG chair, I would much more appreciate it if SNMP Research
>helps us define/document a potential solution that we can try
>to get consensus on and then standardize it.
>
>Certainly if you are doing a commercial implementation and so
>probably have customers who deploy it, such experience would
>be very helpful to try and work on a standardized solution.
>
>Bert

We'll be glad assist as we are able, and implement and test 
products from WG efforts.  That's why I posed the initial question 
about updates to RFC 5539; I was ready to implement and test them.  
However, after the late May 2011 WG discussion about updates to 
RFC 5539, we did not have anything useful to add to the discussion
that had not already been offered.

For the interim, a simple scheme to map certificate fingerprints to
NETCONF usernames is sufficient.  But for the longer term, as a 
standardized solution, I would look closely at RFC 6353 and see if 
its mechanisms could be adapted for use with NETCONF.  I have great
respect for the knowledge and experience of the team that developed 
RFC 6353, and believe RFC 6353's mechanism for mapping certificates 
is well-considered, flexible, and useful, in the "real world." 

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 13:32:13 +0200

> is well-considered, flexible, and useful, in the "real world."

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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 Sep 2011 07:03:00 -0700

>>>>> On Fri, 30 Sep 2011 13:32:13 +0200, Badra <[email-masked]> said:

B> We shall then define our order when exporting the SubjectAltName fields.
B> Consider we agreed on assigning the order on the following types
B> 1= dNSName
B> 2=rfc822Name
B> 3= iPAddress

B> (I believe we shall limit our set of acceptable SubjectAltName to the above
B> three types)

I hope you mean: "ignore the others" not "drop any certificate that
contains something else".  Also, make sure algorithm deals with
certificates that include multiple instances of the subjectAltName types
you want to use (eg, multiple rfc822Names).
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Badra <[email-masked]>
Date: Fri, 30 Sep 2011 19:02:22 +0200

> you want to use (eg, multiple rfc822Names).
The idea is to specify a set of parameters that would be extracted from the
certificate, any certificate that not contains at least one of these
parameters would be rejected.

Best regards
Badra