Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt

From: Jari Arkko <[email-masked]>
Date: Wed, 01 Aug 2001 14:47:43 +0300

Hi Vijay,

You wrote the text below yesterday, and I'm trying
to understand what you mean exactly. You can call
me slow but could you help by explaining more?

> >     a) The mip-specific scheme in the -14 draft
> >     b) Standard IPsec usage without piggybacking
> >     c) Fixed IPsec which enables piggybacked and/or
> >         option-specific selectors
>
> B cannot work at all. all packets from tbe MN to the CN
> contain a home address option in a destination options
> header. that means the security association is applied
> to every packet between the MN and CN. so 'B' also needs
> option specific selectors.

Specifically, I'm wondering why the HA option has relevance
in this discussion. They don't need security in the same way
as BUs do. But perhaps the HA options somehow affect the
policy matching in a negative way? However, as per section
8.1 in the -14 draft, CNs generally remove the HA option before
further processing - presumably such as IPsec policy matching
- takes place. Also, section 10.2 seems to indicate that any
policy matching is performed on outbound packets before they
have the HA applied.

So, assuming BUs have their own next header value and are
not piggybacked, it seems that they could match policy
entries such as "protocol=BU, destination=me,
source=peershomeaddress => use sa1". The rest of the traffic
uses protocols such as TCP, which do not match these entries,
hence no security is applied to them.

Jari

---

From: Jean-Michel COMBES <[email-masked]>
Date: Wed, 01 Aug 2001 15:43:16 +0200

Hi Jari,

> hence no security is applied to them.

JMC : I'm happy to hear this !!! I think this is the cheapest and best
solution. I would be afraid to have to pay a high cost to secure MIPv6
while by changing just two little things (ie. BU "nxt header" value and
"no piggybacking"), we could use existing tools ...

Regards
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Aug 2001 18:17:38 +0200 (CEST)

> "no piggybacking"), we could use existing tools ...

Jean-Michel,

That would solve part of the outstanding issues.
But with just those changes you would still need a PKI that includes
both the MN and the CN in order to use route optimization.
It is my understanding that folks one to use route optimizations even when
a PKI with such scope is not available.
(If I'm mistaken about this requirement it would be good to straighten me out.)
 Thus there is a need for something somewhat weaker than a PKI in order
to allow route optimization in those cases. There are several proposals 
that somehow use "return routability" as the criteria for such a weaker
scheme.

   Erik

---

From: Michael Thomas <[email-masked]>
Date: Wed, 1 Aug 2001 09:30:39 -0700 (PDT)

> that somehow use "return routability" as the criteria for such a weaker

  No, you are exactly right. There are two things that need to
  done:

  1) Provide a strong authentication solution where it is
     pragmatically possible
  2) Provide a weak authentication solution where it is 
     pragmatically impossible.

  We have been talking almost exclusively about (1) recently,
  though that doesn't mean that (2) is uninteresting. It's
  day will come too, I expect.

	   Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Aug 2001 09:44:18 -0700

Jari,

for option 'B' i thought you assumed that only piggybacking
was not used. i didnt realise that you also assumed that there
is a new next header value for the BU. then option 'B' would
work.

vijay

---

From: Lars Henrik Petander <[email-masked]>
Date: Wed, 1 Aug 2001 20:04:41 +0300 (EET DST)

> that somehow use "return routability" as the criteria for such a weaker

The use of return routability as a proof of address ownersip has some
limitations, especially on nonswitched broadcast links. 

SUCV and CAM both provide a lightweight solution to the problem of address
ownership, by cryptographically binding the home address to the public key
of MN. This could be used in combination with almost any protocol, which
uses public key cryptograhy, to verify cryptograhically that MN really
"owns" its home address. 

IMHO use of a SUCV is a lot more secure than using return routability.
Also as there is no dependence on a trusted third party, the protocol
should scale well.

Henrik Petander

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Aug 2001 20:00:04 +0200 (CEST)

> limitations, especially on nonswitched broadcast links. 

Agreed. My intent was just to have return routability as an example
of a weaker mechanism. Sorry for not making that clear.

> uses public key cryptograhy, to verify cryptograhically that MN really

While I'm not up on the latest draft I suspect that there can be DoS
issues. For instance, invoking public key crypto operations to verify
the binding between a SUCV address and a key, when a random packet is 
received might be asking for DoS attacks. This can be avoided by in
effect doing a return routability checking handshake before invoking
the public key operations.

   Erik

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 1 Aug 2001 22:23:53 +0300

> a PKI with such scope is not available.

Yes, we absolutely need to have a PKI-less solution for the global
Internet use. (Perhaps also a PKI solution for the Intranet use.)

But this working group already has an ongoing effort to create
such a PKI-less key management solution, and luckily we can
keep the actual BU protection and the authentication/key management
questions separate. Therefore, we are free to choose between
MIP-specific BU protection and IPsec AH independent of how
the key management is solved.

