Subject: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06

From: t.petch <[email-masked]>
Date: Fri, 3 Oct 2014 11:45:32 +0100

I think that this still needs a tweak.

In s.2.4.1, the sentence
"If
   the NETCONF client has external information as to the expected
   identity of the NETCONF server, the hostname check MAY be omitted.
"
has been moved, to be immediately after the comment about performing
certificate validation as per RFC5280.  Which does not make good sense
since RFC5280 is not about hostname checks.  The sentence used to come
after the references to RFC6125 which is about hostnames and so made
more sense.

But more fundamentally, I am unclear what this is saying.  'hostname
check' does not appear anywhere else.  There is talk of matching but I
am unclear if that is intended.  As it stands, the sentence would seem
to say, get a certificate and then ignore its contents, in which case, I
think that an example, or list, of suitable conditions needs to be there
alongside the sentence, whereever the sentence is.

Separately, given the focus there has been on call home and the
different flavours thereof, I would like a sentence at the end of 2.1
pointing to the call-home document

Tom Petch

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 03 Oct 2014 14:14:44 +0200

Thanks Tom.

I am assuming that the authors/editors of the document will answer.

Anyone else who has an opinion, please chime in too if you like.

Bert (co-chair of NETCONF WG)

On 03/10/14 12:45, t.petch wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Oct 2014 08:16:37 +0200

> after the references to RFC6125 which is about hostnames and so made

To tell the truth, I find the section still confusing. There are too
many MUST and MAYs interacting here. I also see that the second
paragraph says MUST ask for user confirmation or terminate the
connection. This also seems to conflict with the notion of
'whitelisted' certificates (which I think the 'client has external
information as to the expected identity' boils down to). If you can
come up with a rewrite of section 2.4.1 that makes all of this simpler
and straight forward, this would actually be very much appreciated.

> alongside the sentence, whereever the sentence is.

No, it is not 'ignore its contents'. My understanding is you validate the
certificate but the contained in the ticket is not checked against the
expected hostname - instead you verify that the certificated is a known
one.

> pointing to the call-home document

I disagree with this. We have moved all the call-home stuff to a
different document and hence this transport specification should
really be silent about call home.

/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: t.petch <[email-masked]>
Date: Mon, 6 Oct 2014 14:29:42 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 06, 2014 7:16 AM
> and straight forward, this would actually be very much appreciated.

Juergen,

I too am confused. I can start with

" If the certificate presented by a NETCONF server has passed
   certification path validation [RFC5280] to a configured trust anchor,
   the NETCONF client MUST  examine the certificate presented
   by the server to verify that it meets the client's expectations.

   The NETCONF client SHOULD check its understanding of the
   NETCONF server hostname against the server's identity as presented in
   the server Certificate message, in order to prevent man-in-the-middle
   attacks.  This check is performed according to the rules and
guidelines   defined in [RFC6125].  If the check fails, the NETCONF
client MUST either ask for the user for confirmation that the
certificate is acceptable or terminate the connection with an indication
that  the NETCONF server's identity is suspect.

   The NETCONF client MAY have external information as to the expected
   identity of the NETCONF server, such as ....."

at which point, my understanding runs out

Tom Petch

---

From: t.petch <[email-masked]>
Date: Mon, 6 Oct 2014 15:23:34 +0100

I think that
draft-ietf-netconf-call-home
needs quite a lot of tweaking.

'TCP connection' I would like to see used throughout, rather than a mix
of
connection/session/stream

'element' is used extensively within Netconf but, AFAIK, always to refer
to a protocol element.  The two ends of Netconf are commonly client and
server, so I would like to see 'network element' eradicated from this
I-D (unless it is not applicable to the management of all the other
boxes that are currently managed:-)

There is no Introduction.  Commonly the Abstract serves as part or all
of the Introduction, and I think that that is needed here, before
Motivation

s.3 references section 3 which I think is section 2 until you add an
Introduction in which case it becomes section 3 once more.

s.4 /connection/underlying connection/ - connection on its own is
ambiguous

s.6 would be easier to comment on with more subsections

"Using this TCP connection, the NETCONF server immediately starts
      either the SSH-server or TLS-server protocol.  That is, the next
      message sent on the TCP stream is the initial message defined for
      these protocols, per [RFC4253] or [RFC5246]."
Odd wording.  For SSH there is a defined initial SSH server message, as
per RFC4253; for TLS, there is not - this paragraph could be read as
requiring the TLS server to send HelloRequest which I think wrong -
split the description of the two protocols.

"The NETCONF protocol proceeds normally for SSH and TLS, as defined
      in [RFC4253] and [RFC5539] respectively."
Odd wording.  The next step is the setting up of the secure SSH or TLS
channel which I think warrants a mention.  Once that is complete, then
RFC4253 is irrelevant - it is RFC6242 that matters

" The NETCONF client's perspective (e.g., the management system)"
e.g. or I.e. or omit altogether!

"  o  The NETCONF client listens for TCP connections on one or both of
  the IANA-assigned ports for NETCONF Call Home port (YYYY and/or
      ZZZZ)."
remove second port

"  o  Using this TCP connection, the NETCONF client immediately starts
      either the SSH-server or TLS-server protocol.  That is, the next
      message sent on the TCP stream is the initial message defined for
      these protocols, per xref target="RFC4253"/> or [RFC5246]. "
I would rather the NETCONF client started the client protocols, else we
are into a reverse call home:-)
The xref is awry but RFC4253 is appropriate here for SSH

