Subject: [Mip6] Secure binding update..

From: Warodom Werapun <[email-masked]>
Date: Sun, 07 Dec 2003 21:27:57 +0700

Currently, Is Binding Update(BU) message security base on IPSec ?
I had read IPSec specification.  It seems to abstract information only.
I mean, IPSec doesn't tell me, which algorithm is used to encrypt or 
sign mesgs.
It provides only framework (protocol) and modes (transport and tunnel).
I'm not sure that I understand correctly, if I'm wrong, could you please 
correct me.

For those reasons, I like to applied Indentity Base Signature to BU 
message for protected the fake BU message sending by adversary nodes.

Do you have any ideas?  I'd like to got some advises.  Thank you.

Best regards,

-- 
Mr. Warodom  Werapun
School of Graduate Studies, Computer Engineering
King Mongkut's Institute of Technology Ladkrabang
Chalongkrung Road, Ladkrabang Bangkok THAILAND 10520

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 07 Dec 2003 10:04:57 -0800

have you taken a look at 
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt?

---

From: Warodom Werapun <[email-masked]>
Date: Mon, 08 Dec 2003 12:03:50 +0700

Thank you Vijay, I look at mobileip-mipv6-ha-ipsec-06.txt.  I have some 
questions following below.

Q1.  On Page 11 , Section 4.1 ,   It said that "  Manual configuration 
of IPsec security associations MUST be supported. The configuration of 
the keys is expected to take place out-of-band, for instance at the time 
the mobile node is configured to use its home agent. " 

What is encryption or signature algorithm used in security association?  
because it said only using out-of-band to configure the key and use IKE .

Q2.  On Page 14, Section 4.3 ,  " When securing Binding Updates ....  
SHOULD use the Encapsulating Security Payload (ESP) [4] header in 
transport mode and MUST use a non-null payload authentication algorithm 
to provide data origin authentication, connectionless integrity and 
optional anti-replay protection"
     
I'm still don't know, what 's encrypt or sign algorithm that I should 
use?  I know only mode of IPSec which i use.      

I already saw in Example configuration on Page 20,   " mobile node SAD: 
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): source = home_address_1 
& destination = home_agent_1 & proto = MH ".   It shows the structure 
SA1 but I still don't know which encrypt+sign algorithm use in SA1 (again).

Those are all points that I focus to propose the suitable algorithm 
applied with BU messages but I'm not sure, that I asked above is 
important because mobileip-mipv6-ha-ipsec-06.txt never talks to encrypt 
or sign alogrithm used in IPSec.

Could you please advice me, I don't like to do the useless research.  I 
wish to be the one of this community who help the mobile IPv6 working 
more securely.

Best regards,
Warodom

Vijay Devarapalli wrote:

>> I'm not sure that I understand correctly, if I'm wrong, could you 
>> please correct me.
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 08 Dec 2003 14:30:05 -0800

there are a bunch of drafts/RFCs produced by the IPsec WG which
talk about the various algorithms/cryptographic suites to support
for IPsec and IKE. here are a couple of them.

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-04.txt

there are more at http://www.ietf.org/html.charters/ipsec-charter.html

in general when you use IKE, the mobile node and the home agent
negotiate what cryptographic algorithm to use. Mobile IPv6 only
can say use ESP in transport. in addition it can also say whether
authetication/encryption/both are required. beyond that, it is
upto the IPsec implementation to figure out what to do (which
includes what algorithm to use).

when it comes to manual configuration, there is no such
negotiation. the algorithm to use has to be manually configured
on both the mobile node and the home agent.

Vijay

Warodom Werapun wrote:
>     I'm still don't know, what 's encrypt or sign algorithm that I 
> should use?  I know only mode of IPSec which i use.

---

From: Warodom Werapun <[email-masked]>
Date: Sun, 21 Dec 2003 23:09:55 +0700

After I read IPSec-draft, I found this URL: 
http://www.math.ohio-state.edu/~silver/bibliography/mobileip
It's "Securing MIPv6 Binding Updates Using Address Based Keys (ABKs)" 
and already expired.

I don't see   " 
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-04.txt , 
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-04.txt
and there are more at 
http://www.ietf.org/html.charters/ipsec-charter.html"   talking about 
Address Based Keys.

This internet-draft wasn't interesting?  How do you think about ABKs?

Best regards,

-- 
Warodom  Werapun
PGP:  http://plex.coe.psu.ac.th/myPGP.txt

---

From: Jari Arkko <[email-masked]>
Date: Sun, 21 Dec 2003 22:17:02 +0200