(Of course, it might be easier to get also the PKI-solution if IPsec
AH was used.)

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Aug 2001 21:45:10 +0200 (CEST)

> Therefore, we are free to choose between

You are assuming that it is easy to use IKE to create non-IPsec keys e.g.
for MIP specific BU protection.
Are you sure it is that easy?
(I don't have any data - but I thought IKE was tied to IPsec.)

  Erik

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 1 Aug 2001 13:10:59 -0700 (PDT)

> (I don't have any data - but I thought IKE was tied to IPsec.)
From RFC2409,

   Phase 2 is where Security Associations are negotiated on behalf of
   services such as IPsec or any other service which needs key material
   and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
   exchange. "Quick Mode" MUST ONLY be used in phase 2. 

I thought you would not need IKE, if you need only weak authentication.

-mohan

---

From: Michael Thomas <[email-masked]>
Date: Wed, 1 Aug 2001 13:45:28 -0700 (PDT)

> (I don't have any data - but I thought IKE was tied to IPsec.)

   IKE provides for domains of interpretation (DOI), though
   IPsec (2407) is the only one currently defined. ISAKMP
   provides a fairly general framework which is used by
   the group keying draft as well as KINK. It would require
   a pretty good understanding of 2407, 2408, and 2409 to
   contemplate creating new DOI, not to mention that the
   work would need to be back integrated into ISAKMP
   consumers (KINK, maybe GDOI??). Also, there is a question
   of how the kernel would get the keying information. PFKEY
   (2367) is the current method for many *nixes, but I don't
   know how extensible it is for things other than IPsec.
   An implementation issue for certain, but yet another
   complication.

		Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 01 Aug 2001 13:17:38 -0700

Hello Erik,

I thought that we were going to have to devise a way for all
IPv6 nodes to get security associations with mobile nodes.
Isn't IKE too much to ask from every IPv6 node?  And, yet,
I agree that we should have a way to use IKE to get keys that
would be useful for authenticating Binding Updates.  I just
expected it wouldn't be the universally mandated way.

Regards,
Charlie P.

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 2 Aug 2001 07:35:27 +0300

Charlie, Erik,

> (I don't have any data - but I thought IKE was tied to IPsec.)

I'm trying to make the point here that the BU protection and key
management can be solved in an independent manner. I wasn't
actually thinking that IKE be used to create MIP-specific SAs.
That would also be possible, though it involves some more work.

Instead, I think a much more fruitful approach would be the following:

- CN, MN, and HA nodes implement AH protection for BUs in the manner
  discussed before in this thread i.e. no piggybacking and a new
  next header number. Current IPsec suffices for this.

- CN and MN nodes implement BAKE - or something similar -
  in order to generate keys without a global PKI. BAKE provides
  keys for AH i.e. creates IPsec SAs. We do need to complete
  BAKE in this WG, but I don't think it'll make a difference whether
  it keys IPsec SAs or other kinds of SAs.

- Optionally, some nodes may implement IKE in order to 
  use it for VPNs or for the protection of BUs through a
  corporate PKI. Of course IKE will also be creating
  keys for IPsec SAs.

Jari

---

From: Claude Castelluccia <[email-masked]>
Date: Thu, 02 Aug 2001 09:53:40 +0200

Hello Erik,

Actually SUCVp (the SUCV protocol) described in
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt
considers the DoS issues you've pointed out...

The protocol works as follows:
- the MN sends a msg1 (basically a BU-Hello request) to the CN
- the CN replies with a msg2 (that contains a cookie ...or more precisely a
client puzzle). This msg is sent through the home agent...
- the MN then has to reply with a msg3 that contains the cookie or the puzzle
reply...
- The CN will then only perform the SUCV verification + DH exponentiation (to
derive a SKey) if the cookie or the puzzle reply is correct...

The draft actually contains a fully detailled security analysis of the
protocol...we believe it is pretty complete...
Unfortunatly we  did not get a slot to present it in London ...but we will both
(Gabriel Montenegro and myself) be in London and will
be very happy to discuss with anybody interested in this work...

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Claude Castelluccia <[email-masked]>
Date: Thu, 02 Aug 2001 10:20:32 +0200

> Also as there is no dependence on a trusted third party, the protocol

Hello Henrik...

I of course agree with you ;-)
SUCV does not rely on any trusted third party and scales very well...

SUCVp also uses return routability but not as a proof of address ownership but
rather to avoid some DoS attacks as described in the draft...

BTW SUCVp can also be used to prove the CoA address owernship... this is very
usefull to
avoid address stealing and some DoS attacks (see
.http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt
for more details).

regards,
Claude.

--

---

From: Jean-Michel COMBES <[email-masked]>
Date: Thu, 02 Aug 2001 14:51:58 +0200

Hi Erik,

> that somehow use "return routability" as the criteria for such a weaker

JMC : I totally agree with you. I just want to avoid that PKI-IPsec solution will
be rejected. Today, some people speak about problem of PKI scalability but just one
point : there are more PKI than MIPv6 Mobile in the world :-))

Regards.
JMC.

--

---

From: Jean-Michel COMBES <[email-masked]>
Date: Thu, 02 Aug 2001 14:55:55 +0200

Hi Mike,

>   1) Provide a strong authentication solution where it is

