>I'm sorry to see that you consider healthy technical
discussions as
>disagreement. Nevertheless, I will just point out one
contradiction in
>your emails and conclude thereafter.
=> A "healthy" discussion should also *stop*
at some point.
Wassim H.
> -----Original Message-----
> From: James Kempf [mailto:kempf docomolabs-usa.com]
> Sent: Friday, August 18, 2006 12:23 PM
> To: Narayanan, Vidya; Wassim Haddad; Dondeti,
Lakshminath
> Cc: Jari Arkko; mipshopietf.org
> Subject: Re: How probable is compromise of an AR? (was:
Re:
> SEND-based protection and related confusions )
>
> Vidya,
>
> Protocol design can mitigate the consequences of a
threat. If
> you want to split hairs, then, yes, the attack based on
the
> threat is what the protocol design is protecting
against.
> I've heard this shorted to "mitigating the
threat", just as
> when people use the short hand term "mobility
management"
> to mean "modification of packet routing to match
changes in
> host topological location".
>
> Perhaps I need to include a "Terminology"
section in my email? 
>
> Anyway, we're not making much progress. It seems we
don't
> agree about much, so this is the last response I'll
make to
> you on this thread.
>
> jak
>
> ----- Original Message -----
> From: "Narayanan, Vidya" <vidyanqualcomm.com>
> To: "James Kempf" <kempfdocomolabs-usa.com>; "Wassim Haddad"
> <whaddadtcs.hut.fi>; "Dondeti,
Lakshminath" <ldondetiqualcomm.com>
> Cc: "Jari Arkko" <jari.arkkokolumbus.fi>; <mipshopietf.org>
> Sent: Friday, August 18, 2006 11:15 AM
> Subject: RE: How probable is compromise of an AR? (was:
Re:
> SEND-based protection and related confusions )
>
>
>
> There is no mitigation to any "threat" via
a protocol design.
> The threat exists and it is about mitigating the impact
of a
> resulting attack (entity compromise, in this case) via
a good
> security protocol. That is the reason security protocol
> designers look at the relevant threats and design
protocols
> to provide maximum protection against attacks resulting
from
> the existing threats.
>
> Vidya
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempfdocomolabs-usa.com]
> > Sent: Friday, August 18, 2006 9:57 AM
> > To: Wassim Haddad; Narayanan, Vidya; Dondeti,
Lakshminath
> > Cc: Jari Arkko; mipshopietf.org
> > Subject: Re: How probable is compromise of an AR?
(was: Re:
> > SEND-based protection and related confusions )
> >
> > > 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
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|