Re: [Anima] Fwd: Secdir last call review of draft-ietf-anima-grasp-api-07

Joseph Salowey <joe@salowey.net> Mon, 09 November 2020 05:25 UTC

Return-Path: <joe@salowey.net>
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 B13B13A11F2 for <anima@ietfa.amsl.com>; Sun, 8 Nov 2020 21:25:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 i4OjdZMnmqly for <anima@ietfa.amsl.com>; Sun, 8 Nov 2020 21:25:23 -0800 (PST)
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 27B043A11F5 for <anima@ietf.org>; Sun, 8 Nov 2020 21:25:22 -0800 (PST)
Received: by mail-qk1-x742.google.com with SMTP id k9so6957691qki.6 for <anima@ietf.org>; Sun, 08 Nov 2020 21:25:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7XjywJ00xJKcTumc9slLzJ/QuDaHQ8E1Ff2UWgQ5K9c=; b=Z3VBQty7l8gZFOq4zlQyHEOrHVaCZOs1ANlc0P3yH1C5Xwxez1K20hVbs8sbnoLauA /qITLPIJH0Apd6ud3QgzXGWVRw1VlfVnhavtlGOFSUccaebipgUHS7NDV6KiiqUuyoTZ QdBZJ+o5MVkYvbNk4fB5Ibl/pVZTLOppDfq8Af6DUnmrc4d5l1+Sdy1jTFnnKrUgz1dC ldJTse5Uu4RvxGsIwV5YXHvIznYIUqrpX+gpYAsSQrVKuM+eDj13jawgqHm52RUnN/N9 22ltH1IxrY+wNhU/n5dIQNijrQHhjnHkw9+7c2GwMKIv0jM0fo2vmNV7NfGdVRGYmdEb N7Mw==
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=7XjywJ00xJKcTumc9slLzJ/QuDaHQ8E1Ff2UWgQ5K9c=; b=gRzoZViSmF7exRh8cV3ALlkXlXVFm7kvFR1mJTQGihmJ7RqIvqNNBRZAxaGZhpJn2s BtGinoSnWQ62ApB6PDTee9LRrahiuXpXkIemZjFx67tKLXW3sIqy2tWOGWp4PI2lV672 a9NVrRN9WdnQOxE7xl9w8WNgm3ZtUzOWRJj5Y/5y1BcrsSzesIzFY9IW5SA2nfwZtbYL g3fpdtXWcfycIa3vUPha9GEWGrAPynYKDPQzrA3/cBcqkJwWOCMMWBXsnmg3h+0Jgs3n 8YgbAKP4W1RKPAcccQKx3vDKCmU63N1516pzB2uhpwi3c8rYGfkYVh8atTus8zNnBTpw u3Ig==
X-Gm-Message-State: AOAM532QZK8oaA/hn7yfaG3ykfrfm/XS/p4pGUvOIjQPuMjrGLzjWilg fJkw93f2kR3bEh5fFrUc/ejVGJAOo2CDdZDWcG0N4A==
X-Google-Smtp-Source: ABdhPJxuT1vPmoQtCl3G8GQWw/32B+fgX/dEQnHI+yPpEKtDA4gjBRL1w17vJ7Kqg0zDwdpVVK9WAcIW/lnHEYc9IaM=
X-Received: by 2002:a37:4948:: with SMTP id w69mr12081542qka.472.1604899521865; Sun, 08 Nov 2020 21:25:21 -0800 (PST)
MIME-Version: 1.0
References: <160381954432.30121.9559007698502161410@ietfa.amsl.com> <b132bb6d-4a5b-5388-6f0d-0f94c71bc51b@gmail.com> <CAOgPGoCBgM-PvMUaQoc0mEwtV0YvaAFeZcUvQAFsg9XqCo6Lgw@mail.gmail.com> <CAOgPGoAroFke8dyCOMyKaAiwHrN_sGguivo8O2Ju-scAE4Q5cg@mail.gmail.com> <6106292a-f2c6-d4f3-9cbc-aafda045cf84@gmail.com>
In-Reply-To: <6106292a-f2c6-d4f3-9cbc-aafda045cf84@gmail.com>
From: Joseph Salowey <joe@salowey.net>
Date: Sun, 8 Nov 2020 21:25:11 -0800
Message-ID: <CAOgPGoD7ABfrqqMwE0UVJCDk7Dq_fDAssdiNifBU6dYvJQDK2Q@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: secdir <secdir@ietf.org>, last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e6c43305b3a5c967"
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/WHOaCSvBWCB9X2rw9P4KAnyzitI>
Subject: Re: [Anima] Fwd: Secdir last call review of draft-ietf-anima-grasp-api-07
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: Mon, 09 Nov 2020 05:25:26 -0000

