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?