"   o  The NETCONF protocol proceeds normally for SSH and TLS, as
defined in [RFC4253] and [RFC5539] respectively."
As before, we have moved beyond RFC4253 into RFC6242

Enough for the moment.  I would like to see this lot incorporated into a
fresh I-D (or rejected) before I carry on.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 10 Oct 2014 12:59:22 +0200 (CEST)

Hi,

I also find the first two pararaphs of 2.4.1 confusing.

Some additional comments:

2.4 says:

   Implementations MAY optionally support TLS certificate-based
   authentication [RFC5246].  If the implementation supports TLS
   certificate-based authentication, then the following sections
   apply.

Ok, so if my implementation does not support certificate-based
authentication, how is the NETCONF username derived?

-------------

The text in 2.4.2 doesn't make much sense on its own.  Maybe merge the
text in 2.4.3 into 2.4.2?

-------------

2.4.3 says:

   The NETCONF server uses the algorithm defined in
   [I-D.ietf-netconf-server-model] to extract a NETCONF username from
   the X.509 certificate presented by the NETCONF client.

is this a MUST, or is this one way to do this?

/martin

---

From: t.petch <[email-masked]>
Date: Fri, 10 Oct 2014 17:56:20 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 10, 2014 11:59 AM
> authentication, how is the NETCONF username derived?

Martin

We did have
"   Implementations MAY optionally support TLS Pre-Shared Key (PSK)
   authentication [RFC4279].  RFC4279 describes pre-shared key
   ciphersuites for TLS.  The description of the psk-maps container in
   the ietf-netconf-server YANG module, defined in
   [I-D.kwatsen-netconf-server], specifies how a NETCONF server
   associates a TLS pre-shared key with a NETCONF username."
as the only alternative to certificate based authentication so that was
covered.

I am unclear whether or not PSK is still a use case for NETCONF.

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Oct 2014 18:35:50 +0000

>I am unclear whether or not PSK is still a use case for NETCONF.

...and by "we did have", Tom means that PSK is no longer defined in the
current draft.

FWIW, the server-model has this data-model:

   module: ietf-netconf-server
      +--rw netconf-server
         +--rw tls-client-auth
            +--rw trusted-ca-certs
            |  +--rw trusted-ca-cert*   binary
            +--rw trusted-client-certs
            |  +--rw trusted-client-cert*   binary
            +--rw cert-maps {tls-map-certificates}?
            |  +--rw cert-to-name* [id]
            |     +--rw id             uint32
            |     +--rw fingerprint    x509c2n:tls-fingerprint
            |     +--rw map-type       identityref
            |     +--rw name           string
            +--rw psk-maps {tls-map-pre-shared-keys}?
               +--rw psk-map* [psk-identity]
                  +--rw psk-identity        string
                  +--rw user-name           nacm:user-name-type
                  +--rw not-valid-before?   yang:date-and-time
                  +--rw not-valid-after?    yang:date-and-time
                  +--rw key                 yang:hex-string

which will be extended by
https://github.com/netconf-wg/server-model/issues/4.

But there currently isn't much description about this data-model other
than in the "description" statements in the YANG module itself.  While I
agree that the server-model draft is missing a section under Section 2
(Objectives) (e.g., "Support SSH and TLS transports"), I also think that
5539bis needs to declare its requirements without making server-model a
Normative reference.

Just added https://github.com/netconf-wg/server-model/issues/14 to track
this.

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 10 Oct 2014 21:22:25 +0200 (CEST)

> ...and by "we did have", Tom means that PSK is no longer defined in the

