Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Mar 2015 08:10:24 -0400

This is an update to netconf over TLS with mutual X.509 authentication.

In general, this looks fairly good.

I'd ask the security ADs to take a look at two things:

* The text on certificate validation in section 5.
Certificate validation has a number of options, none of which are
described or specified in this text.
Is that good enough for this application?  (Probably)

In section 7, there is a description of how the netconf server finds the
username of the client.
It talks about a certificate fingerprint without a reference to a
specific algorithm.
I'm aware of multiple algorithms for fingerprints.
This text is probably too vague for interoperability.

---

From: t.p. <[email-masked]>
Date: Tue, 10 Mar 2015 12:12:14 +0000

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 09, 2015 12:10 PM
Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09

> This text is probably too vague for interoperability.

Sam

I see what you mean but had a different model in mind.  The fingerprint
is not transmitted as part of the tls/netconf protocol, I assume that it
is only generated within a server when a certificate arrives over the
tls/netconf protocol and is then compared with a prestored list of
fingerprints within the server.

So as long as the same algorithm is used within the server, then it does
not matter what is used.  If, instead, the prestored list of
fingerprints is generated outside the server and installed as a file,
then yes, the algorithm used to create the prestored list must be the
same as that used within the server when a certificate arrives over the
tls/netconf protocol.  That is the only issue I can see.

However, this I-D used to contain a data model to go with it but that
has been put into a different I-D namely netconf-server.  That data
model imports a YANG data type tls-fingerprint which is defined as a one
octet hashing algorithm identifier followed by the fingerprint value.
The  octet value is taken from the IANA TLS Hash Algorithm Registry (RFC
5246).

So if the YANG data model is used, then the algorithm is part of the
model and the server can look up what has been used in its prestored
list of fingerprints.  If users do not use the YANG data model, well
that is up to them

Hope this helps

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2015 13:59:18 +0100

> This text is probably too vague for interoperability.

Since the fingerprints are not exchanged over the wire, this is a
local problem. That said, there is a YANG configuration data model in
draft-ietf-netconf-server-model-06 that clarifies details for those
implementations that want interoperable configuration and this data
model uses tls-fingerprint defined in RFC 7407.

/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.p. <[email-masked]>
Date: Tue, 10 Mar 2015 14:16:04 +0000

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, March 10, 2015 12:48 PM
> >>>>> "t" == t p <[email-masked]> writes:
>
> Well, I think you still need to answer questions like
>
> * Is it a fingerprint of the cert or the key?
>
> * Is the server expected to re-normalize the DER?    Allowed to
>   re-normalize the DER?

Sam

Thank you for your comments.

The I-D specifies fingerprint of the certificate so that is specified.

Normalisation is not specified and is an interesting point; as you say,
something to be considered.

Tom Petch

> So that the input to the hash is well specified.
> Several protocols within the IETF have taken on the challenge of
> describing how to fingerprint certificates.  I think the document
would
> be improved by picking one of these strategies.
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Mar 2015 08:48:04 -0400

So that the input to the hash is well specified.
Several protocols within the IETF have taken on the challenge of
describing how to fingerprint certificates.  I think the document would
be improved by picking one of these strategies.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Mar 2015 08:15:59 +0100

> something to be considered.

The model follows RFC 6353 (STD 78) and I am not aware of any issues
that were reported against STD 78 because fingerprints do have issues
with being ambiguous. So are we talking about a real-world problem or
a problem that could exist in theory?

/js

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Mar 2015 07:35:14 +0000

> > something to be considered.

The certificate should not be normalized.  Rather the "locally configured"
fingerprint needs to match the certificate as it is expected to be presented.

> a problem that could exist in theory?

Since the fingerprint is configured via some out-of-band process
that establishes authorized access for the holders of the associated
private keys, its represenation is largely irrelevant.  Any strong
cryptographic binding of the certificate (or bare public key) will
do.

In particular the draft should mention that fingerprints of raw
public keys are also acceptable (and might some day even be used
directly on the wire per RFC 7250).

FWIW, the Postfix MTA has supported authentication of remote SMTP
clients and servers by certificate fingerprint (since 2005 and 2008
respectively) and also by public key (SPKI) fingerprint (since 2012).

No normalization of the certificate is performed, the ASN.1 form
of the certificate is as encoded by the peer.

-- 
	Viktor.

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 11 Mar 2015 11:37:05 +0000

-----Original Message-----
From: t.p. [mailto:[email-masked]] 
Sent: Tuesday, March 10, 2015 1:12 PM
To: Sam Hartman; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Secdir Review of draft-ietf-netconf-rfc5539bis-09

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 09, 2015 12:10 PM
Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09

Sam

Hope this helps

Tom Petch