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

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 9 Jan 2019 21:42:47 +0000

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. 

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

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."

Or make certificate validation a SHOULD. ☹
Barbara

---

From: David Schinazi <[email-masked]>
Date: Wed, 9 Jan 2019 14:06:40 -0800

Hi Barbara,

Thanks for your review. Responses inline.

On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H <[email-masked]> 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

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?
>
> "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.

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

Thanks,
David

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 10 Jan 2019 03:17:50 +0000

On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> 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.

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.

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.

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.

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

---

From: David Schinazi <[email-masked]>
Date: Fri, 11 Jan 2019 11:43:20 -0800

Hi Barbara,

I think we're using terminology differently, but I'm not sure how to
resolve that best. Would you consider proposing text that would address the
issues you point out? A pull request to our repository
<https://github.com/jech/babel-drafts> would be ideal :)

Perhaps one way to resolve your issue would be to remove the MUST validate
identity, because I see your point that it is unclear. I still believe that
we shouldn't over-specify this and instead let usage profiles (like the
homenet profile) specify what kind of identity and keys to use for a given
use-case.

David

On Wed, Jan 9, 2019 at 7:18 PM STARK, BARBARA H <[email-masked]> wrote:

> 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.
>
>
>
> 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.
>
>
>
> <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
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 12 Jan 2019 12:48:47 +0100

> otherwise (e.g., [TLSPGP]).”

My reading is that this doesn't preclude negotiating a different
certificate type (either in-band or out-of-band, e.g. through static
configuration) or using a PSK (symmetric key).

I agree with David that this is out of scope for the Babel-DTLS draft.

> <bhs> Validating what identity?

David should not have spoken about identity -- what we're speaking here is
authentication.

TLS has a notion of server and client authentication.  Server
authentication is hardwired into the protocol, client authentication is
optional.  What the draft says is that the Babel-DTLS protocol requires
client authentication in addition to server authentication.

> 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.

I'm not a specialist, but this looks like it's consistent with the nature
of TLS.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 14 Jan 2019 19:34:55 +0000

