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

From: Alan Luchuk <[email-masked]>
Date: Mon, 26 Sep 2011 09:25:14 -0400 (EDT)

Hello,

Is an update to RFC 5539 (NETCONF over TLS) available, and, if so, where 
might the update be found?  I saw the flurry of discussion about this topic
that took place on the NETCONF WG mailing list in late May 2011, but have
not found any indication that the issues discussed were resolved, or that
an update to RFC 5539 was produced.

Thanks in advance.

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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Sep 2011 15:45:27 +0200

> an update to RFC 5539 was produced.

I don't think there is such a document yet. I would, however, be
interested - primarily from the background of constrained devices
where having SSH is expensive if TLS is already available (to secure
other protocols).

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

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 26 Sep 2011 15:56:12 +0200

Hi All,

there was no substantial result from the discussion in May, 
which would lead to an update of the standard document.
I would like to encourage everybody to contribute if there 
is any concrete idea to improve RFC 5539.

Cheers, 
Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> ext Juergen Schoenwaelder
> Sent: Monday, September 26, 2011 3:45 PM
> To: Alan Luchuk
> Cc: [email-masked]
> Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539)
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Sep 2011 11:36:00 -0700

Ideally there would be a standard for how to extract an identity from a client certificate, but since there isn't (and since it's out of scope for us to define one), it seems that we should either adopt 5953 language to produce a NetConf username or move this RFC off the standards-track.

K.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, September 26, 2011 9:56 AM
To: Juergen Schoenwaelder; Alan Luchuk
Cc: [email-masked]
Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539)

Hi All,

Cheers, 
Mehmet 

Behalf Of

---

From: Badra <[email-masked]>
Date: Tue, 27 Sep 2011 10:14:47 +0400

Hi,

Juergen already proposed two options during last May: "RFC 4741bis needs to
provide this functionality by allowing transports to supply (ordered?) sets
of usernames or the TLS transport has to figure out how to select the one
and only username"

I thing RFC6141 didn't say anything about that issue (Juergen, please
correct me if I am wrong), and the only way is to figure out how to select
one and only one username. If the certificate contains a single
subjectAltName, that is fine, we extract it. Else,  if you have more than
one, you shall specify which one you would extract, the first? the last?
Moreover, if you have non-empty subject distinguished name field, would be
enough to extract its value and set it as the user identity?

Would you please elaborate more to see how we can adopt 5953 language to
resolve the above problem?

P.S. Most of the current standards that run applications over TLS (such as
HTTP over TLS or EAP-TLS) defines a common way to extract the an identity
from a client certificate.

Best regards,
Badra

On Mon, Sep 26, 2011 at 10:36 PM, Kent Watsen <[email-masked]> wrote:

>
> Ideally there would be a standard for how to extract an identity from a
> client certificate, but since there isn't (and since it's out of scope for
> us to define one), it seems that we should either adopt 5953 language to
> produce a NetConf username or move this RFC off the standards-track.
>
> K.
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Sep 2011 11:33:29 +0200

On Mon, Sep 26, 2011 at 11:36:00AM -0700, Kent Watsen wrote:
> 
> Ideally there would be a standard for how to extract an identity
> from a client certificate, but since there isn't (and since it's out
> of scope for us to define one), it seems that we should either adopt
> 5953 language to produce a NetConf username or move this RFC off the
> standards-track.

Yes, it is a pitty that the TLS folks just do not close this hole. And
I am sure once they do address this, they will come up with something
slightly different...

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Sep 2011 11:45:29 +0200

> enough to extract its value and set it as the user identity?

I guess you mean RFC 6241. Yes, this document just says the transport
mappings need to define how a username is provided:

   [...] The username is a string of characters that match
   the "Char" production from Section 2.2 of [W3C.REC-xml-20001006].
   The algorithm used to derive the username is transport protocol
   specific and in addition specific to the authentication mechanism
   used by the transport protocol.  The transport protocol MUST provide
   a username to be used by the other NETCONF layers.

This essentially means that all the transports need to be updated at
some point in time to define how a username is provided.

> resolve the above problem?

There is text on how to map a certificate's subjectAltName or
CommonName components to a tmSecurityName, or to map a certificate's
fingerprint value to a directly specified tmSecurityName. Now, a
tmSecurityName is not exactly having the same restrictions as a
NETCONF username.