Yes, I understand this.  But if the doc says that certificate-based
authentication is optional, it should at least also say that there
might be other auth mechanisms, out of the scope for this document.

> Just added https://github.com/netconf-wg/server-model/issues/14 to track

Hmm, so why does 5539bis talk about one auth mechanism but not the
other?

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Oct 2014 20:03:43 +0000

>Hmm, so why does 5539bis talk about one auth mechanism but not the

There is a sequencing issue, the server-model update came out before the
PSK info was removed from 5539bis.   If the intent is to remove support
for PSK, then the next update to server-model will remove it too.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Oct 2014 20:10:59 +0000

Hi Tom,

Thank you for your review!   Please see below for responses.

Thanks,
Kent

>connection/session/stream

Done

>boxes that are currently managed:-)

Mostly done.  I left the "network element" and "management system" terms
in the Motivation section, which refers to these roles independent of any
particular protocol.

>of the Introduction, and I think that that is needed here, before

Done

>Introduction in which case it becomes section 3 once more.

Done.

>Ambiguous

You are correct that it is an ambiguous statement.  But this is exactly
how it is written in RFC4253 and qualifying it may not be right.  How
about this instead?

   This document updates the SSH Transport Layer Protocol [RFC4253] only
   by removing the "The client initiates the connection" statement made
   in Section 4 (Connection Setup).  This document assumes that the
   reference to "connection" refers to the underlying transport
   connection (e.g., TCP).  Security implications related to this change
   are discussed in Security Considerations (Section 10).

>s.6 would be easier to comment on with more subsections

Done.  Actually, I wound up re-arranging the doc a little, to group things
more logically - please let me know if you like it.

>RFC4253 is irrelevant - it is RFC6242 that matters

Good catch - that was a copy/paste error, it was suppose to be RFC6242.

>e.g. or I.e. or omit altogether!

I omitted altogether, but beware that "e.g.," is proper syntax with the
comma...

>  the IANA-assigned ports for NETCONF Call Home port (YYYY and/or

Currently there is a port per transport, so we really do need two listed
here for now.

The potential to have a single "call-home" port is tracked by
https://github.com/netconf-wg/call-home/issues/4

>are into a reverse call home:-)

Fixed - another copy/paste error.

>As before, we have moved beyond RFC4253 into RFC6242

Same root-cause and fix as above.

>fresh I-D (or rejected) before I carry on.

Coming up!  ;)

Thanks again,
Kent

---

From: t.petch <[email-masked]>
Date: Tue, 14 Oct 2014 10:11:27 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, October 10, 2014 9:03 PM

<tp>
Which is the question I think we need to resolve first, after which
updates to the I-Ds will follow.

In a way it is unfortunate that RFC6241 says
"NETCONF connections MUST provide authentication, data integrity,
   confidentiality, and replay protection.  "
and
"   The authentication process MUST result in an authenticated client
   identity whose permissions are known to the server."
because that then means, to me, that rfc5539bis is obliged to say how,
and make it mandatory.

We could, simplistically, say that that means TLS client and server
certificates are mandatory, other options are for further study; or else
I think we have quite a bit of discussion, perhaps starting with PSK.

