Subject: Re: [mobile-ip] Authenticating BU and PKI

From: Pekka Nikander <[email-masked]>
Date: Tue, 01 May 2001 06:49:45 +0100

> Pekka Nikander a écrit :
> ....
> > In this particular case (authenticating BUs), secure reverse
> > DNS would be the "right" PKI for the purpose.  However, getting
> > it running seems like quite an obstackle, and even if we had it,
> > authenticating a random MN
> 
Jean-Michel COMBES wrote:
> I think you wanted to say 'random CN'

No, I really meant 'random MN'.  Unless I have understood something
completely wrong, the "MIPv6 security case" is looking for a solution
where the CN can reasonably believe that the MN sending BUs is the
"right" MN, i.e. the one that is authorized to set up a binding
for the specific home address.  For some specific attack scenarios, see
e.g. draft-nikander-ipng-address-ownership-00.txt

> > Just to clarify: A simple infrastructure with some global CA
> > providing simple certificates is not enough and/or feasible.  The
> > certificate must include the home address, and the issuer of
> > the certificate must be authorized to issue certificates
> > concerning that particular home address, etc.
> 
> JMC :
> A possible solution would be to use the HA.
> Explanation :
> When the MN receives tunneled packets from its HA, the MN should send BU to
> the CN (MIPv6, section 10.3). This is the _FIRST TIME_ that the MN will send
> a BU to a CN and will have to set up SA to authenticate BU. So the HA knows
> when the MN will have to set up IPsec parameters ... why don't we use this
> fact ? When the HA encapsulates packets to the MN, it could send MN's
> certificate to the CN too, including the Home Address that the MN can use
> (ie. resolving the authorization problem) with the BU.

I am sorry but I don't understand what you have in mind.  You are right
that the first time the MN sends a BU to the CN it must set up an SA.
The problem is HOW to set up this SA if there is no prior security
relationship between the MN and the CN.  How does the CN know that the
MN is really the MN whose home address is the one given?  I am sorry,
but I just don't understand what you are trying to say.  Would you
please clarify?

--Pekka

---

From: Jean-Michel COMBES <[email-masked]>
Date: Wed, 02 May 2001 12:52:00 +0200

Pekka Nikander a écrit :

> No, I really meant 'random MN'.

JMC :
So, what are you calling 'random MN' ? What are the differences with 'not random
MN' ?

>  Unless I have understood something
> for the specific home address.

JMC :
I don't totally agree with you. Yes, there is an authorization problem but, in my
mind, the "MIPv6 security case" is looking for a solution where MN sends BU to
'random CN' (ie. big servers like yahoo) which must manage too many SA and BU.

>  For some specific attack scenarios, see
> MN is really the MN whose home address is the one given?

JMC :
With not using the HA ... (see below)

>  I am sorry,

JMC :
Regarding authorization problem, I'm trying to explain that HA knows always :
- when the MN will send the first BU to a CN and so will set up IPsec SA with it
- what is the Home Address that the MN must use

So in using HA, a possible scenario could be :

1. CN sends packet to MN's Home Address
2. HA intercepts it
3. HA tunnels it to the MN's Care-Of Address / HA sends security informations to
the CN (and why not to MN too ...)

I am enough clear ? BTW, sorry for my poor english :-))

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: Pekka Nikander <[email-masked]>
Date: Wed, 02 May 2001 12:16:29 +0100

...
> So, what are you calling 'random MN' ? What are the
> differences with 'not random MN' ?

In my terms, a 'random NM' is someone the CN does not know and
therefore cannot authenticate, and a 'nonrandom MN' is someone 
the CN knows and therefore can authenticate.

...........
> 'random CN' (ie. big servers like yahoo) which must manage too many SA and BU.

Right, we also have the DoS and performance problems.  But they
are not specific to MIPv6.  From my point of view, they are
just design constraints, not part of the actual problem.

..............
> - what is the Home Address that the MN must use

Right.  The HA knows that.  But who tells the CN which HA to use?
The MN.  How does the CN know whether it can believe the information
or not?  One answer is by involving the HA in the check.  That is
exactly what we do in BAKE.  Thus, I don't any more understand what's
the problem we were discussing about.  And given your detailed
explanation....
 
> 3. HA tunnels it to the MN's Care-Of Address

.... this is exactly what happens in BAKE.  And it happens without
any public keys.  My problem is that I don't see what is the value
of adding unauthenticated public keys.  I don't see much, if any.

--Pekka

---

From: Jean-Michel COMBES <[email-masked]>
Date: Wed, 02 May 2001 16:10:11 +0200

