Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 15 October 2020 22:04 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4824F3A0905; Thu, 15 Oct 2020 15:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 uY5FxywZwAAR; Thu, 15 Oct 2020 15:04:14 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68133A08EB; Thu, 15 Oct 2020 15:04:13 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09FM3oDA007564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Oct 2020 18:03:55 -0400
Date: Thu, 15 Oct 2020 15:03:49 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Toerless Eckert <tte@cs.fau.de>
Cc: The IESG <iesg@ietf.org>, draft-ietf-anima-autonomic-control-plane@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>
Message-ID: <20201015220349.GH50845@kduck.mit.edu>
References: <159727599109.5414.1617295798802435987@ietfa.amsl.com> <20200911125956.GA63981@faui48f.informatik.uni-erlangen.de> <20201001223244.GP89563@kduck.mit.edu> <20201002080614.GA374@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201002080614.GA374@faui48f.informatik.uni-erlangen.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ijSf_c4dXGKidkAxfi_IhoXdb48>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2020 22:04:16 -0000

Hi Toerless,

On Fri, Oct 02, 2020 at 10:06:14AM +0200, Toerless Eckert wrote:
> Thanks, Ben
> 
> Let me just comment on possible AI for you, i will do my AI in a few
> days when i have more time.

I guess I took more than a few days for mine :(

> On Thu, Oct 01, 2020 at 03:32:44PM -0700, Benjamin Kaduk wrote:
> > I think A.6 is an interesting idea and don't want to drop the idea, but the
> > current state of the text in A.6 is better suited for a separate doc than
> > inclusion in this one.  I suppose I could try to do a shorter rewrite that
> > might be a better fit for this doc if you want; let me know.
> 
> A separate doc would have to be an actual spec of the mechanism IMHO,
> and alas i do not have the time right now to start it (and after
> we have an ACP RFC maybe i can also find other WG participants to
> contribute ;-)). So i do not want to loose the thought and think an
>  appendix is the best reminder for the problem and solution directions.
> 
> Aka: Yes: If you want to send replacement text, please send it,
> and i will replace A.6 with it verbatim.

Here's a first crack.  I'll set a reminder to read over it again in a
few weeks to see if it still looks okay (and presumably we can get some
other eyes on it in the intervening period, too).

The discovery procedure in this specification for low-level ACP channel
support by layer-2 peers involves DULL GRASP and attempting (usually in
parallel) to establish all supported channel types, learning the peer ACP
address and correspondingly the assignment of Decider and Follower roles,
and tearing down all channels other than the one preferred by the Decider.
This procedure, in general, becomes resource intensive as the number of
possible secure channels grows; even worse, under some threat models, the
security of the discovery result is only as strong as the weakest supported
secure channel protocol.  Furthermore, the unilateral determination of
"best" channel type by the Decider does not result in the optimal outcome
in all possible scenarios.

This situation is tolerable at present, with only two secure channels (DTLS
and IPsec) defined, but long-term agility in the vein of [BCP201] will
require the introduction of an alternate discovery/negotiation procedure.
While IKEv2 is the IETF standard protocol for negotiating security
associations, it currently does not have a defined mechanism flexible
enough to negotiate the parameters needed for, e.g., an ACP DTLS channel,
let alone for allowing ACP peers to indicate their preference metrics for
channel selection.  Such a mechanism or mechanisms could be defined, but if
ACP agility requires introducing a new channel type, for example MacSec,
IKEv2 would again need to be extended in order to negotiate an ACP MacSec
association.  Making ACP channel agility dependent on updates to IKEv2 is
likely to result in obstacles due to differeng timescales of evolution,
since IKEv2 implementations help form the core of Internet-scale security
infrastructure and must accordingly be robust and thoroughly tested.

Accordingly, a dedicated ACP channel negotiation mechanism is appropriate
as a way to provide long-term algorithm and secure-channel protocol
agility.  Such a mechanism is not currently defined, but one possible
design is as follows.  A new DULL GRASP objective is defined to indicate
the GRASP-over-TLS channel, which is by definition preferred to other
channel types (including DTLS and IPsec).  When both peers advertise
support for GRASP-over-TLS, GRASP-over-TLS must run to completion before
other channel types are attempted.  The GRASP-over-TLS channel performs the
necessary negotiation by establishing a TLS connection between the peers
and using that connection to secure a dedicated GRASP instance for
negotiating supported channel types and preference metrics.  This provides
a rich language for determining what secure channel protocol to use for the
ACP link while taking into account the capabilities and preferences of the
ACP peers, all protected by the security of the TLS channel.

> > > End-to-end communication (inside or outside the ACP) will use the
> > > ACP address, and it could authenticate its IPv6 address (the ACP
> > > address) by using the ACP certificate during end-to-end authentication,
> > > but this spec does not mandate that.
> > 
> > I would like (and will put in my forthcoming COMMENT) to at least mention
> > that there are cases where you could do this sort of check, even though it
> > is definitely impossible in some cases (such as the secure channel) and
> > even if it is not mandated.  I think I can live with not requiring it,
> > though.
> 
> What do you think would be achieved with such a check ? If we write anything,
> we should know (if not write down) the most obvious/relevant attack vector
> prohibited:
> 
> a) I do not quite care about discovering e.g.: a TCP proxy, because that
> to me seems like the most obvious thing we could discover (TLS connection
> end to end via TCP proxy). Indeed, in BRSKI we already explicitly benefit
> from the BRSKI proxy which is a TCP proxy. So i am worried that unqualified
> address comparison would eliminate future positive use of TCP proxies.
> 
> b) Where address check really would be beneficial is something where we
> are missing a key bilding block, so it would at best be written into
> an appendix as a reminder: We need a GRASP authentication block. Example:
> ACP node announces (multicast GRASP) a service. We want to know if that
> service announcement is actually authentic from the ACP node that
> owns the ACP address in the GRASP announcement. If the GRASP message
> had an auhentication extension, we would know that the announcement
> and its ACP address is from the ACP who claims that address.

I think I'm mostly coming at this from the "it's intuitively the Right
Thing to do" based on my accumulated experience.  But let's consider GRASP
-- signing the announcements (e.g., with CMS) could be a use case as you
describe, but I would also like to ask about unicast GRASP.  IIRC it runs
over TLS, but with the current procedures for certificate validation a TCP
proxy could be on the path as you note in (a).  Is the TCP proxy still a
feature for you for this case?

Perhaps we are looking for a statement akin to:

% The presence of the ACP node address prefix in the ACP certificate in
% principle allows for end-to-end authentication of certain interactions.
% However, because the ACP is assumed to consist entirely of trusted nodes,
% the baseline requirements for establishing a secure channel within the
% ACP do not require validation of the peer address against the ACP
% certificate.  In some cases ([example of stuff that uses link-local
% addresses]), such end-to-end validation is not technically possible, and
% for cases where it is technically possible ([example of end-to-end]) the
% baseline requirement is still left flexible so as to allow for the
% introduction of (e.g.) TCP proxies in the ACP topology.  This does not
% preclude individual ACP mechanisms or objectives from making use of
% end-to-end authentication with ACP certificates; such mechanisms might
% for example include signed GRASP announcements.

-Ben