Subject: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Apr 2015 08:14:24 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-netconf-rfc5539bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 2: be no harm to say the server has to send a
CertificateRequest as part of the handshake and/or to say (or
point to) how e.g. to configure that in apache or similar.
(Not normatively, but as an illustration to save folks time
when they go to do it.)

- section 7, if we get the ID via step (b) option 2 and step
(c) option A then anyone certified below that CA gets to use
that identity. I'd say that's a sufficiently bad plan in
almost all cases to be worth noting as a security
consideration.  (Sorry for not spotting that in RFC7407 but I
think the alg there is harder to see in the yang module(s) so
I guess I missed it;-)

- I agree with Sam's second comment in the secdir review [1]
that specifying how to fingerprint is a good idea, even if
it's non-normative. I think in this case you may need to
fingerprint the full certificate and not the public key, as
the latter could allow attacks - but someone would need to
spend more time that I have today to figure out if there are
any interesting attacks. (Did the WG think those issues
through?)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05522.html

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 10:57:46 +0200

Would this address your comment:

OLD

   [...] The TLS client
   MUST send the TLS ClientHello message to begin the TLS handshake.
   Once the TLS handshake has finished, the client and the server MAY
   begin to exchange NETCONF messages.  

NEW:

   [...] The TLS client
   MUST send the TLS ClientHello message to begin the TLS handshake.
   The TLS server MUST send a CertificateRequest in order to request a
   certificate from the TLS client.  Once the TLS handshake has
   finished, the client and the server MAY begin to exchange NETCONF
   messages.

I am not sure it makes sense to describe how this is done using Apache
since NETCONF is not running over HTTP and thus servers are not using
web-server configs.

> think the alg there is harder to see in the yang module(s) so

I do not see the problem. Step (b) determines whether the current list
entry should be considered (because the fingerprint matches the
client's certificate fingerprint or it matches the fingerprint of a CA
certificate used to validate the client's fingerprint). The subsequent
steps in (c) determine the username out of the client's fingerprint
(and not the CA certificate in case (b).2 was used in step (b)).
 
>    [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05522.html

The text says in a couple of places 'certificate fingerprint'. It
never talks about the embedded key itself.

/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: Stephen Farrell <[email-masked]>
Date: Thu, 09 Apr 2015 10:57:12 +0100

Hiya,

> since NETCONF is not running over HTTP and thus servers are not using

Fair enough.

> I do not see the problem. 

So say a Web PKI root CA certificate fingerprint is added
then anyone who gets a web site certificate from them could
be logged in to the server as whatever identity is stored for
all the millions of possible certificates that chain up to
that CA.

It's just a matter of scope, and I think this is an error
that could be made. Well, not for a public CA like the
above but maybe for an enterprise CA that also issues
employee cards, s/mime certs, software licenses etc. That
kind of thing was part of the flame attack due to how
msft architected their PKI so as to entwine licensing and
other PKI stuff.

I think you ought point out that there is a codepath here
that could end up allowing loads of TLS clients to get
access if you configure things badly, but in a way that's
not extremely unlikely to happen.

> Step (b) determines whether the current list

Ok, but (again, non-blocking) I'd recommend you describe a way
to do that.

Cheers,
S.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 16:06:37 +0200

> not extremely unlikely to happen.

Would this addition to the security considerations address your
concern?

   [...] Note that the decision
   whether a certificate presented by the client is accepted can depend
   on whether a trusted CA certificate is white listed (see Section 7).
   If deployments make use of this option, it is recommended that the
   white listed CA certificate is used only to issue certificates that
   are used for accessing NETCONF servers.

/js

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Apr 2015 15:14:26 +0100

>    are used for accessing NETCONF servers.

Yes, that'd be a fine recommendation to follow.

I'd personally also add text about the bad case where the CA
issues many certificates for other purposes and say that that
particular configuration is not suitable.

S.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 16:26:42 +0200

> particular configuration is not suitable.

Next proposal...

   [...] Note that the decision
   whether a certificate presented by the client is accepted can depend
   on whether a trusted CA certificate is white listed (see Section 7).
   If deployments make use of this option, it is recommended that the
   white listed CA certificate is used only to issue certificates that
   are used for accessing NETCONF servers.  Should the CA certificate be
   used to issue certificates for other purposes, then all certificates
   created for other purposes will be accepted by a NETCONF server as
   well, which is likely not suitable.

/js

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Apr 2015 15:27:24 +0100

>    well, which is likely not suitable.

Lovely,
Thanks,
S.