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

["STARK, BARBARA H" <[e-mail]>]

On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H <[e-mail]<mailto:[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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8446-23section-2D1&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=YC72PjflRXn_GgiF5MetBcDZlLnezCCCcGyKIBnug0g&s=oBF96sjCDL5QI5GpPkbNS_KavWpgv9kfW5Qo1N0ye20&e=>.

<bhs> I looked at the TLS 1.3 spec, and the use of “authentication” there is very consistent with my understanding of authentication as a process. The 2 phrases I noted seem to use “authentication” as if it meant “authentication key” – which it does not. The CertificateRequest message is not used to request client authentication (i.e., request the client perform the authentication process). It is used to request a client authentication key. You cannot verify an authentication. But you can verify an authentication key.

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)

<bhs> TLS 1.2 (RFC 5246) says “The following rules apply to the certificates sent by the server:
   -  The certificate type MUST be X.509v3, unless explicitly negotiated otherwise (e.g., [TLSPGP]).”
DTLS (RFC 6347) doesn’t modify this requirement and neither DTLS nor babel-DTLS requires support for certificate format negotiation. Every babel-dtls implementation has to be prepared to act as the DTLS server. Practically speaking doesn’t this mean every babel-dtls implementation that expects to interoperate in an open environment has to either have or be able to generate an X.509 certificate? Anything less and there can be no expectation of interoperability. Clearly, a closed environment can use whatever it wants. But I don’t find closed environments very interesting.

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.

<bhs> Validating what identity? You haven’t specified any identity to map anything to. You can’t make validation a MUST if you give no clue as to how or what to validate.

Barbara

Thanks,
David