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

[Joseph Salowey <[e-mail]>]

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 <
[e-mail]> 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 <
> [e-mail] <mailto:[e-mail]>> 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
> >
> >
> >
>
>