Subject: Re: DH exchange (Re: [Mipshop] Review of draft-haddad-mipship-hmipv6-security-04)

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Aug 2006 10:16:05 +0300 (EEST)

On Mon, 31 Jul 2006, Lakshminath Dondeti wrote:

> At 03:25 PM 7/31/2006, Wassim Haddad wrote:
> >On Mon, 31 Jul 2006, Lakshminath Dondeti wrote:
> >
> ><snip>
>
>
>
> > >
> > > I see problems with that key delivery, for instance, the MN has no
> > > way of knowing who sent the Ks it receives, or whether the entity
> > > that sent the key is live or not.  What are your thoughts on those issues?
> >
> >=> The Mn can know who sent Ks in the same way as it can know who sent the
> >RA message.
>
> Ok, works as long as the RA messages are signed and include a
> nonce/TS as per SEND.  My mistake.  Thanks.

=> I hope you will keep this particular issue now out of the discussion as
I've mentioned in my first email to you that it is "misleading".

> > > Next, how do you expect the key Ks to be used?  All I see in the I-D
> > > is that the MAP sends a hash of Ks in a BA to the MN.  I am not sure
> > > what the hash of Ks is supposed to achieve.  Could you please explain
> > > the properties of that design?  Thanks.
> >
> >=> The hash of the key is sent by the MAP in the BA message to allow the
> >MN to detect if the BA message is valid or not. However, this is clearly
> >not enough and an authentication is needed and has been added to avoid
> >potential issues in case the MN misses the BA message and re-sends a BU
> >message.
>
> Good.  So, the hash of the key is being removed in the revised design?

=> Not removed. Look at it just as  being the first line of defense. the
authentication is the second line. Having the hash helps the MN decide
immediately if the message is worth validating or not.

> > > Finally, can you elaborate the notion of the SEND-based key delivery
> > > used for "just during the first BU/BA message?"  I think I have
> > > already explained that the compromise in the design is exploitable as
> > > long as the SA derived thereof is in use.
> >
> >=> It means that after establishing the bidirectional SA, Ks is removed
> >from the MAP BCE. I don't see how you can exploit such design excpet if
> >the AR is compromised in which case the harm goes beyond such attack.
> >Peraps you can explain.
>
> A couple of things here.  First, yes, the AR compromise issue looms
> of course.

=> it looms of course but SEND has been designed to counter such threat
(to some extent of course which I consider sufficient in our case).

> Parking that for the moment, the second issue is
> unauthenticated DH exchange.  You said earlier that that is being
> fixed in the revised design.  I will look forward to that.

=> OK

> > > > > I have a related question.  Given that you are working with a limited
> > > > > threat model and given that the problem of malicious/compromised
> > > > > routers is a concern in some networks, are you suggesting that
> > > > > MIPSHOP would work on another solution for HMIPv6 security to address
> > > > > a more common/generic threat model?
> > > >
> > > >=> IMHO, we are not working with a limited threat model. There
> > is a compromise
> > > >which is based on SEND (without SEND it would have been
> > impossible to use it).
> > >
> > > We can agree to disagree.
> >
> >=> OK. Hope the new security consideration will make it clearer and we
> >won't have to agree on disagreeing.
>
> We can discuss again once the new draft is published with the threat
> model, revised design and revised security considerations.  One
> thing, I will ask you guys to consider is what happens when an AR is
> compromised.

=> IMHO, there is no need to talk about MAP service in this case especially
that the AR has also the task to deliver the RA message(s) sent by the MAP(s)
to the MN AND to add one parameter to the message(s) in order to enable the MN
select the right MAP. The damage is beyond what you're mentioning below.

> Sure when an AR is compromised, all kinds of things
> might go wrong, but what if an MN moves away from that AR (after
> noticing lack of or substandard service)?

=> Moving away may not be enough to get MAP service!

Regards,

Wassim H.

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 02 Aug 2006 04:41:20 -0700

>I've mentioned in my first email to you that it is "misleading".

Wassim,

I am not trying to mislead anyone.  Folks on this list are very smart 
and not easily misled!

>immediately if the message is worth validating or not.

Trying again ...  Inclusion of the hash of a key provides no proof to 
the other party.  It does not serve as any kind of defense.  Suppose 
Alice sends a message and a hash of a key it shares with Bob.  Eve 
can change the message at will and include the hash of the key Alice 
shares with Bob.  Bob wouldn't be able to tell whether the message 
originated with Alice or not!

Furthermore, including the hash of the key is very dangerous.  As 
Suresh and you wrote in these threads, you are now going to include a 
hash and a MAC.

Suppose the MAC is based on the same hash function.  Then the 
adversary has sufficient information to calculate the MAC from the 
hash of the key you are making public.  Including the MAC along with 
the hash of the key renders the MAC useless.  Apologies if this is 
harsh, but your security protocol design choices puzzle me, to say 
the least!  Please remove the hash of the key from the protocol.

>(to some extent of course which I consider sufficient in our case).

Trying again.  From 3971, Section 9.2.4 "
SEND does not protect against brute force attacks on the router, such
    as DoS attacks, or against compromise of the router, as described in
    Sections 4.4.2 and 4.4.3 of [22].
"

And that is ok in case of SEND.  If one of the parties to a security 
protocol is compromised, there's little one can do.  In case of 
HMIPv6, the parties to the security protocol are an MN and a 
MAP.  The AR is an entity in the middle.  We need the AR to route 
packets etc., but we don't *need* it to assist in SA establishment 
between the MN and the MAP.  If we can somehow avoid having the AR as 
the key distributor, we will be mitigating the possibility of the AR 
getting compromised.

Now that does not rule out using Cryptographically generated IDs or 
addresses to establish an SA to protect HMIPv6 bindings.

regards,
Lakshminath

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 2 Aug 2006 15:21:27 +0300 (EEST)

> originated with Alice or not!

=> Fully Agree. That's why the message are now authenticated.

> Suresh and you wrote in these threads, you are now going to include a

=> I see what you mean.

> the least!  Please remove the hash of the key from the protocol.

=> No need to be puzzled! Wait for the next version.

> between the MN and the MAP.

=> I've already mentioned to you that the AR in HMIPv6 plays a critical
role in enabling the MAP service as it is used in forwarding the RtAdv
message from the MAP and assisting the MN in selecting the right MAP. So
this is clearly "not just an entity in the middle" as you can guess.
I'll let you guess what it means compromising an AR.

Regards,

Wassim H.