Subject: RE: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication?

From: "Tuomas Aura" <[email-masked]>
Date: Mon, 15 Apr 2002 04:25:46 -0700

Jari Arkko wrote:

> How about this: we don't provide any authentication of 
> the CN in the sense that all the messages be tied to each 
> other in some manner. But we provide a simple send cookie 
> - return cookie for each of the request - response pairs 
> in the protocol. We also delete the MAC field from the BA 
> and BR, and only keep the response cookie.

Yes, I was almost going to suggest this. 

The advantage of simple cookies instead of a MAC for the 
BA/BR "authentication" is that the protocol and its 
limitations are much easier to understand. The disadvantage 
is that the simple cookie mechanism is clearly a little bit 
less secure. I'm not yet sure which solution is the best one 
but the simple cookie mechanisms looks much cleaner.

I challenge everyone to compare the following alternative 
protocols and explain to themselves the exact differences 
between them.

(1) Jari's protocol:
     1a. MN(HoA) -> CN: HoTI(HoA, C0)
     1b. MN(CoA) -> CN: CoTI(CoA, C1)
     2a. CN -> MN(HoA): HoT(C0, K0, j)
     2b. CN -> MN(CoA): CoT(C1, K1, i)
     3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC_Kbu, j, i)
     4. CN -> MN(CoA): BA(C2, MAC_Kbu)
     5. CN -> MN(HoA): BR(C2, MAC_Kbu) 
     Kbu= H(K0 | K1)

(2) Protocol (1) without the cookies C0 and C1. 
     1a. MN(HoA) -> CN: HoTI(HoA)
     1b. MN(CoA) -> CN: CoTI(CoA)
     2a. CN -> MN(HoA): HoT(K0, j)
     2b. CN -> MN(CoA): CoT(K1, i)

 (3) Protocol (1) without MACs on BA/BR. 
     4. CN -> MN(CoA): BA(C2)
     5. CN -> MN(HoA): BR(C2)

Here is my analysis of the above protocols:
Clearly, (1) is the most secure one. BA/BR are 
authenticated with the same or almost the same 
strength as the BU. The curious thing with protocol 
(1) is that removing the cookies C0 and C1 from 
messages 1a/b and 2a/b makes the MAC_Kbu in BA/BR 
completely worthless. Without the cookies C0 and C1, 
the attacker can spoof messages 2a and 2b and thereby 
decide the value of Kbu. Therefore, the simple cookie 
mechanism of protocol (3) without the MACs in BA/BR 
is at least as secure as protocol (2). 

Obviously, the choice is between protocols (1) and (3). 
Currently I prefer (3) because I think most people 
will never understand why protocol (1) is slightly 
better. (I barely do myself.) I believe that the added 
security of protocol (1) is not worth much if the 
majority of protocol engineers never understand it.

If someone is in favour of protocol (1) instead of (3), 
I challenge them to prove that protocol (1) is 
equivalent to protocol (4) below. A formal proof 
might influence my preferences. 

(4) Protocol (1) but BA/BR authenticated with Kba.
     4. CN -> MN(CoA): BA(C2, MAC_Kba)
     5. CN -> MN(HoA): BR(C2, MAC_Kba) 
     Kba= H(C0 | C1)  

I think protocol (4) gives the same level of 
routing-based authentication for BA/BR as we already 
have for BU. I think this is fairly obvious. Note, 
however, that protocol (4) is not a realistic option 
because the correspondent would have to be stateful 
and remember either C0 and C1 or Kba.

Tuomas

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Apr 2002 14:34:46 -0700

Before going ahead, we need to separate BA and BR. BA is
sent immediately after the RR/BU messages. BR is sent much
later (in fact just before RR Binding is about to expire).
According Jari, section 11 is going to recommend a cookie 
lifetime (for C2) which is much less than the RR Binding 
Lifetime. Your C2 would have expired long before the 
binding expires.

C2 can be used for BA, but not for BR, IMO.

regards
Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Apr 2002 15:01:38 -0700

> Lifetime. Your C2 would have expired long before the 

Is this necessary? It would be good if the lifetime of the RR 
would suffice to do multiple handovers. Don't the cookie
lifetime and RR lifetime have to be the same for this to be so?

It would also be useful if the MN could do RR somewhat prior
to the BU, then be able to issue BUs as needed. This avoids
having the prerformance of the posthandover routing update
change depend on the security step.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Apr 2002 01:32:31 +0300

> C2 can be used for BA, but not for BR, IMO.

Cookie lifetimes that we have been talking about so
far have been the CN cookies K0 and K1. The lifetime
of these needs to be limited, to limit "future" in
the future attack.

The cookies from the MN, C0, C1, and C2 however are
an independent matter. What is the right lifetime for
them? Obviously it doesn't make sense to have a lifetime
for C0 or C1 that is longer than the retranmission failure
timeout.

C2 could have a lifetime that simply matches the BCE lifetime.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Apr 2002 01:35:34 +0300

> lifetime and RR lifetime have to be the same for this to be so?

The CN cookies K0 and K1 will have a specific lifetime, the
exact value of which has been under debate. This cookie
lifetime is the time period during which you must at the latest
send your BU. Another time period is the maximum allowable BCE
lifetime, which extends from that time onwards.

> change depend on the security step.

Yes. And the intention is to allow some lifetime for the CN
cookies so that this, fast movements, and reuse of cookies
for multiple bindings can be done.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Apr 2002 16:26:41 -0700

> C2 could have a lifetime that simply matches the BCE lifetime.

That makes sense. Thanks. The lifetimes for C0/C1/C2 should 
be the same BCE lifetime.

And for K0, K1, I still think we can have the same lifetime 
as BCE lifetime, without additional harm.

thanks
Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 18 Apr 2002 18:50:02 -0700

Hello Tuomas,

> majority of protocol engineers never understand it.

I think that the advantage of having MAC_Kbu
(even without C0 and C1) versus having C2 alone
is the attacker has to grab K0 and K1 sent towards
different IP addresses. With C2 alone in BA, it is
sufficient if he gets hold of C2 sent to an IP address.
I agree with you that having C0 and C1 in MAC_Kbu
for BA should be considered. So..

> and remember either C0 and C1 or Kba.

Well, what if

K0 = MAC_Kcn (HoA | Nj | C0 | 0)
K1 = MAC_Kcn (CoA | Ni | C1 | 1)
Kbu = H (K0 | K1) (as before), and BA includes
MAC_Kbu,

and the MN supplies C0 and C1 in BU ?

The downside is it adds 8 extra bytes whether or
not BA is desired by the MN. Since the sequence number
in BU can be used in place of C2, the overhead is 4 bytes.

Regards,

-Rajeev