Subject: Re: [Anima] some comments on -- draft-ietf-anima-grasp-01

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 09:49:41 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> Yes, I suspect that there is something here.
    >>
    >> There is a transitivity of trust that GRASP will have to deal with if the
    >> ASAs do *not* have access to the private key for the device.  I think that
    >> SIP did it right, explaining how the SIP proxies interacted, while not saying
    >> too much about how/what they did.

    > I don't expect either the ASAs or GRASP to have access to the private
    > key. Aren't we leaving that in the hands of the ACP?

I don't want the ASAs to have access to the ACP's private key either.
That might mean that the ASA needs to have it's own private key, and that the
Device private key (which is the ACP key) might need to be used as a sub-CA
key to sign the ASA.

    >> Channel binding may involve the two ASA cryptographically connecting the
    >> communication they have at layer "5" with the security provided at layer 3.
    >> It can be as simple as each end asking the layer-3 for the hash of the public
    >> keys used to secure the channel 3, and then sending that in-protocol to establish
    >> that there is no MITM.

    > OK, but for that GRASP is just a carrier. It would have to be the ACP, that
    > created the secure channel, that provides the hash. We still have an
    > unused protocol option called DeviceID - are you saying that we
    > actually need it?

I'd have to look at DeviceID to figure out if it is appropriate.
GRASP would have to carry the channel binding contents.  But, as GRASP is
operating hop-by-hop, that might not be correct, it's the ASAs that need to
establish ASA-to-ASA trust.

    >> It may be that GRASP will have to *explicitely* support
    >> a trusted MITM because multi-hop GRASP messages will be necessary before
    >> stable addresses are available.

    > I don't see how that would work without a PKI.

Exactly.

    >> Yes, it could be done.
    >> We can use the enrolled certificates to bring up a multicast key manager like
    >> rfc3830, but I'd like to know why we need it...

    > I'm worrying about the unsolicited (flooding) synchronization that we bolted on.
    > I don't know how to secure it. My understanding is that DTLS+multicast==mess.
    > (Unicast replication, the next point, would fix it.)

Yes, we don't have any DTLS for multicast, DICE failed to define a way to do
this, and removed it from their scope.  It's why I'd prefer to to do
everything over the ACP, and why I suggest that the initial insecure
discovery does not to be GRASP.

    >> The end result is that the appropriate inter-ISP ASAs that need to do things
    >> communicate with each other.  I suspect that it isn't just A3/B2 that need to
    >> talk, but rather and ASA on NOC-A and needs to talk to an ASA on NOC-B, but
    >> that it may well need to know something about the Interconnection topology.
    >>
    >> (I'm trying hard not to make this specific to DiffServ...)

    > That would be a fine use case. Yes, I agree that multiple ACPs are not excluded
    > by the laws of physics. Whether there's a real advantage over ad hoc TLS is
    > another question.

I think that we need to have a inter-ISP use case document so that we can
figure out if the security is correct.  Would be nice to have a contribution
From an operator here that actually uses non-degenerate DSCP code points.
{With my operator hat on (AS26227, AS26413), we always used a single EF code
point, which all of the upstream ISPs had the same as.}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-