Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 05 Mar 2012 21:12:03 +0100

If I am correct, then, after Mehmet's call for
discussion and to express interest, I have seen

- Badra supports (editor/author)
- Juergen supports (contributed to the document)
- Mehmet supports

Did I miss any?

Do our other netconf implementers (Andy, Martin, Lada?
Juniper-folk) not want to express an opinion?

Bert (co-chair hat on)

On 2/14/12 1:00 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Dear NETCONF WG,
>
> we had a discussion on draft-badra-netconf-rfc5539bis in Taipei and people
>
> were agreeing that this work is needed if we want to keep NETCONF over TLS
>
> on the standards track.
>
> The revision posted yesterday updates RFC 5539 fitting the changes in RFC
>
> 6241 and is covered by our charter.
>
> The co-chairs believe that there is sufficient interest on this document
>
> to be a working group item. So we encourage discussion here so that we
>
> can make the next steps and if the interest indeed shows, then make it a
>
> WG document.
>
> Please state your opinion (including draft authors and contributors) on the
>
> ML concerning the importance of this draft and updating RFC 5539, within
>
> the next two weeks.
>
> Another important questions is: Who is going to implement the update?
>
> The optimal case would be if we can already discuss any implementation
>
> experience in IETF #83.
>
> Mehmet & Bert
>
> *From:*ext Mohamad Badra [mailto:[email-masked]]
> *Sent:* Monday, February 13, 2012 11:00 PM
> *To:* [email-masked]
> *Cc:* Ersue, Mehmet (NSN - DE/Munich); ext Bert Wijnen (IETF)
> *Subject:* New version of draft-badra-netconf-rfc5539bis
>
> Dear All,
>
> I posted a new version of draft-badra-netconf-rfc5539bis and would appreciate your comments. Enclosed is the diff file.
>
> The document URL: http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-01.txt
>
> WG Chairs, I would like to ask adoption the document as WG item.
>
> Best regards,
>
> Badra
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 5 Mar 2012 21:23:45 +0100

> Juniper-folk) not want to express an opinion?

I do support the update of 5539, but since I recently changed my job I cannot promise an implementation.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Mar 2012 19:19:54 -0800

Section 2.1: "It MUST connect to the server that passively listens for the incoming TLS connection on the TCP port 6513".  This language eliminates the possibility of implementing a "reverse-tls" mechanism like we have with "reverse-ssh".  Since one of the motivators for this work is to support low-end devices, I would think a need for a call-home mechanism would be desired.  That said, it might be hard to implement since SSH uses a named subsystem ("netconf"), maybe this is more reason to support bidirectional TLS connections? [Note: this language was also in RFC5539]

Section 2.2: what about <close-session>?  - why define another mechanism?  If important, then why doesn't RFC6242 require the client to send SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT.   Regardless, I disagree with the intent of forcing graceful closures - in reality, devices MUST be coded to support ungraceful closures and, once the code is written, there isn't much value to a graceful close anymore.  Also the second paragraph seems out of place - shouldn't it be in the TLS RFC? [Note: this language was also in RFC5539]

Section 3.1 - RFC4642 places these recommendations into its "Security Considerations" section - should this draft do the same?  If this draft is going to specify this information, then should it first state that the client SHOULD validate the server's certificate chain (i.e. a trusted CA, no expirations, no revocations, etc.)?  Note: this language was also in RFC5539]

Section 3.2.1 - What happens if subjectAltName contains more than one ipAddress, dnsName, or rfc822Name - as allowed by RFC 5280 section 4.2.1.6?

Section 3.2.1.1 - This whole section should be rewritten - it's hard to follow as is.  I think there is an implicit assumption that the client's certificate is trusted; that is, that the TLS layer would not have allowed the connection if couldn't validate the certificate. Does this assumption need to be stated explicitly?   Third paragraph is about being able to apply transformation based on the identification of the issuing CA, a good idea, but shouldn't this be after exhausting all direct-match options. Lastly, what is a "transformation container"?

Section 3.2.1.3:

Regarding "description" - Is the second sentence redundant? "It specifies how NETCONF servers transform X.509 certificates presented by clients into NETCONF usernames.  It also specifies how NETCONF clients transform NETCONF usernames into X.509 certificates for presentation to NETCONF servers."

Regarding "tls-fingerprint-type" - how can it be of length '0'?  - the last paragraph says it's to support containers where the fingerprint may be optional, but shouldn't those containers simply not specific "mandatory true"?  The 2nd paragraph regards an encoding, does this mean that implementations MUST support all the hash algorithms listed in IANA's registry?

Regarding "certificate-to-username-transform-count" - this type doesn't seem to be referenced anywhere - remove it?

Regarding "certificate-to-username-transform-last-changed" - this type doesn't seem to be referenced anywhere - remove it?  Besides, why reset the value to '0' just because the NetConf server restarted?

Regarding "certificate-to-username-transforms"
  1) the statement "the client's presented certificate MUST either be validated based on an established trust anchor, or it MUST directly match a fingerprint in this container."  is surprising - does this mean that the TLS server MUST be coded to allow connections having client certificates that cannot be authenticated at the TLS-level?  I had assumed that this RFC was only proscribing how to extract an identity, but this proscribes an authentication strategy - is that right?
  2) the statement "If the list entry's certificate-fingerprint value matches that of a locally held copy of a trusted CA certificate, and that CA certificate was used to validate the path to the presented certificate, then consider the list entry as a successful match." - what is the "path"? - do you mean the certificate chain? - how does the server know this?  I need to see an example.
  3) the statement "Non-consecutive values of index are acceptable and implementations should continue to the next highest numbered list entry.  It is recommended that administrators skip index values to leave room for the insertion of future list entries (for example, use values of 10 and 20 when creating initial list entries)."  - why not just use an ordered list?