> My reading is that this doesn't preclude negotiating a different certificate
> type (either in-band or out-of-band, e.g. through static

I also agree it's out-of-scope to say anything about this in the babel-dtls draft. But it's not out-of-scope for information-model. I need to make sure the info model provides the ability to easily manipulate (add/delete) the types of certificates we think will commonly be used. Leaving the info-model open to supporting all possible certificate types isn't something I'm in favor of. It's also useful to understand what sort of certificate might be used when trying to figure out what it means to "authenticate" (or "validate" or "verify") such a certificate. 

> TLS has a notion of server and client authentication.  Server authentication is
> hardwired into the protocol, client authentication is optional.  What the draft
> says is that the Babel-DTLS protocol requires client authentication in addition
> to server authentication.
> 
> I'm not a specialist, but this looks like it's consistent with the nature of TLS.

No. (D)TLS ecosystems have to specify what "authentication" means within that ecosystem. Server authentication is *not* hardwired into the TLS protocol. Only the exchange of certificates, and their use in negotiating a shared secret and establishing encryption, is specified by (D)TLS. As far as (D)TLS is concerned, received certificates can be automatically accepted without question (i.e., without authentication), and (D)TLS will work just fine. Mutually exchanging credentials != mutual authentication. Sending a CertificateRequest message simply requests the client to send a cert. It does *not* "request client authentication". It *allows* the server to perform client authentication on the cert subsequently sent by the client. How or whether to authenticate a received certificate is specified by application layer policy. 

Quote from the TLS RFC: 
"... the decisions on ... how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS." 
[Note authentication certificate = authentication key = certificate; authentication certificate != authentication.]

Examples of ecosystem-specific authentication requirements:
 - When TLS is used with Internet servers, authentication consists of checking the validate, checking that it's signed by a CA whose cert is in an internal cert store of trusted credentials, checking that site domain name = subjectAltName field, and optionally checking other things like whether the cert has been revoked. Different web browsers (and other HTTP applications) have different cert stores for what CAs they trust and different specific authentication algorithms. 
 - Checking that provided credentials are in an internal store of trusted credentials 
 - Checking that provided credentials are in an internal store of trusted credentials and always sent from a particular IP address
 - Checking that provided certificate is in an internal cert store and subjectAltName matches an identity included in the application-layer protocol.

Here are some possible authentication requirements that might be reasonable for babel-dtls. I'm strongly in favor of the first of these. I also think the CA requirement is a good idea. The others I'm presenting to provide an idea of what else we might say, but I do think it's good to provide at least one (optional) method for associating credentials with a specific router-id or IP address.
MUST authenticate received credentials against an internal store of credentials.
SHOULD associate router-id with credentials and ensure credentials are only used for that router (this would require additional requirements for how to express router-id in certain types of credentials -- like X.509 subjectAltName).
MAY ensure same IP address is used to send a particular cert, after first use of cert
MAY support validation by certificate authority (CA) credentials (requires an internal store of CA credentials) used to sign received credentials.
MAY support trust-on-first-use for first time an IP address is seen

Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 14 Jan 2019 22:39:19 +0100

> No. (D)TLS ecosystems have to specify what "authentication" means within
> that ecosystem.

[...]

> As far as (D)TLS is concerned, received certificates can be
> automatically accepted without question (i.e., without authentication),
> and (D)TLS will work just fine.

Right.  Thanks for the explanation.

---

From: David Schinazi <[email-masked]>
Date: Mon, 14 Jan 2019 14:03:46 -0800

Hi Barbara,

I think we might be interpreting the TLS document differently from one
another, but I'm sure we'll find agreement on what to change in Babel-DTLS.

Regarding the type of credentials, I'm fine with the information model
restricting configuration to X509 certificates, but I do not think that
should belong in Babel-DTLS as there might be non-certificate based
use-cases for Babel-DTLS.

Responding inline to your text proposals:

On Mon, Jan 14, 2019 at 11:35 AM STARK, BARBARA H <[email-masked]> wrote:

> Here are some possible authentication requirements that might be
> reasonable for babel-dtls. I'm strongly in favor of the first of these. I
> also think the CA requirement is a good idea. The others I'm presenting to
> provide an idea of what else we might say, but I do think it's good to
> provide at least one (optional) method for associating credentials with a
> specific router-id or IP address.
>

Requiring a CA would break the homenet use-case for example. In my opinion,
if I buy a bunch of homenet routers I should be able to setup my network
even if I don't currently have Internet access to get a CA to sign my
certificates.

> MUST authenticate received credentials against an internal store of

I'm not sure how this differs from the current text "Nodes MUST use mutual
authentication" - authenticating a peer implies it is done against a store
of credentials, but perhaps adding a line of clarification is worthwhile.

> SHOULD associate router-id with credentials and ensure credentials are
> only used for that router (this would require additional requirements for
> how to express router-id in certain types of credentials -- like X.509
> subjectAltName).
>

I don't think we should necessarily bind ourselves to the router-ID, as
that could inhibit future innovation - I could run a router that uses two
router IDs to do <insert magic new feature here>.
Having a way to tie router-IDs to X509 certificates makes sense to me, but
I see that as a separate document (similar to how subjectAltName is not
defined or mentioned in the TLS spec).

> MAY ensure same IP address is used to send a particular cert, after first

There are devices out there rotating MAC addresses and IP addresses
periodically to improve user privacy, I don't want Babel-DTLS to get in the
way of that.

> MAY support validation by certificate authority (CA) credentials (requires
> an internal store of CA credentials) used to sign received credentials.

I'm not sure how these MAYs improve the document. These mechanisms will be
defined by the profiles that use Babel-DTLS. If you feel strongly about
this we could add an appendix providing options for what credentials would
make sense, but I would remove the normative language.

All this said, it might be simplest to have a phone call / video chat of
some kind to discuss this in real time.

Thanks,
David

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 14 Jan 2019 23:24:36 +0100

> MUST authenticate received credentials against an internal store of

Sounds good to me.  Say that a router is configured with a number of
credentials, and that what authentication means depends on the exact kind
of the credential.  Give three examples -- public key, CA, pre-shared
symmetric key.  Be very clear that this list is not exhaustive, and
implementations MAY use other strategies.

> SHOULD associate router-id with credentials

No, that's too restrictive.  While 6126bis associates a router-id with
a router, router-ids are only carried by routes, so a router that doesn't
redistribute any routes does not need to carry a router-id.  Furthermore,
router-ids need not be persistent -- a router can pick a new router-id
whenever it reboots.

> MAY ensure same IP address is used to send a particular cert, after

That won't work -- Babel supports having multiple interfaces on the same
link (and that actually happens quite often in radio networks, either due
to misconfiguration or for increased reliability).  IPs identify
interfaces, not routers.

> MAY support validation by certificate authority (CA) credentials
> (requires an internal store of CA credentials) used to sign received
> credentials.

Yep.  That's the second example in my list above.

> MAY support trust-on-first-use for first time an IP address is seen

That would work -- as long as we allow the same cert to be originated by
multiple IPs.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 15 Jan 2019 10:12:23 -0800

I just had a quick phone call with Barbara and we clarified our differences
in terminology.
I have slightly tweaked the authentication text to hopefully address these:
https://github.com/jech/babel-drafts/commit/0d1fbc98e5a8a0b86e6cbe6d6757c1fbe7d6fc2d

Barbara, thanks for taking the time, and please let us know if you like the
new text.

Thanks!
David

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 16 Jan 2019 13:58:54 +0000

I’ve read the proposed text. It resolves my comments.
I have no other comments and support publication of the draft.
Barbara

From: David Schinazi <[email-masked]>
Sent: Tuesday, January 15, 2019 1:12 PM
To: Juliusz Chroboczek <[email-masked]>
Cc: STARK, BARBARA H <[email-masked]>; Babel at IETF <[email-masked]>
Subject: Re: [babel] babel-dtls: verifying "authentication"

I just had a quick phone call with Barbara and we clarified our differences in terminology.
I have slightly tweaked the authentication text to hopefully address these:
https://github.com/jech/babel-drafts/commit/0d1fbc98e5a8a0b86e6cbe6d6757c1fbe7d6fc2d<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jech_babel-2Ddrafts_commit_0d1fbc98e5a8a0b86e6cbe6d6757c1fbe7d6fc2d&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=QOMuCseQ_LpPPqW6uYIq8TTVOwfgYRcrWz0nmJ1xbVM&s=kUhH8wpDHCyASUxwyGQFaty4MZEXSzl6-VT1hVimhHU&e=>

Barbara, thanks for taking the time, and please let us know if you like the new text.

Thanks!
David

-- Juliusz