JMC : that are the right words : strong authentication when possible

>      pragmatically impossible.

JMC : agree too

Regards.
JMC.

--

---

From: Michael Thomas <[email-masked]>
Date: Thu, 2 Aug 2001 06:23:52 -0700 (PDT)

> rather to avoid some DoS attacks as described in the draft...

   This really amounts to the same thing. The Diffie-Hellman 
   exchange is being protected by a return routability test
   but since it's the exchange is not bound to trustable
   direct or third party knowledge, the key agreement protocol
   isn't providing any _additional_ authentication properties
   (which is why all of these drafts are subject to MITM 
   attacks, etc.)

   This is why I think that we must make public key crypto
   explicitly optional as I did in draft-thomas-mobileip-ha-cookies.
   They have their use, but their use is in the cpu time/messages
   tradeoff domain, not in the authentication domain.

 > . http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-01.txt
 > for more details).

   I don't understand how you can possibly have "proof" of
   address ownership without either direct or third party
   knowledge of a key to address binding. Perfect forward
   secrecy is only as strong as the initial authentication;
   it doesn't provide additional authentication.

	      Mike

---

From: Jean-Michel COMBES <[email-masked]>
Date: Thu, 02 Aug 2001 15:49:28 +0200

Hi,

Jari Arkko a écrit :

>   corporate PKI.

JMC : or if you want to guaranty no breaks during sensitive communications (eg.
IP telephony)

Regards.
JMC.

> Of course IKE will also be creating
>   keys for IPsec SAs.
>
> Jari

--

---

From: Michael Thomas <[email-masked]>
Date: Thu, 2 Aug 2001 07:57:21 -0700 (PDT)

>   next header number. Current IPsec suffices for this.

   Agreed.

 >   it keys IPsec SAs or other kinds of SAs.

   I'm not so sure here as there's a consideration which
   hasn't been discussed yet (to my knowledge). IPsec and
   other kinds of schemes like it create hard state on the
   nodes. That is, state that cannot be deleted at will by
   either of the hosts without causing synchronization
   problems. It would be nice to have a scheme which allows
   soft state instead. This is not possible with strong
   authentication unless you use public-key digital
   signatures. However, it does seem like it's possible
   with the weaker return routability-based authentication 
   schemes. Given that BU's are soft state, it would be
   highly advantageous to allow for soft state in the weaker
   variety of BU authentication. 

   Indeed, I see no reason to force hard state between the
   MN/CN in general for the very reason that the return
   routability test is, itself, an example of a repeatable
   test which can be used as a means of producing soft state.   
    
 >   corporate PKI. Of course IKE will also be creating

   Right. My main argument here is that if we are given
   the choice between something that has standard key
   distribution methods defined right now, and something
   that does not, there should be extraordinary reasons
   why we'd choose the latter since key distribution is
   such a nightmare.

	  Mike

---

From: Claude Castelluccia <[email-masked]>
Date: Thu, 02 Aug 2001 17:02:45 +0200

>    (which is why all of these drafts are subject to MITM

Hello Mike,

I would be very gratefull if you could explicitly tell us to which MITM attacks
SUCVp
are subject to...
This would be very useful to us.

thanks in advance,

Claude.

--

---

From: Michael Thomas <[email-masked]>
Date: Thu, 2 Aug 2001 08:39:19 -0700 (PDT)

> This would be very useful to us.

Claude, 

What you propose is the security equivalent of a
perpetual motion machine :-) It is well known that
all schemes which do not incorporate
authentication -- either direct or third party --
are subject to man in the middle attack. That is,
if my message goes through an untrusted man in the
middle, it can dup both parties into believing
that they are speaking end to end when they are
in fact speaking through the man in the middle
who can adulter/insert/delete messages.

In the case of MIP, the MITM would likely be a
router, though it's possible there are attacks
from the edge as well. The only way that I can
counter the MITM is to possess a piece of
_independently_ obtained information for which you
can supply some cryptographic transform which
leads me to believe that you are in possession of
the information which binds the request to
whatever you are asserting ownership of (and thus
control). Practically speaking, that means a key,
either asymmetric or symmetric, that I've obtained
securely and *in advance* of the request, either
directly, or by leveraging a trusted third party.

I've not read enough in the SUCV draft to find
exactly where the MITM attack is possible, but if
it is based off of HIP in its oppertunistic mode,
then such an attack is definitely possible (which
I'm pretty sure that Bob would agree). This is not
to say that such opportunistic encryption is not
completely without value; indeed it does a
reasonable job of keeping outsiders out even with
the MITM attack possibility. However, we need
to not fall victim to belief that the security
equivalent of the second law of thermodynamics
can be repealed.

       Mike