Subject: [mobile-ip] A less drafty draft

From: Charlie Perkins <[email-masked]>
Date: Tue, 10 Apr 2001 22:53:46 -0700

Hello folks,

We have a fairly complete draft, specifying a method for
establishing a Binding Key between mobile node and
Correspondent Node, available at the following URL:
    http://people.nokia.net/charliep/txt/bke/bke.txt
It is our belief that the protocol in this draft is suitable
for meeting the requirements laid out at IETF 50 by
Jeff Schiller to enable the use of Binding Update messages
between mobile nodes and correspondent nodes.

This draft is also going to be submitted to the Internet
Draft directories.  Comments are, as always, welcome!

Regards,
Charlie P.

---

From: "Phil Neumiller" <[email-masked]>
Date: Wed, 11 Apr 2001 05:04:40 -0500

I had some basic questions on the less drafty draft.

0).  WARNING:  Often security holes and exploits are found in the procedures used
       to implement cryptographically secure algorithms, i.e. the implementation goo is
       the place where the holes will turn up for would be attackers.  Since this less
       drafty draft is indeed implementation goo, it deserves extra careful attention.
       I believe this draft is security work and requires careful cryptanalysis.  Again I
       must ask, is the MIP WG the  most qualified WG in the IETF to perform this duty?

1).  Why is forcing the malicious node onto the routing path between the CN and HA
       so important?  Is this somehow perceived to be harder for the attacker to do?
       What other way could an attacker choose to attack, i.e. this seems like a tautology
        to me (i.e. if you are going to attack you probably want to be mucking with the
        route on the route) [if its not DoS].

2).  If the CN is a MN (does not seem to be ruled out), then why is this routing path
       necessarily "a small part of the Internet"?  Seems like there *could* be a few
       routers between two arbitary points on the planet.

3).  MNs will usually be on the air.   So eavesdropping on "all" the traffic between
      the MN and the CN does not seem like such a chore to me.  Doesn't this put
      all key construction material in the hands of an attacker?

-pdn

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 11 Apr 2001 08:05:19 -0700

Hello Phil,

>      I believe this draft is security work and requires careful cryptanalysis.  Again
>      I must ask, is the MIP WG the most qualified WG in the IETF to perform this duty?

Well, someone has to do it, and sooner is better in my opinion.  Given
recent events, I have no doubt that BKE will get a full security review
before it would have any chance to progress to Proposed Standard.

>      What other way could an attacker choose to attack, i.e. this seems like a
>      tautology to me (i.e. if you are going to attack you probably want to be
>      mucking with the route on the route) [if its not DoS].

If I were an attacker, I'd rather attack from some totally random spot
in the Internet, difficult to detect, and able to be changed to a new
vantage point instantaneously.  The stated restriction makes almost all
such vantage points unworkable.  Having said that ...

Our protocol is NOT vulnerable to random nodes on the path between the
correspondent node and the home network.  Most nodes on that path do not
have any way to discover the random number 'R' which is sent by the mobile
node to the correspondent node in the Binding Key Establishment destination
option.  Such nodes cannot pretend to be the mobile node.  They also cannot
receive the key information from the mobile node, which will be addressed
directly to the correspondent node.  The protocol is vulnerable only to
attackers on the correspondent node's link, and (when the HA->MN tunnel
is unprotected) on the mobile node's current link.

Actually, we'd prefer if there weren't any vulnerabilities to attackers on
any paths. Here, it's worthwhile to keep in mind the goal:
	"Do no harm",
which I interpret to mean that we should not introduce vulnerabilities to
any attacks which do not exist between statically located IPv4 network nodes.
If a mobile node is on its home network, the only vulnerabilities exist when
there are attackers between itself and its correspondent node.  If the mobile
node moves, and uses the BKE protocol, then we have not introduced any further
vulnerability.

>        routers between two arbitary points on the planet.

Agreed.  Let's say there are 15.  That's still a tiny part of the Internet.
But see above, where anyway our vulnerability is much more restricted
than that.  Again, I claim that our solution is much better (and still
computationally very small) than the minimum required solution, reducing
vulnerability even beyond that which is required by "Do no harm".

>       all key construction material in the hands of an attacker?

Key material can be acquired by anyone on the same link as the correspondent
node.  With unprotected tunnels, it puts key material in the hands of anyone
on the same link as the mobile node.  The key material is ONLY to be used
for authenticating Binding Updates, which are ONLY used to enable a
correspondent
node to have efficient communications with a mobile node.

In my view, this is an acceptable risk, less vulnerable than ARP today.

