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

From: "Tuomas Aura" <[email-masked]>
Date: Fri, 12 Apr 2002 18:11:55 -0700

I do not like the BA/BR authentication. First, do they need 
to be authenticated? Second, the protocol is difficult to 
understand and analyze.

But if BA/BR authentication is needed, this may be as good 
as it gets. 

>      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, j, i)
>      4. CN -> MN(CoA): BA(MAC)
>      5. CN -> MN(HoA): BR(MAC)

>          Kbu = H(K0 | K1)

>          CN -> MN(CoA): MAC_Kbu(BA | HoA | CoA | C2),
>                         ...

Note 1:

I agree that something like this must be done if BA/BR are 
to be authenticated. Without the cookie exchange, an attacker 
could spoof messages 2a and 2b and thus could spoof the value 
of Kbu. Therefore, authenticating BA/BR with Kbu would not 
prove anything.

Note 2:

The cookie exchange in the above protocol solves the spoofing 
problem, at least to some extent. Messages 2a and 2b contain 
the cookies and are therefore difficult to spoof. Consequently, 
the attacker cannot easily spoof the value of Kbu.

However, it will be difficult to explain exactly why the BA/BR 
authentication works and to quantify how strong it is compared 
to the BU authentication.

For these reasons, I am not very fond of the above protocol. 
Unfortunately, I do not immediately see any alternative that 
would give the same security without adding complexity.

Note 3: (rather theoretical)

To get exactly the same strength of authentication for the 
BA/BR as for the BU, the BA/BR should be authenticated with 
MAC_Kba where Kba= H(C0 | C1), not with MAC_Kbu. Clearly, 
this is impossible if the stateless CN does not remember 
C0 and C1, or Kba. But there is a way around this.
CN can remember C0 and C1 in the following way: 

      2a. CN -> MN(HoA): HoT(C0, K0, j, Blob0)
      2b. CN -> MN(CoA): CoT(C1, K1, i, Blob1)
      3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC, j, i, Blob0, Blob1)
      Blob0 = E_Kcn(C0); Blob1 = E_Kcn(C1)  

The correspondent encrypts C0 and C1 with the key Kcn, which 
is known only to itself and sends the encrypted blobs of data 
to MN. MN sends them back for decryption. (The freshness of 
the encrypted Blobs needs to be checked. I'm not sure what is the
best method and whether it is necessary to add even more length
to the messages). 

I do not seriously suggest this change, though. Jari's protocol
is already complex enough. Rather, I would like to see it
simplified, for example, by discarding the BA/BR authentication 
altogether.

Note 4:

The routing-based authentication of CN is not an inherently 
bad idea. This is different from CGA-based authentication, 
which simply does not work for the correspondent (unless the 
correspondent address is also required to be a CGA).

Tuomas

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Apr 2002 04:51:01 +0200 (CEST)

> to be authenticated? Second, the protocol is difficult to 

I think it makes sense to prevent off-path attackers from being able
to confuse the MN by sending CoT/HoT/BA/BR packets.
That should just require a cookie (akin to the sequence number in TCP
SYN packets preventing spoofed SYN|ACK packets).

   Erik

---

From: "Tuomas Aura" <[email-masked]>
Date: Sun, 21 Apr 2002 17:11:31 -0700

I agree. Cookies seems sufficient for this purpose.
Tuomas

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: 17 April 2002 03:51
> To: Tuomas Aura
> Cc: [email-masked]; [email-masked]
> Subject: RE: [mobile-ip] Unresolved issue #3: BA, BR authentication?
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 25 Apr 2002 16:33:59 +0200 (CEST)

> This is an excellent observation! The sequence number works in
> this case as a sort of a weak cookie, which as you point out,
> the attacker doesn't know. Perhaps this could be enough.

I agree with Vijay that the sequence number in the BA is enough.

> Question: in BR, we don't have a sequence number. If the BR
> is more like a binding refresh request, should we add the sequence
> number also there?

For BA it is sufficient to do an exact match to the sequence number
against the last sent BU.

If you put a sequence number in the BR it isn't obvious to me that an
exact match is sufficient.

Case 1: Lost BU vs. lost BA.

	MN sends BU with sequence number 17 and the A bit set. 
	Retransmits it several times. Never receives a BA.
	This could be because all the BUs where lost, or because the CN
	received (at least) one BU but the BA was lost.

	Should the MN expect that a BR contain seq 17 or 16 (assuming 16
	was the last one it got a BA for).

Case 2: BUs without A bit

	If the MN sends BU seq # 15, 16, 17, etc without asking for a BA
	which sequence number should it expect in the BR?

I think these issues appear if a cookie different that the sequence number
is used to filter out spoofed BRs.

  Erik