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

David Schinazi <dschinazi.ietf@gmail.com> Fri, 11 January 2019 19:43 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C434128766 for <babel@ietfa.amsl.com>; Fri, 11 Jan 2019 11:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdnUiTnBUJM3 for <babel@ietfa.amsl.com>; Fri, 11 Jan 2019 11:43:32 -0800 (PST)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD091286E7 for <babel@ietf.org>; Fri, 11 Jan 2019 11:43:32 -0800 (PST)
Received: by mail-pg1-x52e.google.com with SMTP id t13so6704758pgr.11 for <babel@ietf.org>; Fri, 11 Jan 2019 11:43:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DMHKWadR2mj31tmaHewWA6jISb0jendSyilZTQvjJNI=; b=Vqwq5QmwNeQjceN2ylLe9QZ6/wCLTZ+4VF1RYsy3aQ4b15jdPfTxLHPUq9FEOppxQY cAQ2No3YjIOam/sCQTJFMUic8v1bwwOArVkXN0T5wBa2/SQbD6k8WtnBtd6PMlMqrT8G HeCj8Iue8eX0haq3xtkHzwYZ2sBbFLQgVRaKcRW4wlBIxXxH20XVy71+knTLRoij7VRr xFncB5E1RbBxh6DpMnrNezuX27fJC1pefWm7xgTSTOp7JZ1+RYXnO+1iIX8D/i+dUw+G V1FWtdHor6EIAaIoenGZf1O1wL8Hv+FjmRSZ8kCRadnZ5yBvdhY97qNwgIMygSBC3ui7 vRPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DMHKWadR2mj31tmaHewWA6jISb0jendSyilZTQvjJNI=; b=WbF+ousEfTEkq7/D4FxvS/SVtW5v0dnXhcUipWG1WElA7a52fNvzhUCBqJVfBJYAM/ tk6K1HQvTj5vO2/edsKO888iJB38UEN/GvA5qUA2dDku6u5soeQ2U0WMidScqVncguvW ATRjpemxDLAOhS/Dz3xEr1PpF/MfkbOqwdsS8BMNDLhXcMewR5xFFDA1VdS4uANUbcF6 plLLtC3I/hR2Jtfb6vVY4cEmv0ZzxFj/PNkbDjwuUBUkiys9Lan+7w1GAZu6UcUi0rBl DaEDdwHHAEEdSDTfNrFBVK+ct2XTHogjrWst0GMN/SvQrZbxfJe+oMS59/ng4Q/kbYfl dYAQ==
X-Gm-Message-State: AJcUukeDLh4mwVawEWfWX1LT4Fv0j6DKFvqqHRYz6DHuDp+/bB3IXGAh UftYoRedv4unQDKi9Ci7lQxAR4vpU4yZtBdRXRU=
X-Google-Smtp-Source: ALg8bN5LWzjEEIfljFtWjhWHhkcoSli6LXYgxosGRIxEFebImU0bsR2S6Up6dQgsigwMvrErbMmrj6JduEUArKHTleA=
X-Received: by 2002:a62:5658:: with SMTP id k85mr15685947pfb.231.1547235811519; Fri, 11 Jan 2019 11:43:31 -0800 (PST)
MIME-Version: 1.0
References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAPDSy+6cuAJ1m1-DJAHVNjmsQHP6SOJoFSZx6bF6x8o48xs71Q@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Fri, 11 Jan 2019 11:43:20 -0800
Message-ID: <CAPDSy+4=ReD0NAJQQGOgiKMV9Q7TD6LS1TxOiaC=GRoCutciWA@mail.gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: Babel at IETF <babel@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000edf0ee057f33e860"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/IUAoGTCC7tx01ZSHIECX1EShK84>
Subject: Re: [babel] babel-dtls: verifying "authentication"
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jan 2019 19:43:35 -0000

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 <bs7652@att.com> wrote:

>
>
> On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H <bs7652@att.com> 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
>