Re: [babel] babel-dtls: verifying "authentication"

[David Schinazi <[e-mail]>]

Hi Barbara,

Thanks for your review. Responses inline.

On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H <[e-mail]> wrote:

> I read the draft and think the last paragraph of 2.1 could do with a
> little more verbiage as to what "fails to verify the peer's authentication"
> means, since it's part of a "MUST" normative statement. I also don't think
> the word "authentication" is used consistently or (in some cases)
> correctly. I think of "authentication" as a process.
>
> I find "request client authentication" and "verify the peer's
> authentication" to be odd uses of the word "authentication", and not
> consistent with my understanding of the word. I would suggest something
> like "request client certificate" (consistent with the name of the message
> that is sent) or "request client credentials" for the first phrase. And
> perhaps "validate the peer's certificate" or "validate the peer's
> credentials" for the second. Unless you mean something different by
> "verify" vs. "validate" here.
>

Our intent was to use the terms authenticate and authentication in the same
way as the TLS specifications do, in particular see the TLS 1.3 spec
introduction <https://tools.ietf.org/html/rfc8446#section-1>.


> Will only X.509 certificate keys be allowed, or will "DH_anon" key
> exchange be allowed?
>

babel-dtls does not specify what source of authentication to use, X509 are
one allowed option, but they are not mandated
DH_anon is prohibited by "Nodes MUST use mutual authentication" (and
subsequent clarifying text in section 2.1)


> Here are the possible things that are sometimes done as part of
> certificate validation, that I think this phrase is potentially referring
> to:
> 1. Ensure the certificate validDate is not in the past. This check should
> only be done if the implementation thinks the underlying system has
> acquired a good current time (i.e., it runs a NTP client and getting the
> current datetime via NTP has succeeded, or the current datetime has been
> configured).
> 2. Check the certificate's chain of trust for a trusted CA. This would
> mean there is a configured set of trusted CAs.
> 3. Check if the certificate has been revoked. This is often not done, but
> might not be a bad idea the first time the certificate is seen.
> 4. Check if this identical certificate is included in a store of trusted
> certificates (either it was previously trusted and stored or the store is
> configured).
> 5. Check some aspect of "identity". Is there some characteristic of the
> peer that is expected to be stable wrt a certificate? For example, would
> the same certificate always originate from the same MAC address or LL IPv6
> address?
> 6. If a TOFU (trust on first use) policy is supported, what exactly should
> be trusted (and what should not be trusted)? I do like allowing for a TOFU
> policy (if an implementation chooses to support one). If it is allowed, I
> would suggest something like the cert is TOFU if the IPv6 LL address hasn't
> been seen before (new neighbor). After that it always has to use the same
> cert. When changing certs, send old and new cert together for some time, so
> new cert is associated with trusted old cert.
>
> Presumably, a device might be configured with a new certificate at some
> point (like when the old one expires). Will the new certificate be
> considered the same neighbor if the "identity" matches (see item 5 for
> question on determining identity)? If you get a request for a new DTLS
> session and already have a session for that "identity" (IPv6 LL address?)
> with a different certificate, what do you do?
>
> If there is already a DTLS connection using a provided certificate, what
> do you do if you get a request for a new DTLS session using the same
> certificate? Tear down the old one?
>
> With all this said. I think it might be enough if the draft had statements
> like:
> "The key exchange mechanism used MUST require use of X.509 certificates."
> (if this is the intent)
> "Certificate validation MUST be done according to internal policy.
> Characteristics of certificates that MAY be used for validation include the
> validDate, the Certificate Authority (CA) chain of trust, inclusion in a
> revocation list, prior determination of trust, and whether the IPv6 link
> local address is the same as in prior uses of the certificate. A trust on
> first use (TOFU) model MAY be supported, with policy defined by the
> implementation. Any TOFU policy MUST, at a minimum, ensure that a given
> certificate is only ever used from a single IPv6 link local address
> (neighbor) and fail an unknown certificate used for an IPv6 link local
> address already associated with a trusted certificate. "
> "When new certificates are issued, they SHOULD be sent together with the
> old certificate prior to the old certificate's expiration or revocation, so
> it is possible for the new certificate to inherit any trust associated with
> the old certificate."
>

Certificate validation is out of scope for the babel-dtls draft, in the
same manner as it is out of scope for the TLS or DTLS RFCs. I don't think
any mention of certificates at all belongs in this draft, as some
applications may choose to not use certificates. In the case of babel, the
babel-dtls draft specifies how to use DTLS; on the other hand the
certificates and PKI you use is left to the users of babel-dtls, for
example the homenet mapping document could mandate X509 and how to add new
certificates to the trust store, and the other points you mentioned would
make sense to me in that document.

Or make certificate validation a SHOULD. ☹
>

Validating identity is a MUST, the fact that that identity maps to a
certificate is a MAY.

Thanks,
David