For cases where additional authentication is necessary, we can design
additional protocol.  However, the additional protocol SHOULD NOT be
mandatory for implementation in all IPv6 nodes.  BKE, on the other hand,
SHOULD be mandatory for implementation in all IPv6 nodes.  We have to
build a protocol that is simple, effective, and yet "does no harm".

Regards,
Charlie P.

PS. I boldly adjusted your white space in places to make your text look
    prettier on my screen.  Thanks for using ASCII only in your e-mails :-)

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 11 Apr 2001 09:02:10 -0700

Hello again Phil,

I need to make a clarification to my previous note, which was written
with an unstated assumption.  The assumption I made, was that the mobile
node itself had started the process of creating a Binding Key.

Consider what happens if this assumption is invalid, and an active
attacker resides along the routing path between the correspondent
node and the home network.

In this case, the correspondent node can be fooled into setting up a
security association with the active attacker as follows:

- Attacker sends Binding Warning with IP source address some
  random care-of address (perhaps its own IP address).

- Attacker receives Binding Request on its way from the correspondent
  node to the home network.

- Attacker responds to the Binding Request with a suitably doctored
  up BKE message.

- Correspondent node now believes that it can rely on the BKSA
  supplied by the attacker.

Note that all of this does not introduce any vulnerability not
already present in today's Internet.  Furthermore, we can protect
against usurping EXISTING security associations by simple rules
at the correspondent nodes.  Lastly, if ingress filtering is in
place, the attacker is limited to using a care-of address which
is topologically correct along the restricted routing path.

Thanks again for your consideration of our protocol.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Apr 2001 23:21:58 +0200

=> can you use the standard line length?

   0).  WARNING: Often security holes and exploits are found in the
   procedures used to implement cryptographically secure algorithms,
   i.e. the implementation goo is the place where the holes will turn up
   for would be attackers.  Since this less drafty draft is indeed
   implementation goo, it deserves extra careful attention.  I believe
   this draft is security work and requires careful cryptanalysis.  Again
   I must ask, is the MIP WG the most qualified WG in the IETF to perform
   this duty?
   
=> do you propose to create a new WG or to add a security statement in the
charter? (I believe the second solution is the best one)

   1).  Why is forcing the malicious node onto the routing path
   between the CN and HA so important?

=> because if we restrict the places where the attacker must be
we restrict possible attacks too. And as the MN can be wireless
(mobile = wireless = cellular :-) this is important to reduce the
vulnerabilities with the malicious guy to the MN.

   Is this somehow perceived to be harder for the attacker to do?

=> yes

   3).  MNs will usually be on the air.  So eavesdropping on "all" the
   traffic between the MN and the CN does not seem like such a chore to me.

=> so you'd like to answer to your first point (:-)?

   Doesn't this put all key construction material in the hands of an attacker?

=> no if the HA->MN tunnel is protected and the N2 nonce not available
to eavesdroppers on the MN radio link.

Regards

[email-masked]

---

From: Lars Henrik Petander <[email-masked]>
Date: Mon, 23 Apr 2001 20:15:56 +0300 (EET DST)

Hi all!

Since BAKE allows active attacks on local links using a broadcast medium
that redirect the traffic to the attackers machine, it allows a similar
attack against CNs as a fake icmp redirect. A good example of a vulnerable
host is a MN in its home network, which is likely to be wireless and
eavesdroppable.

Although this vulnerability already exists in IPv4 it might lead to
the disabling of MIPv6 CN functionality in many nodes in the same way as
ICMP redirects often are disabled today. Do we really want to limit the
use of full CN functionality to trusted links? 

I am afraid that any unauthenticated key exchange is likely to suffer from
the same (or a similar) vulnerability. Thus it would probably be a good
idea to make strong authentication of the peers possible by using public
key cryptography, which would allow them to retrieve each other's
certificates from DNS or some other repository and authenticate each other
strongly. In absence of a PKI they could always revert to unauthenticated
key establishment, the use of which should be configurable in CNs.

Regards,

Henrik Petander

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 24 Apr 2001 07:41:29 +0300

Lars Henrik Petander wrote:
> attack against CNs as a fake icmp redirect.

Right.  But only from a limited number of locations within the Internet.

> A good example of a vulnerable

MN's home network is indeed vulnerable, since being located there
allows an attacker to launch an active attack against an arbitrary CN.
The same applies to any attacker at the CN->HA link, the home network
is no different in that sense.  However, even being located at the MN's 
home network should be safe against passive attackers.  However, if you 
have found an attack where it is enough to eavesdrop at the MN's home 
network, please describe it.  That is, there are certain to be attacks
the we haven't thought about.

> use of full CN functionality to trusted links?