I think that here, we are going against the grain, in that TLS is
(almost) all about server authentication by certificate, and the issues
are which algorithms to use, and other forms of authentication, let
alone a prescribed method of client authentication (as opposed to an
application's RYO), get little attention.

Whatever, we have to solve this in order to progress this set of I-Ds.

Tom Petch

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Oct 2014 15:09:00 +0200

> application's RYO), get little attention.

RFC 5539 says both ends use a certificate. I assume this is the
default unless someone makes a clear proposal otherwise. Are you
making such a proposal? If not, lets go ahead with both ends use a
certificate.

I was pushing for PSK authentication back in a day when we did NC
light. I think it is meanwhile clear that NC light is not a viable
option and hence I proposed to remove PSK authentication at the
Toronto meeting as not many people seem to care to implement this
(slide #7 of my slide set). Perhaps the chairs should do an explicit
call for concensus on this so that we can move on.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Oct 2014 15:15:34 +0200 (CEST)

> making such a proposal? If not, lets go ahead with both ends use a

Do you want to say certificate-based auth is a MUST?  This seems to
imply that if someone someday wants to do PSK, that won't be possible.

The alternative is to define certificate-based auth as the only
current option, but open the spec for other auth mechanisms.  (this is
almost how the doc is written today...)

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 14 Oct 2014 15:45:56 +0200

Juergen, do we have an open issue on an issues list somewhere that we
can point to?
- it should describe the issue
- a proposed solution

We can then do a consensus call for the proposed solution

Maybe this is somewhere already in my email archives or in meeting notes,
but it would be good to have it listed as an issue that we can easily point to.

Thanks,
Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Oct 2014 20:47:21 +0200

> almost how the doc is written today...)

I believe we should allow for other authentication mechanisms (in
particular client authentication mechanism) to be defined in the
future. Hence, we should say that this document defines one possible
client authentication mechanism namely the use of certificates.

The real problem I personally have is that the algorithm to extract a
username from the cert is defined a path of about 3 references away
from this doucment. This creates and interesting dependency to other
documents. But this is not so much a technical issue but more an
organizational issue.

I have to read up on the documents coming out of the UTA working group
since ideally their work should simplify our work.  The problem is
that their BCP draft is the beginning of a longer recursive descent.

/js

---

From: Qin Wu <[email-masked]>
Date: Thu, 16 Oct 2014 09:13:02 +0000

-----邮件原件-----
发件人: Netconf [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2014年10月14日 21:09
收件人: t. petch
抄送: [email-masked]
主题: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06

On Tue, Oct 14, 2014 at 10:11:27AM +0100, t. petch wrote:
> (almost) all about server authentication by certificate, and the 
> issues are which algorithms to use, and other forms of authentication, 
> let alone a prescribed method of client authentication (as opposed to 
> an application's RYO), get little attention.
> 

RFC 5539 says both ends use a certificate. I assume this is the default unless someone makes a clear proposal otherwise. Are you making such a proposal? If not, lets go ahead with both ends use a certificate.

[Qin]: Support.

I was pushing for PSK authentication back in a day when we did NC light. I think it is meanwhile clear that NC light is not a viable option and hence I proposed to remove PSK authentication at the Toronto meeting as not many people seem to care to implement this (slide #7 of my slide set). Perhaps the chairs should do an explicit call for concensus on this so that we can move on.

[Qin]: Are you saying constrained device will not be supported by this draft?

/js

---

From: t.petch <[email-masked]>
Date: Thu, 16 Oct 2014 11:09:44 +0100

----- Original Message -----
From: "Bert Wijnen (IETF)" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 14, 2014 2:45 PM
> but it would be good to have it listed as an issue that we can easily
point to.

There is a pptx slide from IETF90 on the netconf materials page with a
list of issues - sometimes I can access it, sometimes I cannot.

The minutes of IETF90 do reference slides but not in a way that I find
easy to correlate and the minutes on their own do not give me the
complete picture (but who cares, everything will be confirmed on the
list:-)

So that slide set is the closest I know of to an issues list and
'Required Authentication Schemes' seems to fit the bill.

I do think limiting ourselves to client and server X.509 certificates is
the right way forward at this time but it does leave issues.

One is that my reading of RFC6241 is that we need a mandatory,
interoperable technique and if other methods appear in future, e.g. PSK,
PAKE, raw public keys, then we would have to revise the I-D but this is
life  (Netconf started with SSH, BEEP, SOAP!).

Certificate validation I see as straightforward based on RFC5280.

Certificate authentication is tricky, the waters now being muddied by
RFC6125 which, like much around TLS, focusses on HTTP with a user
sitting at a screen ready to intervene - not much use for a network
device looking at a client certificate.  Pre-configured certificate
fingerprints seems the best bet, as a SHOULD.

The work of the UTA WG I think irrelevant - it is chartered for HTTP,
SMTP and such like; client certificates will never be on its radar.
Currently, it is rather hung up on what Opportunistic xxxxx means and
what UTA should do about it.

And then there is extracting the user name, which is even worse.  X.509
could have had a user name extension for us to use, but we are out on a
limb in our use of TLS so it does not.  As I said before, I think that
most TLS applications are RYO for client authentication.

On the plus side, we have been here before and done it with RFC5539 so
the best hope is that what was acceptable then, will be now, but where
Security Area ADs are concerned, my pessimism is usually well-founded.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 19 Oct 2014 22:26:16 +0200

> [Qin]: Are you saying constrained device will not be supported by this draft?

You need to say more clearly what you mean with 'constrained devices'
before I can answer this.

/js

---

From: Qin Wu <[email-masked]>
Date: Fri, 31 Oct 2014 04:14:30 +0000

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2014年10月20日 4:26
收件人: Qin Wu
抄送: t. petch; [email-masked]
主题: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06

Just for curiosity, the constrained device I am referred to is the device with small RAM, limited power, limited processing capability.
It looks these devices more favor using RESTCONF.
/js