Thanks Brain,

Explicitly defining the trust model will address most of the comments, and
I think you have dealt with any other outstanding ones below.  I think you
may find it would be better to have a mechanism to establish trust in
individual participants, however I understand that the group has pushed
this to future work.

Cheers,

Joe

On Sat, Nov 7, 2020 at 4:28 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Joe,
>
> A few more comments in line:
>
> On 02-Nov-20 19:02, Joseph Salowey wrote:
> > (Forwarding my response to the rest of the audience)
> >
> > Hi Brian,
> >
> > Thanks for the quick response,  additional questions and comments inline
> below:
> >
> > On Tue, Oct 27, 2020 at 6:58 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> >
> >     Hi Joseph,
> >
> >     Thanks for the review. Comments in line...
> >
> >     On 28-Oct-20 06:25, Joseph Salowey via Datatracker wrote:
> >     > Reviewer: Joseph Salowey
> >     > Review result: Has Issues
> >     >
> >     > I have reviewed this document as part of the security directorate's
> >     > ongoing effort to review all IETF documents being processed by the
> >     > IESG.  These comments were written primarily for the benefit of the
> >     > security area directors.  Document editors and WG chairs should
> treat
> >     > these comments just like any other last call comments.
> >     >
> >     > The summary of the review is Has issues.  The document does needs
> a bit more
> >     > discussion of the security implications.
> >     >
> >     > 1. Authorization
> >     >
> >     > In the security considerations section the document says that
> authorization is
> >     > left for future work.  I would expect that the section should at
> least describe
> >     > what the implications of no authorizations are.
> >
> >     This isn't really an issue for the API itself, but for the
> underlying protocol
> >     and for the ANIMA ecosystem. It's an issue that the WG explicitly
> deferred
> >     (and it's now a chartered work item). Let me quote here what the
> GRASP spec
> >     says in its security considerations:
> >
> >     >>    - Authorization and Roles
> >     >>
> >     >>       The GRASP protocol is agnostic about the roles and
> capabilities of
> >     >>       individual ASAs and about which objectives a particular ASA
> is
> >     >>       authorized to support.  An implementation might support
> >     >>       precautions such as allowing only one ASA in a given node to
> >     >>       modify a given objective, but this may not be appropriate
> in all
> >     >>       cases.  For example, it might be operationally useful to
> allow an
> >     >>       old and a new version of the same ASA to run simultaneously
> during
> >     >>       an overlap period.  These questions are out of scope for the
> >     >>       present specification.
> >
> >     and what draft-carpenter-anima-asa-guidelines says:
> >
> >     >> Authorization of ASAs is a subject for future study. At present,
> ASAs are trusted by virtue of being installed on a node that has
> successfully joined the ACP. In the general case, a node may have mutltiple
> roles and a role may use multiple ASAs, each using multiple GRASP
> objectives. Additional mechanisms for the authorization of nodes and ASAs
> to manipulate specific GRASP objectives could be designed.
> >
> >     That draft is on the verge of WG adoption. The point is that the
> current
> >     trust model is that we trust any node that has successfully joined
> the ACP,
> >     and therefore we trust any ASA in such a node. We should state that
> clearly
> >     in the text.
> >
> >     IMHO it would be out of scope for the API to say more but we should
> add a
> >     reference to the GRASP Security Considerations.
> >
> >     > What risks are not being
> >     > mitigated?   What modes of operations should not be used?
> >
> >     Those are good questions for the WG to look at.
> >
> >
> > [Joe] These are the sort of things I would expect to be described in the
> security considerations.
>
> I meant "good questions to look at when investigating possible
> ASA authorization models."
> >
> > I'm trying to get my bearing in what the current model is here.  In
> particular it seems that any security is applied at the "ACP".
>
> Exactly.
>
> > What is the relationship of an ASA to an ACP node?
>
> We'll try to clarify that in the next version. An ASA runs in an ACP node
> and therefore inherits all the security properties of an ACP node (i.e.
> message integrity, message confidentiality and the fact that unauthorized
> nodes cannot join the ACP).
>
> >
> > Does the ACP provide a security guarantee that it will send a message to
> the correct ASA running on the correct system?  Does it ensure that a
> message received was sent by the correct system?  I couldn't find these
> answers in the security considerations of ACP, GRASP or GRASP API.
>
> The ACP is agnostic about indivdual ASAs, but the ACP is built in such a
> way
> that messages can't miscarry since there is no way for a node to usurp
> another
> node's IP address. The GRASP Session ID ensures that messages are delivered
> to the appropriate peer.
>
> >     > In general leaving
> >     > security items out suggests that the work is not ready for wide
> deployment.
> >     > Perhaps this is OK because the work is informational, but the
> document should
> >     > probably say this.>
> >
> >     Personally I don't think we have left a hole here, because there's a
> well-defined
> >     trust boundary, but we should indeed state that as well as citing
> the GRASP spec's
> >     security considerations.
> >
> > [Joe] Yes please,  defining the trust model would help.
>
> Ack.
>
> >
> >
> >     >
> >     > 2. Authentication
> >     >
> >     > Section 2.3.1.4 discusses the ASA_locator.  How is is the entity
> accessed by
> >     > the locator authenticated?  How does the caller of the API know
> they are
> >     > talking to the right entity?  I don't see any discussion of this
> in this
> >     > document and there is very little in draft-ietf-anima-grasp-15 on
> this.    Is
> >     > there a section in one of these documents I should be looking for?
> >
> >     No, you're not missing anything. The trust boundary is the ACP, and
> that takes
> >     us back to the previous point. If we do decide that we need a
> fine-grained
> >     trust model inside the ACP, we'll presumably need to extend GRASP
> itself
> >     to add some form of authentication option beyond what GRASP over TLS
> can
> >     provide.
> >
> > [Joe] From my understanding the ASA_locator is referencing a remote
> system that the caller of the API is going to interact with. If this is
> true then there must be some way for the local system to make sure that the
> identity of the remote system is indeed the same entity they reference in
> the API.  I would expect somewhere in one of the specifications that there
> needs to be some mapping between the name specified API and the name
> authenticated in TLS (typically in the subjectAlternativeName in a
> certificate), but it could be established in other ways.
>
> No, the GRASP discovery process operates over the ACP so is protected by
> that (e.g. by TLS in a TLS-based ACP, but that's not the only way it could
> be). The discovery process returns a locator and as noted above, that can't
> be usurped, so we're done.
>
> This wouldn't be safe on the open Internet, but we aren't on the open
> Internet. (It wasn't by chance that we developed RFC8799 while working on
> ANIMA.)
>
> >
> >     >
> >     > 3. ASA_Nonce
> >     >
> >     > The ASA nonce is described as a security mechanism.  It is only 4
> bytes long.
> >     > This seems short, making the ASA_Nonce vulnerable to collisions.
> Why is this
> >     > not a problem?
> >
> >     This isn't used on the wire, just locally within the GRASP instance,
> >     so collisions can be excluded.
> >
> > [Joe] OK, thanks.
> >
> >
> >     > How long is the ASA nonce supposed to be valid?  How often does
> registration
> >     > happen?
> >
> >     At the moment, there is no sensible answer to those questions. When
> we develop
> >     the authorization model, we'd definitely have to answer those
> questions and maybe
> >     the nonce would have to be replaced by a crypto object.
> >
> > [Joe] OK.
> >
> >
> >
> >     >
> >     > 4. Session Nonce
> >     >
> >     > Are there security implications of revealing the session nonce to
> the caller as
> >     > suggested in section 2.3.1.7?  Could it allow for the ASA to bypass
> >     > authorization if it knows this value?   Perhaps forming the nonce
> from the
> >     > underlying session ID is not the best guidance?  Also it seems the
> underlying
> >     > protocol session ID is only 4 bytes and collisions are likely and
> may be a
> >     > problem for the protocol.
> >
> >     No, the collision risk is avoided because the session nonce includes
> the
> >     ACP IPv6 address of the session originator. We should explain that
> >     more clearly.
> >
> > [Joe]  I still have the question of whether the nonce should be revealed
> to the API caller or left internal to the implementation.
>
> If a caller is running multiple parallel sessions, there needs to be
> *something* in the API; it's exactly the same as a socket in that respect
> (in fact, in an implementation, it must map 1:1 to a socket).
>
> An ASA can't usurp itself. The only risk I can see is that one ASA usurps
> another
> one in the same node by somehow stealing a session nonce. Given the trust
> model,
> is that really a concern? (An implementation of GRASP could choose to use
> a process ID as an extra check, I suppose.)
>
> >
> >
> >
> >     >
> >     > 5. Error Codes
> >     >
> >     > In general, the list of API codes in the appendix is not described
> in the API.
> >     > It seems they should be.  Some of the error codes seem related to
> >     > authorization, which is out of scope?
> >
> >     Our hope was the the WG could move faster on that topic, but the
> >     incredible delays on BRSKI and the ACP made that impossible.
> >     Our idea is certainly that register_asa() and register_objective()
> >     should include authorization in the longer term.
> >
> >
> > [Joe]  I think it would be helpful for the API spec to list the valid
> error codes for each call.
>
> We can annotate the error code list and get the same effect with less
> clutter.
>
> Regards
>     Brian
>
> >
> >
> >     > It seems that some of the error code could lead to disclosure of
> information,
> >     > for example:
> >     >
> >     > notYourASA       7 "ASA registered but not by you"  might reveal a
> valid nonce
> >     > from an invalid nonce
> >
> >     Hmm... I don't think so. Let me glance at the code...
> >
> >     The only place where I found that error code useful was in
> deregister_asa()
> >     and that doesn't return anything else. It could be used in an
> exhaustive
> >     search attack to deregister an ASA, but in the current trust model
> that
> >     doesn't seem like a significant risk.
> >
> >     >
> >     > 6. Denial of service
> >     >
> >     > are there protections in the underlying protocol for denial of
> service with
> >     > respect to Flood(), Synchronize() or any other method?
> >
> >     There are recommendations about rate throttling for relaying GRASP
> Flood and
> >     Discover multicasts, which should confine any multicast abuse to a
> single
> >     link-layer segment. That's one good reason for using link-layer
> multicast only.
> >     We also have recommendations for exponential backoff in the GRASP
> spec, but
> >     of course a malicious sender could ignore those. In any case we can
> put a
> >     specific pointer to that subsection of the GRASP Security
> Considerations.
> >
> >     DoS against the Negotiate or Synchronize parts of GRASP seems to be
> like
> >     any other client/server protocol. I'm not sure what we can say in the
> >     API spec about that. In my implementation (which is not intended to
> be
> >     production quality) I've simply put finite queues for all the request
> >     handlers, with silent discard if the queue overflows.
> >
> >     We'll collate updates to all reviews after the LC expires.
> >
> >
> > [Joe] OK thanks.
> >
> >
> >     Thanks again
> >         Brian
> >
> >
> >
>
>