Regarding certificate-fingerprint - why is the length on "tls-fingerprint-type" further constrained?

Regarding "data" - should a regex be used to constrain it to valid username format?

Regarding "psk-map" - why have "valid-not-before" and "valid-not-after" - aren't these already specified in the certificate?  If not, then why not just have the configuration added/removed when becoming valid/invalid?  Should we start adding time-based constraints to all our YANG models?

PS: I will not be checking mail tomorrow, in case you're wondering why I don't post any follow-up responses

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
Sent: Monday, March 05, 2012 3:12 PM
To: Netconf
Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis

Did I miss any?

Bert (co-chair hat on)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Mar 2012 19:30:30 -0800

> Juniper-folk) not want to express an opinion?

I have not received any requests so far to implement a TLS transport
for yuma.  Nobody has volunteered either.  I do not oppose this draft,
but I do not have the resources to implement it or even review it.

> Bert (co-chair hat on)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2012 08:06:49 +0100

> Section 2.2: what about <close-session>?  - why define another mechanism?  If important, then why doesn't RFC6242 require the client to send SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT.   Regar…

Proper closure of the TLS session is important to be able to
distinguish a proper closing of the session from a potentially
malicious closing of the session. I guess the same applies for
SSH. Sure, you can't prevent arbitrary TCP failures but a proper
shutdown procedure tells the other end that the closure was done by
intention. In other words, from a security point of view, I think
RFC6242 should have also encouraged proper SSH shutdown.

> Regarding "psk-map" - why have "valid-not-before" and
> "valid-not-after" - aren't these already specified in the
> certificate?  If not, then why not just have the configuration
> added/removed when becoming valid/invalid?  Should we start adding
> time-based constraints to all our YANG models?

With pre-shared keys, there are no certificates involved. To
accomplish key rollovers, you need to provision multiple keys and tell
the server when they are valid. (You obviously can't install a new key
with NETCONF if the old key has expired - so this really needs to be
done before the old key expires.)

/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: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Mar 2012 08:40:29 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> for yuma.

Same for us.  We haven't implemented it, and we have never had any
requests for it.

> Nobody has volunteered either.  I do not oppose this draft,

I don't oppose it either, but at the same time I don't quite see the
value in having this transport.  I will review if the WG decides to do
it though.

/martin

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 9 Mar 2012 10:39:17 +0100

Dear Kent,

Section 2.1: "It MUST connect to the server that passively listens for the
> incoming TLS connection on the TCP port 6513".  This language eliminates
> the possibility of implementing a "reverse-tls" mechanism like we have with
> "reverse-ssh".  Since one of the motivators for this work is to support
> low-end devices, I would think a need for a call-home mechanism would be
> desired.  That said, it might be hard to implement since SSH uses a named
> subsystem ("netconf"), maybe this is more reason to support bidirectional
> TLS connections? [Note: this language was also in RFC5539]
>

RFC5246 doesn't support reverse proxy as well, and all RFCs' Applications
over TLS have the same above language.

However, what about rewriting it as follow:

The peer actively opens the TLS connection, and the server passively
listens for the incoming TLS connection.

Section 2.2: what about <close-session>?  - why define another mechanism?
>  If important, then why doesn't RFC6242 require the client to send
> SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT.   Regardless, I disagree
> with the intent of forcing graceful closures - in reality, devices MUST be
> coded to support ungraceful closures and, once the code is written, there
> isn't much value to a graceful close anymore.  Also the second paragraph
> seems out of place - shouldn't it be in the TLS RFC? [Note: this language
> was also in RFC5539]
>
> Section 3.1 - RFC4642 places these recommendations into its "Security
> Considerations" section - should this draft do the same?  If this draft is
> going to specify this information, then should it first state that the
> client SHOULD validate the server's certificate chain (i.e. a trusted CA,
> no expirations, no revocations, etc.)?  Note: this language was also in
> RFC5539]
>

I would prefer not moving it to the "Security Considerations" and I will
replace the 1st paragraph with

If the server's presented certificate has passed
certification path validation [RFC5280] to a configured
trust anchor, the client MUST carefully examine the
certificate presented by the server to determine if it meets the
client's expectations. Particularly, the client MUST check its
understanding of the server hostname against the server's identity as
presented in the server Certificate message, in order to prevent man-
in-the-middle attacks.

Section 3.2.1 -
> Section 3.2.1.1
> Section 3.2.1.3

Alan and Juergen will be able to address your concerns much better than me.

Best regards,
Badra

---

From: Phil Shafer <[email-masked]>
Date: Fri, 9 Mar 2012 09:13:46 -0500

>> Juniper-folk) not want to express an opinion?

We have a proprietary SSL-based connection mechanism that predates
this draft, but it is rarely used.

On the other hand, customers complain about the amount of time
required for starting up an ssh connection, so if this access
mechanism is quicker, perhaps it can find a niche.  I've never done
these timing comparisons myself.

Thanks,
 Phil