> the CN knows and therefore can authenticate.

JMC :
I don't understand ... this is the HA that sends informations ...

> or not?

> One answer is by involving the HA in the check.

JMC :
Agree.

>  That is exactly what we do in BAKE.  Thus, I don't any more understand what's the
> problem we were discussing about.

JMC :
About delivering, securely, informations about the MN to the CN and so solving
authorization problem too.

>  And given your detailed explanation....

> of adding unauthenticated public keys.  I don't see much, if any.

JMC :
I didn't see how BAKE resolves the authorization problem you mentioned in your
latest messages

JMC.

--

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 02 May 2001 18:43:23 +0100

> I don't understand ... this is the HA that sends informations ...

Even if so, IP source address spoofing is easy.  If the HA sends
a packet to the CN, how does the CN know that it really came
from the HA?  You cannot assume that there is some security association
between them, since there can't be, yet.

--Pekka

---

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

Pekka Nikander a écrit :

> Even if so, IP source address spoofing is easy.

JMC :
agree

>  If the HA sends
> from the HA?

JMC :
the CN doesn't need to know that the informations come from HA (or another
home network entity such as AAAH, etc.)

>  You cannot assume that there is some security association

JMC :
agree ... but sending MN's certificate doesn't need to have a SA. The
certificate is signed and so CN can verify information authenticity.

JMC.

--

---

From: Alexis Olivereau <[email-masked]>
Date: Thu, 03 May 2001 14:28:06 +0200

> certificate is signed and so CN can verify information authenticity.

Then the CN needs a PKI to check and use the certificate, so here we are
with the same problem again...

Alexis

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 May 2001 09:18:34 -0700 (PDT)

> between them, since there can't be, yet.

   The CN can form the HA's address by forming a 
   Home Agents Anycast address as described in -13.
   As for how do you know that the HA is sending
   the information -- just as well as the CN knows
   that the MN is sending the information. Meaning,
   to the degree you trust the integrity of the
   routing system, you can trust replies from the
   MN's home agent about as much as replies from
   the MN itself.

	  Mike

---

From: Jean-Michel COMBES <[email-masked]>
Date: Fri, 04 May 2001 12:20:32 +0200

> with the same problem again...

JMC :
... of course, if using PKI is a problem

JMC.

--

---

From: Damien Routier <[email-masked]>
Date: Fri, 04 May 2001 13:33:36 +0200

> ... of course, if using PKI is a problem

I think that using a PKI is a problem since a new certificate must be
published each time a MN gets a new CoA and the CA/RA must check that
the CoA is rightfully claimed before publishing the certificate 

am i completly wrong ?

Damien Routier
Motorola Research Center - Paris

---

From: Lars Henrik Petander <[email-masked]>
Date: Fri, 4 May 2001 15:23:29 +0300 (EET DST)

> the CoA is rightfully claimed before publishing the certificate 

Partly, as you would normally want to prove the ownership of the home
addresss and the certificate would bind the home address or FQDN
to a public key. You would need a new certificate only in the case of
renumbering or changing your domain name. Of course in the case of a
previous router acting as a temporary HA for the old CoA, you would still
need to prove the ownership of your previous CoA.

Regards,

Henrik Petander

---

From: Jean-Michel COMBES <[email-masked]>
Date: Fri, 04 May 2001 14:38:35 +0200

> the CoA is rightfully claimed before publishing the certificate

JMC:
No, if the certificate contains the Home Address and not a Care-of Address.

--

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 04 May 2001 18:26:24 +0100

> need to prove the ownership of your previous CoA.

There is one more complication.  It is not enough that the 
certificate contains the Home Address.  It is also necessary
that issuing the CA can be trusted to state the home address right, 
i.e. that the CA is _authorized_ to issue certificates that contain
that particular home address.  Determining whether the CA is
indeed authorized or not is not necessarily that easy.  Basically,
the CA must inherit its authority from the ultimate authority, IANA.
Thus, IANA should act as the root CA certifying other CAs.

A FQDN would do only if we had fully secure reverse DNS, and 
we don't.  On the other hand, if we had fully secure reverse 
DNS, we wouldn't need the separate certificates since we could
use the secure reverse DNS to look up the key based on the home
address.  Why a secure forward DNS is not enough is left for 
an exercise to the reader.

--Pekka Nikander

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 09 May 2001 11:23:40 +0200

Hello Henrik,

As explained in
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt,

it might also be useful to prove the ownership of the CoA...

regards,
Claude.

--

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