Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication

From: Alan Luchuk <[email-masked]>
Date: Mon, 3 Nov 2014 14:04:00 -0500 (EST)

Hello,

Kent, Tom, thanks for the helpful feedback.

kw>I'm not sure if adding more sections or more words is needed - maybe this
kw>is a case where less is more?   Maybe we *only* need to 1) state that
kw>server authentication MUST be via PKIX as defined in RFCs 5280 and 6125
kw>and 2) state anything not already covered by RFCs 5280 and 6125.

I agree that less can be more, and that it is unproductive to duplicate 
text when a reference to existing text might be satisfactory.  That said, 
are you suggesting:

1)  Keep the existing section 2.4.1 text;

2)  Replace the existing section 2.4.1 text with something much briefer 
    that simply references RFCs 5280 and 6125; or

3)  Refine the proposed text to make it briefer?

The intent for the proposed replacement text for section 2.4.1 was to 
clarify the existing text in section 2.4.1, to address:

tpetch>I think that this still needs a tweak.
tpetch>
tpetch>In s.2.4.1, the sentence
tpetch>"If
tpetch>   the NETCONF client has external information as to the expected
tpetch>   identity of the NETCONF server, the hostname check MAY be omitted.
tpetch>"
tpetch>has been moved, to be immediately after the comment about performing
tpetch>certificate validation as per RFC5280.  Which does not make good sense
tpetch>since RFC5280 is not about hostname checks.  The sentence used to come
tpetch>after the references to RFC6125 which is about hostnames and so made
tpetch>more sense.
tpetch>
tpetch>But more fundamentally, I am unclear what this is saying.  'hostname
tpetch>check' does not appear anywhere else.  There is talk of matching but I
tpetch>am unclear if that is intended.  As it stands, the sentence would seem
tpetch>to say, get a certificate and then ignore its contents, in which case, I
tpetch>think that an example, or list, of suitable conditions needs to be there
tpetch>alongside the sentence, whereever the sentence is.

tpetch> To tell the truth, I find the section still confusing. There are too
tpetch> many MUST and MAYs interacting here. I also see that the second
tpetch> paragraph says MUST ask for user confirmation or terminate the
tpetch> connection. This also seems to conflict with the notion of

I think the proposed section 2.4.1 should be revised if necessary and 
kept because it states clearly:

-  that NETCONF clients using TLS must verify the server's identity;
-  that alternate verification mechanisms are acceptable; and
-  What happens if the identity verificatioN CHeck fails.

The proposed new section 2.4.2 resulted from what seemed like a logical
split of the replacement text for the original section 2.4.1.  It attempts
to clarify statements in original section 2.4.1 such as:

  "by the server to determine if it meets the client's expectations.  If
   the NETCONF client has external information as to the expected
   identity of the NETCONF server, the hostname check MAY be omitted."

I can align with any NETCONF WG consensus about the proposed replacement 
sections being unhelpful, too verbose, or need revision or deletion.

kw>Also, I noticed that you didn't touch the original section 2.4.2. (Client
kw>Identity).   This is the section that is currently missing a statements
kw>along the lines of:
kw>  - the client MUST present a X.509 certificate
kw>  - the client MAY also present a chain of intermediate certs to a trust
kw>anchor the server is expected to trust
kw>  - the server MUST authenticate the client's certificate
kw>  - the server MAY authenticate the client's certificate using PKIX to a
kw>configured trust anchor
kw>  - the server MAY authenticate the client's certificate if it's an exact
kw>match to a previously trusted client certificate.

Yes.  Partly this omission was to address rfc5539bis-06 one section at a 
time, and partly to leave the section as-is to address the comment:

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

The idea was to have rfc5539bis simply say that the NETCONF server 
derives a NETCONF username from the X.509 certificate presented by
the client.  Draft-ietf-netconf-server-model would define one possible
mechanism for deriving the NETCONF username from the X.509 certificate.

If it is the WG's consensus that the existing sections 2.4.2/2.4.3 from
rfc5539bis-06 need work, I can massage the bullet points you suggested
into replacement text.

tpetch>I am unclear on what you are proposing
tpetch>
tpetch>For me, there is a clear split between the validation of  X.509
tpetch>certificates and  the use then made of the contents thereof, 
tpetch>something which I do not see in the paragraphs you propose.

I hope this E-mail answers these and at least explains the reason for 
the omission.  Is understanding the mechanism for deriving NETCONF 
usernames from X.509 certs the primary problem you see with 
rfc5539bis-06?

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: Wed, 5 Nov 2014 10:34:46 +0000

----- Original Message -----
From: "Alan Luchuk" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, November 03, 2014 7:04 PM

<SNIP>

> usernames from X.509 certs the primary problem you see with

No.  I am reasonably comfortable with that having been through it before
for SNMP and RFC5539.  It is what comes earlier (or should do in my
model).

First, being clear that we are only covering X.509 certificates.  I
referred to this vaguely, Kent gave chapter and verse of text in
5539bis-06 which still hints at other things, so I need to see an I-D
that makes (or doesn't) those changes (and yes, I have to wait at least
for the window to open).  This to me has been the biggest stumbling
block.

Second, I want to separate the certificate validation as a distinct
step.  It seems wrong, perhaps a breach of security, to talk of what to
do with the contents before checking that the certificate is valid and
here I refer to RFC5280, not to RFC6125.  As I said, RFC5539 does a good
job, I would just like that paragraph first, it seems the only sequence
to make sense.  If validation may consist of checking against pre-stored
certificates, then I would count that as part of this step as RFC5539
does.

Third comes the RFC6125 step (or variants thereon since that RFC is so
HTTP focussed).  We have a valid certificate but is it a relevant one,
does it match, for some sense of that word, the party we are trying to
set up a TLS channel with?

Then, at last, we can get on with determining a user id to use with
NETCONF.

I am looking for that sort of structure and find it hard to discern.
And yes, I agree, less is often more, when we can assume a certain
familiarity with existing concepts and standards in the mind of the
reader.

Tom Petch