I don't have any personal opinions with regard to BAKE.  I just started
from the given design constraints: do no harm (or be as safe as IPv4 is)
and do not require any heavy computations.  The latter requirement 
basically made all PK operations and D-H infeasible.  

What comes to D-H, IMHO the triangular message exchange in BAKE is
_almost_ as safe as D-H, and much cheaper.  (The difference is
that BAKE is vulnerable to passive attackers that are able to
eavesdrop near the CN or both the MN->CN and CN->HA links, while
D-H is not.  I think that there is no difference with regard to
active attackers, but I am not quite sure.)

Authentication and public key operations are a different issue.
I think that something like CAM/SUCV/PBK-ADDRESSES could and 
probably should be added to BAKE as an optional feature.  I just
haven't had enough time to properly think about that yet.  If you
have any suggestions of how to do that, please share them.

> the same (or a similar) vulnerability. 

I agree.

> Thus it would probably be a good
> strongly. 

As I already said above, I mostly agree.  However, my thoughts are still
unclear about the relative benefits and drawbacks of using certificates
vs. implicitly authenticated keys ala CAM/SUCV/PBK-ADDRESSES.

Please remember the underlying authorization problem.  This question
is really not only about knowing who your peer is, but also making
sure that your peer is indeed authorized to create bindings for the
given Home Address.

> In absence of a PKI they could always revert to unauthenticated

IMHO global PKI is an unrealistic assumption.  One issue here is 
whether you want to use BAKE at all if you have properly authorized
public keys.  If you have public keys, you probably could and should
use some other protocol, such as IKE (or maybe HIP :-), in any case,
and leave BAKE or something like that for the case when you don't
have such keys.

Really, the interesting case here is when you don't have properly 
authorized keys, i.e. either no keys or CAM/SUCV/PBK/PBK-ADDRESSES 
like keys.  IMHO, BAKE does quite a good job for the case of no
keys, but more work is needed for the CAM/... case.

--Pekka Nikander

---

From: Lars Henrik Petander <[email-masked]>
Date: Wed, 25 Apr 2001 13:38:24 +0300 (EET DST)

Thanks for your reply Pekka. I may have missed something of the MN - CN
authorization picture as I was not at the IETF meeting. OTOH I'm working
on the authentication side of the MIPL Linux MIPv6 implementation and
would like to see a solution that works also on untrusted links, that is
a solution applicable also to WLAN and similar low cost wireless links.

> the we haven't thought about.

I meant MN in the sense of it being just a CN while it is in its home
network. 
 
> basically made all PK operations and D-H infeasible.  

Probably the MN's will use SSL, SSH or other protocols requiring
similar operations in any case. BAKE is now the only proposed solution
fully without public key operations. 

> active attackers, but I am not quite sure.)

Unauthenticated D-H in itself does not IMHO provide any protection against
active attackers on the routing path, who pose as a MN to the CN. However,
it allows the authentication of the public keys used and thus makes it
possible to at least try an authenticated exchange. If authentication of
the key exchange is not possible, then a policy could be used to decide
whether to allow the unauthenticated exchange.

> have any suggestions of how to do that, please share them.

That sounds complex. I wonder if any one protocol can or should even try
to satisfy the, for now unpublished, requirements and still be applicable
to CNs on untrusted links. Perhaps MN should propose a protocol for
establishing a key in binding warning and CN to approve or disapprove it
in a binding request. A simple key establishment protocol with cookie
protection against DoS attacks + D-H could be used as an alternative to
BAKE or some other similar protocol.

> vs. implicitly authenticated keys ala CAM/SUCV/PBK-ADDRESSES.

I am not yet familiar with CAM and SUCV, but I have mixed feelings also
towards PBK, which seems applicable only to single connections and not
routing in general (you can establish the keys by pinging a CN and
afterwards all traffic to the home address is routed according to the new
binding).

> sure that your peer is indeed authorized to create bindings for the

Yes, that is true and I think that DNS provides a nice way of doing this.
Although with out deployment of DNSSec this approach is
applicable only if MN and CN use the same DNS server.

> IMHO global PKI is an unrealistic assumption. 

Yes, it is currently a farfetched one, but organization wide PKIs are
already deployed and can be used if the key establishment protocol allows
it.

> One issue here is 

I agree with you here, but use of BAKE and similar protocols should be
nevertheless restricted to trusted links or servers that don't care with
whom they are communicating with. For example: we are thinking about
deploying an IPv6 WLAN with Mobile IPv6 support on the university campus
at HUT (definitely an untrusted link). In this case route optimization
with BAKE or PBK would open new vulnerabilities in the wireless devices
which use MIPv6.

BR,

Henrik Petander