Subject: RE: Review of draft-haddad-mipship-hmipv6-security-04 (RE: [Mipshop] Gauging interest in official WG adoption of IDs)

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 1 Aug 2006 13:14:21 -0700

Hi Suresh,
Please see inline. 

> > 
> > 1. The use of CGAs as described is orthogonal to the 
> problem at hand 
> > and doesn't seem to be addressing any needed security.
> 
> Not really. The public key related to the CGA is used to 
> encrypt the messages from the AR to the MN.
> 

This is true - but, as you see from the other comments below, I contend
that the AR must not be sending any keys to the MAP. 

> > 
> > 2. The DH exchange is unauthenticated and hence subject to 
> MiTM attacks.
> > 
> 
> Again. Not true. The exchange is not subject to MiTM attacks. 
> Since the TPHS option contains the hash of the Ks a third 
> party cannot spoof the MAP.
> 

Hash does not equal message authentication - I've barely caught up with
the email chains after my few days of vacation, but it seems like this
point has been discussed in the thread on DH exchange. 

> > 
> > 3. The solution requires a key to be passed from the AR to the MAP, 
> > which is rather strange - one of the strengths of end node based 
> > mobility management is that the compromise of edge network elements 
> > does not cause redirection attacks. This is directly 
> weakening that aspect.
> 
> I fail to see the redirection attack you are talking about. 
> Can you actually come up with a scenario.
> 

I see the argument that an AR compromise can lead to all sorts of
things. This seems to be coming up often - so, let me take that on a
separate thread.  

> > 
> > 4. The fact that there is key transfer between the AR and 
> MAP implies 
> > an SA between the entities. One of the other strengths of end node 
> > based mobility management is that it doesn't require a mesh of SAs 
> > between ARs and a central entity. This directly weakens 
> that aspect as well.
> 
> It is much easier to set up SAs between the MAP and the 
> limited number of ARs in the HMIP domain rather than between 
> the MAP and every MN.
> 

You are not eliminating the SA needed between the MN and MAP - when the
MN is performing the signaling, a per-MN-MAP SA is needed. No reason to
additionally require an SA between ARs and MAPs. 

> > 
> > 5. The protocol seems to lack replay protection (no liveness checks 
> > between MN and MAP either).
> 
> You are right. There is a possible replay attack when the MN 
> does not receive the BA the first time around and tries to 
> bind again. We will be adding a replay protection mechanism 
> (nonce/timestamp) to eliminate this. There are no liveness 
> checks as you say but I fail to see the relevance to MN-MAP security.
> 

You seem to be confusing replays and retransmissions. They are
distinctly different. A replay attack is where a third entity can
capture a valid message and replay it at a later time successfully.
Without nonces/timestamp, such attacks will be successful. While
nonces/timestamp will fix this problem, it is vital to note that you are
providing replay protection, not retransmission capability with that
feature. 

> > 
> > 6. No reason to tie RCoA to LCoA - RCoA remains the same across 
> > changing LCoAs.
> 
> Yes. But there is nothing in the draft which suggests 
> otherwise. The RCoA-LCoA binding is required for the initial 
> exchange between the MN and the MAP to establish the SA, but 
> not thereafter.
> 

Let's clear up the SA establishment procedure first - we can discuss if
this is needed next. 

Vidya

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

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 01 Aug 2006 17:01:40 -0400

Hi Vidya,
   Please see comments inline.

Cheers
Suresh

> that the AR must not be sending any keys to the MAP. 

Ok. We agree to disagree

> point has been discussed in the thread on DH exchange. 

The idea is that the hash of the Ks in the message provides some 
assurance to the MN that the sender is the MAP (since the AR and the MAP 
are the only other entities which know the Ks, AR compromise aside)

> things. This seems to be coming up often - so, let me take that on a

OK.

> additionally require an SA between ARs and MAPs. 

The protocol allows the MN-MAP SAs to be set up dynamically.

> providing replay protection, not retransmission capability with that

I am distinctly aware of the difference between replays and 
retransmissions. I was talking about a possible replay attack which can 
occur when the MN retransmits the LBU.

> Let's clear up the SA establishment procedure first - we can discuss if

OK.