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

[Joseph Salowey via Datatracker <[e-mail]>]

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. What risks are not being
mitigated?   What modes of operations should not be used?   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.

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?

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?

How long is the ASA nonce supposed to be valid?  How often does registration
happen?

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.

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?

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

6. Denial of service

are there protections in the underlying protocol for denial of service with
respect to Flood(), Synchronize() or any other method?