What I am interested in is a solution that in addition can work with
pre-shared keys on devices that do not have the resources to engage in
certificate exchanges.
 
> from a client certificate.

Can you point to the revelant sections in the RFCs?

/js

---

From: Badra <[email-masked]>
Date: Tue, 27 Sep 2011 14:05:07 +0400

> pre-shared keys on devices that do not have the resources to engage in

Currently RFC5539 only specifies Certificate-based authentication!

> Can you point to the revelant sections in the RFCs?

Please see RFC 5216 section 5.2 and RFC 2818 Section 3

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Sep 2011 12:18:34 +0200

> Please see RFC 5216 section 5.2 and RFC 2818 Section 3

Well, RFC 2818 section 3.2 says:

3.2.  Client Identity

   Typically, the server has no external knowledge of what the client's
   identity ought to be and so checks (other than that the client has a
   certificate chain rooted in an appropriate CA) are not possible. If a
   server has such knowledge (typically from some source external to
   HTTP or TLS) it SHOULD check the identity as described above.

This is kind of handwaving, no?

/js

---

From: Badra <[email-masked]>
Date: Tue, 27 Sep 2011 14:58:26 +0400

> This is kind of handwaving, no?
Please read Section 3.1

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Sep 2011 13:57:42 +0200

> > This is kind of handwaving, no?

But that section is about how a web client checks the identity claimed
by an HTTP over TLS server. And even though 3.2 refers vaguely to 3.1,
it seems 3.1 really talks about server host names, that is, it is
pretty much server identity specific. I still believe RFC 2818 is
not very helpful for us.

/js

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Sep 2011 14:04:49 +0200

---- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Kent Watsen" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 27, 2011 11:33 AM
> I am sure once they do address this, they will come up with something

Juergen

It wasn't TLS that came up with that ... RFC6125, assuming that that is 
what you had in mind, but the Applications Area, and it emerged
late in the day that they would like everyone to start from a service name,
for use in XMPP, SIP and such like, giving that RFC a very narrow
focus.  Traditional protocols, like ours, were never on their radar.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Sep 2011 07:59:55 -0700

>>>>> On Mon, 26 Sep 2011 11:36:00 -0700, Kent Watsen <[email-masked]> said:

KW> Ideally there would be a standard for how to extract an identity
KW> from a client certificate, but since there isn't (and since it's out
KW> of scope for us to define one), it seems that we should either adopt
KW> 5953 language to produce a NetConf username or move this RFC off the
KW> standards-track.

That's not quite the problem.  A client certificate has an identity: the
certificate.  The TLS and corresponding X.509 protocols give you an
identity.  It tells you that "this client certificate has shown that it,
indeed, is on the other side of the connection".

The problem is that people and software being configured really don't
want a big bunch of gobbledygook printed to their log file (imagine
syslog entries saying "XXX connected to the IMAP server" where XXX was a
full certificate in ASCII-DER-Dump format.  Unfortunately, that is
*actually* happening.  The certificate is the identity connecting.

The text in 5953 (which is now 6353, by the way) was written
specifically because an entire certificate really doesn't fit in the 32
character restriction imposed by the access control system.  A mapping
had to be done or the system wouldn't work.  Humans need a mapping too,
because the certificate itself is really not that recognizable in its
complete form.  Humans need something shorter.

But the reality is that you *can't* shorten a certificate down to
something human-readable or, at least, uniquely named for a
configuration field *without losing something* (hence the word
"shortening").  When you try and shorten a complete certificate and you
ditch some of the elements in it you don't think you care about, you end
up with naming collision issues.

With a complete certificate in all its full-length glory, you're
positive that for someone or something on the other side to use that
certificate successfully they must have the private half.  It's very
very convincing (cryptographically).  But...  when you try to find a
word somewhere in the middle of the certificate (say "Dave") that you
can use, because you really don't want to care about the rest of the
gobbledygook, you invariably put yourself in trouble: it's quite easy to
create another certificate that has the word "Dave" in it in the exact
same spot.  Suddenly you now have two separate identities that you've
accidentally given the permissions for "Dave" too when you really only
meant to give them one set of different permissions each.

So to state that "there should be a standard for how to extract an
identity from a client certificate" is problematic in itself, because
you *can't* extract a simple-string identity without loosing a very
important part: the proof bits.  And without the proof bits, your
shortened identity is suddenly subject to naming collisions.
Its not *too* bad if you only have one root-CA as a trust anchor.  The
instant you adopt 2 you'd better know what you're doing.

The language, and techniques, in 6353 is designed to do a few things to
minimize the impact of the shortening.  First and foremost, the wording
was designed to state what happens when you have more than one trust
anchor.  The system is flexible enough to let you do stupid things,
because sometimes "doing the right things" can't be done without
allowing for "the stupid things" to be possible as well.  In reality, if
I'd had a choice, I'd have used the full certificate as the identity.
Or maybe just a (good) fingerprint of it.  But that's not really
people-friendly (nor VACM friendly).

Tread carefully, but have fun.

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Sep 2011 08:19:23 +0200

> *actually* happening.  The certificate is the identity connecting.

[...]
 
> people-friendly (nor VACM friendly).

So the bottom line is that we need a mapping of the client identity
(that is client certificates or fingerprints of them) to a human
friendly string.  That is just more config and NETCONF was designed
for that. ;-) The question is whether we envision a NETCONF specific
solution or a more general configuration module for X.509 certs.

