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

Joseph Salowey <joe@salowey.net> Mon, 02 November 2020 06:02 UTC

Return-Path: <joe@salowey.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4473A0DCF for <secdir@ietfa.amsl.com>; Sun, 1 Nov 2020 22:02:45 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 t5VuW0cDzyLo for <secdir@ietfa.amsl.com>; Sun, 1 Nov 2020 22:02:41 -0800 (PST)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 483773A0DDC for <secdir@ietf.org>; Sun, 1 Nov 2020 22:02:41 -0800 (PST)
Received: by mail-qk1-x743.google.com with SMTP id a64so7274124qkc.5 for <secdir@ietf.org>; Sun, 01 Nov 2020 22:02:41 -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=pf74MjAF4rxypfS2bsxzUgARUpPF+ZliKzRx7ucAhJ4=; b=LIhZBE1sQoM28JSxDn8OpHJdke058FfE34jLgsMlZ1jK8Dn4azx99mNQ2YzEcjMWfC 1ekGKaKkZpdlstxQvyJUbj0e3DeklOeWcxaX4er77f/F/jlFJshHXGf4DBRm1LersrGp nulhkXFhwFCAN+900tgkG9hDXSa/86204+sEqVtjuUgWfbP7ytKRilyE0WOopRpqAwL4 DEohvBm4PL0k+tQtrmjxLg3W3dQup1KEuh0N5m/H/nixWsJkRAa4Wzl5voySfzUOs++0 aJpMKYCdl6AdxOlZ3yCRULZNMEVkYYjAV/arOwa113TuWw6avaNGGMTQMt4bZ9X863bz tzhA==
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=pf74MjAF4rxypfS2bsxzUgARUpPF+ZliKzRx7ucAhJ4=; b=jk07UcJglCw8Zfgcr+vO8am8PgBhs0CQqBWXPLrNbpAnvotl59eNgI3WBYZIDqU0Zh UxuS/HCOQvGzZo7dlh61iI4W3pHK/yptlqSHsOXJKAA7N874m04lypO753k5k0GIvqCF tlNA2x2JbrP5Tr3F9wZYgbKEPmiDzF2uDsm655qQ5neFIxwf6Sg2DHbTB/SrYFcKh8Oq XLEDFoY5x9GeMogv36G7UTQaT6zPtxyBQzKrYYBKaEnB1KdasMNGmIiK3QEEG9LOx6v0 ixbJzZJsvu/elURijLI7qUYLLh+eWAc96b01JjsMyzAdPTydbeNtk+MFUJNVgGTSNPV9 TPKw==
X-Gm-Message-State: AOAM531UNlBEYGBTcSNzrvxfjluU+uEHYY5qIHJphkgZuhRvEcBwCwQ1 A+fN0EA3c0TAiCQH7bTKemYp37ejF/qWI4i97x98/g==
X-Google-Smtp-Source: ABdhPJxJCBQToA7IRN99XpqLKmQX6uCnQUN/4JF0DMGw9BJRkgxQ/m3GQ/y+A4edO1j1Vkb8LiVa+Oet242Z3f+Ewtg=
X-Received: by 2002:a37:76c7:: with SMTP id r190mr13080871qkc.416.1604296960184; Sun, 01 Nov 2020 22:02:40 -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>
In-Reply-To: <CAOgPGoCBgM-PvMUaQoc0mEwtV0YvaAFeZcUvQAFsg9XqCo6Lgw@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
Date: Sun, 01 Nov 2020 22:02:29 -0800
Message-ID: <CAOgPGoAroFke8dyCOMyKaAiwHrN_sGguivo8O2Ju-scAE4Q5cg@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, secdir <secdir@ietf.org>
Cc: last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006d27f005b3197ecd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Ja5BcRGl2mdTbDcXbskIa0a9COQ>
Subject: [secdir] Fwd: Secdir last call review of draft-ietf-anima-grasp-api-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 06:02:52 -0000

(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> 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'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".  What is the
relationship of an ASA to an ACP node?

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.


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


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


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



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


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