> This internet-draft wasn't interesting?  How do you think about ABKs?

ABKs were considered as a potential mechanism to secure BUs to
correspondent nodes, among other techniques. The current RR
technique was the one chosen for the base spec, however.

ABKs do not have anything to do with IPsec SAs.

--Jari

---

From: Warodom Werapun <[email-masked]>
Date: Mon, 22 Dec 2003 09:47:15 +0700

> ABKs do not have anything to do with IPsec SAs.

In ABKs draft said that  
(http://www.math.ohio-state.edu/~silver/bibliography/mobileip)
   
    RR has a weakness that if an attacker can eavesdrop on two links 
(HA-CN and MN-CN), then it can send a fake BU successfully. CGA with an 
initial round of RR is susceptible to this attack. The ABK protocol does 
not have this weakness: an attacker who can eavesdrop on two links still 
cannot send a MAC'd BU. However, if an attacker Okazaki, S. 
Informational [Page 12]  Internet Draft Securing BUs July, 2002 can 
alter messages on both the MN-CN and HA-CN links, then it is possible to 
establish a fake BU with CN. As mentioned above, both RR and CGA (with 
an initial round of RR) are susceptible to a similar attack.

    Why current RR technique was choosed?  How RR technique protected 
this problem?

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Dec 2003 09:28:08 +0200

>    Why current RR technique was choosed?  How RR technique protected 

Some of the background has been discussed in
http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-02.txt

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Dec 2003 09:19:15 -0800

Warodom,

ABKs require some minimal amount of infrastructure, not as much as a PKI,
but more than RR. The base algorithm for securing binding updates in Mobile
IP requires that two random nodes on the Internet without any access to
common infrastructure can participate in route optimization, since there is
currently (and for the forseeable future) not likely to be any common
infrastructure available in the general case (specific deployments of Mobile
IP where security infrastructure already exists, for example by licensed
spectrum cellular providers, may be exceptions).

As in any security problem, the task of securing Mobile IP route
optimization is a matter of identifying the attacks together with their
risks and coming up with solutions that address the most likely attacks and
those with highest risk. The flaws you cite in RR were deemed acceptable
risks in that they do not make Mobile IPv6 less secure than Mobile IPv4. In
addition, the most likely place where a man in the middle attack could occur
is on the last hop, by performing attacks on RFC 2461 and RFC 2462 Neighbor
Discovery. In response to this possibility, the SEND working group was
formed and is almost complete with a protocol that will prevent address
spoofing and router spoofing on the local link. Man in the middle attacks on
other parts of the routing infrastructure are, of course possible, but less
much less likely and much easier to defend against.

There are some other problems with ABK as a general solution to securing
route optimization for Mobile IP, and with the technique as outlined in the
draft you cite. With some additional work, it might be acceptable in
specialized deployments, but there is a definite tradeoff against existing
PKI methods, since the infrastructure for PKI methods is already partially
available while the infrastructure for ABK would need to be deployed from
scratch, and the two methods of securing route optimization share many
characteristics.

            jak

---

From: Warodom Werapun <[email-masked]>
Date: Thu, 25 Dec 2003 10:44:24 +0700

How ABKs protect man in the middle attack? 

In 6.1.2 Man-in-the middle attacks?

	" However, if an attacker Okazaki, S.
Informational [Page 12] Internet Draft Securing BUs July, 2002 can
alter messages on both the MN-CN and HA-CN links, then it is possible to
establish a fake BU with CN. "

Because ABK1 - ABK4 does not sign, so adversary can alter messages 
following above. How this draft solve this problem?

     And another question, the process to success BU messages for mobile 
node, mobile node sent ABK1 - ABK6.  Although, Identity based cryto was 
based on ECC (that used small key size more than RSA) but if we compare 
ABK1-6 (of course plus IP Header overhead for message) with 1 message 
using tradition PKI (such as RSA, attach with certificate).  Tradition 
PKI consume less bandwidth than ABK, is it?   (coz i think that 5 
messages * IP header quite bigger than 1 mesgs plus certificated ).  And 
if we get out ABK1-ABK4 by using method => mobile node send binding 
update attached with certificated of system paramater.(still using 
Identity based cryptography)  Is this better than your proposed method?

Best regards,
Warodom  Werapun

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Dec 2003 09:48:00 -0800

Warodom,

As I stated in my email, there are a number of problems with ABK for BUs as
specified in the draft you cite.  Due to lack of interest by the Mobile IP
community, Docomo Labs USA has dropped work on ABK for BUs at this time. If
interest revives in the future, we may reactivate the draft.

            jak