That said, I like to have support also for constrained devices that
just do pre-shared key TLS.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 28 Sep 2011 09:03:17 +0200

On 9/28/11 8:19 AM, Juergen Schoenwaelder wrote:
> for that.;-)  The question is whether we envision a NETCONF specific

Sounds like that might be a generic YANG module then, no?

Bert

---

From: Badra <[email-masked]>
Date: Wed, 28 Sep 2011 11:07:29 +0400

> just do pre-shared key TLS.

I also support adding PSK, and the mapping is trivial in that case, by using
the psk_identity

Best regards
Badra

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Sep 2011 06:59:24 -0700

> Sounds like that might be a generic YANG module then, no?

Correct, if we go the route of the device needing to be configured to know how to extract a NetConf username from a client certificate, then a YANG module would be good.   But I still wonder how many are using TLS/SOAP/BEEP and the need to keep these RFCs standard?

> That said, I like to have support also for constrained devices 
> that just do pre-shared key TLS.

Supporting pre-shared keys may introduce a new username-identification problem - without passing a client certificate, how would the device know which user it is?  - a global/default user   Defining a YANG module for a generic user (even if just a partial mapping) could be slippery.  Would we also then define a model for pre-shared SSH RSA/DSA keys?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Sep 2011 18:13:58 +0200

On Wed, Sep 28, 2011 at 06:59:24AM -0700, Kent Watsen wrote:
> Correct, if we go the route of the device needing to be configured
> to know how to extract a NetConf username from a client certificate,
> then a YANG module would be good.  But I still wonder how many are
> using TLS/SOAP/BEEP and the need to keep these RFCs standard?

I think there is a case for TLS on low-end devices that do not happen
to have SSH and where adding SSH would be expensive. Will NETCONF (or
NETCONF light) get traction on such devices, I do not know.
 
> Supporting pre-shared keys may introduce a new
> username-identification problem - without passing a client
> certificate, how would the device know which user it is?

I think the TLS pre-shared key extension takes care of this, but I am
not an expert.

> a global/default user Defining a YANG module for a generic user
> (even if just a partial mapping) could be slippery.  Would we also
> then define a model for pre-shared SSH RSA/DSA keys?

I think pre-shared SSH RSA/DSA keys are different from TLS pre-shared
keys. I believe it is common practice that people copy public SSH keys
to boxes in order to enable access to whoever holds the private key.
At least we like to do this. ;-) It would not be bad if there would be
a common standard for this and perhaps the NETMOD system model covers
this, see <draft-bierman-netmod-system-mgmt-00.txt>.

/js

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 29 Sep 2011 10:17:57 +0200

>> using TLS/SOAP/BEEP and the need to keep these RFCs standard?

Here's one data point from the BBWF 2011, yesterday in Paris. One of my colleagues were there and summarized a conversation with a NEP:

"Interesting conversation with [----]. It seems that [----] had introduced Netconf themselves, over SOAP, for their [----] product line. He said they were not that satisfied with it, claimed that using Netconf over SOAP removed the benefits of SOAP and web services and they had decided to drop it."

Seems to me there is a risk that keeping old and rarely used specs could hurt the NETCONF adoption.

/jan
--
Jan Lindblad, [email-masked], +46 702855728
Principal Solutions Architect, Tail-f Systems, www.tail-f.com