Thanks, Ben
Let me just comment on possible AI for you, i will do my AI in a few
days when i have more time.
On Thu, Oct 01, 2020 at 03:32:44PM -0700, Benjamin Kaduk wrote:
> I think A.6 is an interesting idea and don't want to drop the idea, but the
> current state of the text in A.6 is better suited for a separate doc than
> inclusion in this one. I suppose I could try to do a shorter rewrite that
> might be a better fit for this doc if you want; let me know.
A separate doc would have to be an actual spec of the mechanism IMHO,
and alas i do not have the time right now to start it (and after
we have an ACP RFC maybe i can also find other WG participants to
contribute ;-)). So i do not want to loose the thought and think an
appendix is the best reminder for the problem and solution directions.
Aka: Yes: If you want to send replacement text, please send it,
and i will replace A.6 with it verbatim.
> > End-to-end communication (inside or outside the ACP) will use the
> > ACP address, and it could authenticate its IPv6 address (the ACP
> > address) by using the ACP certificate during end-to-end authentication,
> > but this spec does not mandate that.
>
> I would like (and will put in my forthcoming COMMENT) to at least mention
> that there are cases where you could do this sort of check, even though it
> is definitely impossible in some cases (such as the secure channel) and
> even if it is not mandated. I think I can live with not requiring it,
> though.
What do you think would be achieved with such a check ? If we write anything,
we should know (if not write down) the most obvious/relevant attack vector
prohibited:
a) I do not quite care about discovering e.g.: a TCP proxy, because that
to me seems like the most obvious thing we could discover (TLS connection
end to end via TCP proxy). Indeed, in BRSKI we already explicitly benefit
from the BRSKI proxy which is a TCP proxy. So i am worried that unqualified
address comparison would eliminate future positive use of TCP proxies.
b) Where address check really would be beneficial is something where we
are missing a key bilding block, so it would at best be written into
an appendix as a reminder: We need a GRASP authentication block. Example:
ACP node announces (multicast GRASP) a service. We want to know if that
service announcement is actually authentic from the ACP node that
owns the ACP address in the GRASP announcement. If the GRASP message
had an auhentication extension, we would know that the announcement
and its ACP address is from the ACP who claims that address.
c) hmmm... what else... drawing blank...
Let me know what you think...
Cheers
Toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
