ekr> 2. I didn't find the security model very clear. As I understand ekr> things, basically anyone on the network who has ACP credentials is ekr> trusted to engage in negotiation with you, so, for instance, if you ekr> want to get parameter X, then you basically just trust whoever on the ekr> network offers you X. is that correct? That seems like it needs to be ekr> very explicitly called out. And if that's not true, then I don't ekr> understand the spec.
bc> That is the trust model, but really as an explanatory matter I think it
bc> belongs in draft-ietf-anima-reference-model rather than here. I will
bc> add a few words in the High Level Deployment Model section and/or the
bc> Security Considerations.
I am increasingly uncomfortable with leaving things like this.
There are a number of things that we could do as GRASP extensions:
1a) M_SIGNED: could be container that encapsulates a GRASP message into
a COSESign1 structure to indicate who sent the message.
1b) M_MULTISIGNED: a be a container with a COSESign structure in which
every passing node signs as it goes through.
2) transport end to end, run it over TLS or something. Might be implied or
might
require a M_STARTTLS message.
3) hop-by-hop, with some kind of M_TUNNEL message, or using COSE Encrypt
messages with relaying on the outside.
I think that all of these things could be ASA specific, but I think that ASA
should not have to re-invent the wheel here, but can use the GRASP "kernel"
(aka "libgrasp") to do the right thing.
My request for the Chairs to put this on the "re-chartering" list for later
on, but to discuss with ADs now so that some of the GRASP or framework work
could say something aobut "future work".
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
