Subject: Re: [Netconf] rfc5539bis

From: Alan Luchuk <[email-masked]>
Date: Mon, 20 Oct 2014 10:58:05 -0400 (EDT)

Hello,

Related to RFC 5539bis and NETCONF over TLS using X.509 certificates, the
intent was to largely reuse the mechanisms described in RFC 6353 for
generating SNMP security names from X.509 certificates.  Devising a new 
and different scheme for NETCONF over TLS seems unproductive.  For those 
who may be unfamiliar with RFC 6353, the basic ideas are summarized below.  

In RFC 6353, both ends mutually authenticate.  This assures the server
of the identity of who wishes to manipulate the management information.
It assures the client of the identity of the server for which it wishes
to manipulate the management information.

Both ends use X.509 certificate path validation to verify the integrity
of the application certificate presented by its peer.  

The server uses three additional steps to control the access to the 
management information:

S1)  The application certificate presented by the client must be 
     recognized by the server;

S2)  The application certificate presented by the client must be 
     transformable by the server to a valid security name; and

S3)  The resulting security name must be authorized to access 
     management information.

The client uses an additional step to verify the identity of the server
for which it wishes to manipulate the management information:

C1)  The application certificate presented by the client must be recognized
     by the server; -or-

C2)  Some piece of identifying information bound within the application 
     certificate must match what the client is expecting.

To implement item S1, the fingerprint of the received application 
certificate must be preconfigured in a table of recognized certificates.  
To implement item S2, the table of recognized certificates must specify
a transformation to a valid security name.  To implement item S3, the 
security name generated from the transformation must be allowed access
to the management information.

To implement item C1, the fingerprint of the application certificate 
the client expects to receive from the server must be be known to the 
client _before_ the connection is attempted.  If the fingerprint does
not match the fingerprint the client expects, then the connection is
failed.

To implement item C2, the piece of identifying information the client 
expects to receive from the server must be be known to the client 
_before_ the connection is attempted.  If the piece of identifying 
information does not match the client expects, then the connection is 
failed.  Typically this identifying information is something like the
DNS name(s) or IP address(es) of the server.

Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 luchuk at snmp.com        Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------

---

From: t.petch <[email-masked]>
Date: Tue, 21 Oct 2014 15:35:44 +0100

----- Original Message -----
From: "Alan Luchuk" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 20, 2014 3:58 PM
> who may be unfamiliar with RFC 6353, the basic ideas are summarized
below.

Alan

I broadly agree, once we have decided what forms of authentication
NETCONF over TLS will use.

If that is only X.509 certificates, then the next question is where to
put the text about it.  SNMP has the data model integral with the
procedural specification, NETCONF does not, so it is likely that the
protocol goes into rfc5539bis but what you then do with it goes into
netconf-server, for the server, and into ???, for the client.  Which, as
Juergen pointed out, is not ideal but is probably the best we can do.

And NETCONF has not specified access control in the same way as SNMP has
done so that will be different too.

So I broadly agree with you but do want that agreement on what
authentication is valid before going further - I like to progress one
step at a time.

Tom Petch

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Oct 2014 17:34:55 +0200

> authentication is valid before going further - I like to progress one

RFC 5539 has used X.509 certificates and nobody seems to request any
changes. Why do you make this complicated?

Yes, NC access control is different from SNMP access control but this
is irrelevant. All the transport has to deliver is a user name. Why do
we have to make this complicated?

/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: Kent Watsen <[email-masked]>
Date: Wed, 22 Oct 2014 18:29:35 +0000

>we have to make this complicated?

I kind of agree with both sides.

On one hand, 5539bis-06 clearly intends to define mutual certificate-based
authentication - just search for the word "mutual".  Additionally, Juergen
already explained that he put PSK in (-02, according to the change log )
to support NETCONF-light, and since took it out.  So we're essentially
back to just trying to clean up 5539 and make it be in-line with NETCONF
1.1. 

On the other hand, there are a couple issues with 5539bis-06:

1) section 2.4.2 (Client Identity) doesn't actually say that
certificate-based authentication is required.  For instance, this text
from RFC5539 was left out: "with certificate-based authentication
according to local policy"

2) I'm confused by these seemingly conflicting statements:

  - section 2.4 (X.509-based Authentication...) says "Implementations MAY
optionally
    support TLS certificate-based authentication"
  - section 2.5 (Cipher Suites) says "However, implementations MUST
support TLS 1.2".

So, to Juergen's point, I don't think this needs to be complicated, but I
do think we need to be methodical about ensuring the text says what we
want it to say.

One last point, I'm opposed to 5539bis using
draft-ietf-netconf-server-model as a Normative Reference.  I believe that
5539bis should define the protocol on its own, and view
draft-ietf-netconf-server-model as just one data-model that could
configure it.  FWIW, neither 6242 nor draft-ietf-netconf-call-home have a
Normative Reference draft-ietf-netconf-server-model.

