> Oh absolutely. I am all for agreeing, if there is a
consensus, that
> certain threats are noted and considered
"manageable." We are not in the
> business of designing for the non-achievable goal of
"perfect" security.
>
> That said, we also follow certain security design
principles that are
> considered bare minimum, some of which have been
thankfully documented.
>
> One of them is the so called "Internet threat
model." So if the binding
> update is between the MAP and the MN, we can consider
everything in the
> middle as "untrusted" just as that threat
model assumes. This works well
> in that, as long as there is an uncompromised AR
between the MAP and the
> MN, the MN should get service. If a compromised AR
were to be involved in
> key distribution at some point in time, until that SA
expires, the MAP and
> the MN cannot be sure whether there is a MiTM, and
that's not desirable.
>
I guess the point I am trying to make is that it is not
possible to mitigate
the threat of AR compromise by protocol security measures
alone. As long as
the AR can prove its authorization, the authorization with
the MAP will
succeed. The only indication that compromise has occured is
observation of
the AR's behavior. Then its cryptomaterial can be revoked
and it can be
brought offline.
Regarding key distribution, the link between the MAP and the
AR must
naturally be secured, so they need to exchange keys. If one
or the other is
compromised, then as above. Compromise can't be detected by
the security
protocol that proves authorization.
>> In all of this I see the pattern I describe in my
paragraph above. A
> network entity (e.g., AAA, PKI) facilitates SA
establishment between the
> MN and an edge (or closer to the edge) entity. In the
HMIPv6sec design I
> saw the opposite, that alarmed and hence I am engaged
in this discussion.
>
Like I said, I'm not commenting on the security
architecture of the
HMIPv6sec design. My preception is that you believe that it
is possible to
mitigate the threat of router compromise by protocol
security measures, and
I don't believe that is possible.
jak
_______________________________________________
Mipshop mailing list
Mipshop ietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|