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 < [email protected]> 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 < > [email protected] <mailto:[email protected]>> 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 > > > > > > > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