Thanks,
Kent

---

From: t.petch <[email-masked]>
Date: Thu, 23 Oct 2014 10:04:00 +0100

---- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>; "t.
petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 22, 2014 7:29 PM

On one hand, 5539bis-06 clearly intends to define mutual
certificate-based
authentication - just search for the word "mutual".  Additionally,
Juergen
already explained that he put PSK in (-02, according to the change log )
to support NETCONF-light, and since took it out.  So we're essentially
back to just trying to clean up 5539 and make it be in-line with NETCONF
1.1.

  - section 2.4 (X.509-based Authentication...) says "Implementations
MAY
optionally
    support TLS certificate-based authentication"
  - section 2.5 (Cipher Suites) says "However, implementations MUST
support TLS 1.2".

So, to Juergen's point, I don't think this needs to be complicated, but
I
do think we need to be methodical about ensuring the text says what we
want it to say.

<tp>

Kent

This is what I keep saying or at least, try to say - not sure how clear
I am being.  But until those loose ends of text are removed, then
5539bis remains ambiguous IMHO (and I then remain reluctant to move on
to other issues and other I-Ds).

I would go slightly further and change the title and Intro.  Martin
raised the point about this I-D seeming to exclude other forms of
authentication with TLS so I would entitle this one

" Using the NETCONF Protocol over Transport Layer Security (TLS) with
X.509 Certificates"

Then anyone is free to write another I-D entitled
" Using the NETCONF Protocol over Transport Layer Security (TLS) with
PAKE"
or
" Using the NETCONF Protocol over Transport Layer Security (TLS) with
PSK"
etc etc

That leaves us free to be as 'MUST' as we like about authentication,
because our use case is simple.

I want to see a fresh I-D along these lines - but see below ...

</tp>

One last point, I'm opposed to 5539bis using
draft-ietf-netconf-server-model as a Normative Reference.  I believe
that
5539bis should define the protocol on its own, and view
draft-ietf-netconf-server-model as just one data-model that could
configure it.  FWIW, neither 6242 nor draft-ietf-netconf-call-home have
a
Normative Reference draft-ietf-netconf-server-model.

<tp>
suive ... There is another issue in here.  RFC6241 mandates
"The authentication process MUST result in an authenticated client
identity whose permissions are known to the server."
which suggests we should say something about how. 5539bis did have text
about this but that is now in server-model.  Which sort of leads to
having a normative dependency of 5539bis on server-model, not for
configuration reasons but for the algorithm used to extract an
authenticated client identity from what information the server has
gotten..

But I do see this as a separate, more debatable issue, to be discussed
once there is clarity in the published I-D about the use of
certificates.  And I do think that the document structure is right, that
is, how to extract the identity does belong in server-model and not in
TLS or SSH or other transport I-Ds.

Tom Petch

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Oct 2014 15:55:42 +0100

Hi,

the editor does not understand the edits since I do not see clear
agreement of the scope of the document and thus there won't be a new
version before the cutoff. It makes a major difference to me
whether the document is 

- NC over TLS with mutual X.509 authentication

or

- NC over TLS plus a structure to plug in new authentication
  mechanisms

and it is not clear whether

- we details the algorithm to extract a username out of an X.509
  certificate in this spec

or

- leave it to the server configuration model.

If fact, we would be duplicating some elements from RFC 6353 and the
reusable YANG grouping is in draft-ietf-netmod-snmp-cfg-08 (yes, an
interesting dependency chain results from that).

I think the WG needs to sort out what set of documents is wanted
before making further edits.

/js

---

From: t.petch <[email-masked]>
Date: Thu, 30 Oct 2014 09:13:47 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Cc: "Kent Watsen" <[email-masked]>; <[email-masked]>
Sent: Monday, October 27, 2014 2:55 PM
> - NC over TLS plus a structure to plug in new authentication

I think that limiting this I-D to mutual X.509 authentication resolves
the issues that have been raised.

Juergen commented on the mix of MAY, MUST etc causing confusion and that
becomes simpler when there is just one approach to be specified.

Martin commented on not knowing what to do about other forms of
authentication - well, keep them out of this I-D and let anyone who
wants to produce a separate I-D thereon.  After all, the specification
of TLS, and of SSH, is littered with I-Ds adding new forms of
authentication so that would be nothing new.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Thu, 30 Oct 2014 11:28:51 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Cc: "Kent Watsen" <[email-masked]>; <[email-masked]>
Sent: Monday, October 27, 2014 2:55 PM

> - leave it to the server configuration model.

I think that the right place for this is in the server configuration
model.

Alan made the point that he wanted to keep this in line with SNMP, and
that is exactly what this would do.  SNMP puts the details in the MIB
DESCRIPTION so the parallel would be to put it in the YANG model.

And it means we will ultimately have it in just the one place, as
opposed to having parallel and perhaps different definitions for TLS
and, e.g., SSH.

Tom Petch