Subject: [mobile-ip] Additional comments on draft-arkko-mipv6-bu-security-00.txt

From: Erik Nordmark <[email-masked]>
Date: Mon, 12 Nov 2001 17:01:19 +0100 (CET)

Jari,

I have some comments on draft-arkko-mipv6-bu-security-00.txt
which I didn't get to write down in the last exchange on this draft.

Section 6.4 talks about having a configuration knob to allow
unsecure BUs. I think this is a big mistake. Instead the WG should
develop some BU solution that can give some security comparable to
today's IPv4 security.

Piggybacking ...

The term "piggybacking" isn't necessarily well defined. At least some
folks have jokingly used it for the L2 ability to send multiple frames
once the medium is acquired.

I don't know if the best is to hijack the term "piggybacking" or to define
a new one. Assuming the former there has been three forms
of piggybacking discussed:
 - end2end binding update specific piggybacking
 - sending link only generic piggybacking
 - end2end generic piggybacking (being able to send two IP payloads in
   one IP packet)

I think it would be fruitful for the WG to compare and contrast the above.
Some of the arguments for and against BU specific piggybacking 
might actually help drive consensus towards the other forms of piggybacking.

The text in section 7.5 about when to use piggybacking doesn't go into
the difference between two important cases:
1. a new CN is sending packets to the MN and they get tunneled from the HA
2. the MN moves and has some CNs in the binding update list

Some text in the 3rd paragraph seems to only apply to #1. It says
"In this situation one packet beeds to be routed through the home."

Without knowing something about the behavior of the transport and application
protocol behavior it seems like in case #2 the MN must more or less immediately
send a BU, whereas in #1 it could wait for an arbitrary amount of time since
packets will still reach the MN through the home agent. [I'm assuming that the
"update previous default router" might not make sense given that I haven't see
a careful security analysis of this in the BU context.]

Section 8.3 says "... fourfold increase in the size of the packet increased
the amount of time spent by 33%." and later points out that this when going 
from 62 to 4*62 bytes, which reads a bit funny.
Clearly a fourfold increase from 1Mbyte to 4Mbyte has a larger increase.
Thus adding "small messages" or saying "fourfold increase from 62 bytes"
would flow better.

Section 8.6 says "In the use of existing IPsec ..."  but doesn't mention
that IKE would need to establish a SA using the Home Address by sending packets
to the Home Address. So while this doesn't change any packet formats it does
introduce a small behavioral change in an IKE implementation I think.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Nov 2001 12:31:03 +0200

> develop some BU solution that can give some security comparable to

I agree! I have recently come to the conclusion myself that
we should not allow unsecure RO at all, and as a minimum should
require one of the weak auth protocols.

> might actually help drive consensus towards the other forms of piggybacking.

Yes.

> 2. the MN moves and has some CNs in the binding update list

Right. I'll take this in account.

> introduce a small behavioral change in an IKE implementation I think.

Wouldn't this work the same way as any TCP or UDP application, i.e.
to them the CoAs are invisible?

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Nov 2001 13:18:45 +0100 (CET)

> to them the CoAs are invisible?

I assumed 8.6 was related to using IKE/IPsec to secure BUs.
In this case, unless you assume that the certificate used by IKE somehow will
indicate that the holder of the cert "owns" a certain home address,
I think such an approach needs to rely on return routability.

Thus the IKE packets, even when there is a binding cache entry, needs to
go through the home agent when exchanging packets with the home address.
Otherwise it might be possible for an attacker on a link
where the MN used to be (i.e. that can intercept packets send to the old CoA
just after the MN left) to use IKE (with some random certificate name) to
create a SA that will be considered to be the MN.

   Erik

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Nov 2001 15:30:13 +0200

> create a SA that will be considered to be the MN.

I think this is an interesting issue, and we need some
further discussion before we have explored it fully.
My personal current belief is the following.

First, in general when we use "strong" authentication
we typically bind the authentication to some trust
root. You don't accept a VPN connection in just because
the other guys has a cert, there has to be some
chain of trust from that cert to you (not counting
opportunistic encryption ideas of course). Hence
an attacker can't just use a random certificate name.

Second, there are two approaches to using local PKIs:
One, you use it to define the set of Good Guys as
distinct from Bad Guys i.e. everyone else. For instance,
the Sun engineering department might have a VPN where
all engineers have certificates and can access all
services, regardless of where they are. Here, the
emphasis is on defining the good guys and trusting
them for (almost) everything, not just BUs but also
NFS traffic etc. For this purpose current PKIs
and IKE/IPsec are well-suited. In our example, if
we use the 6.4 approach on a local network to protect
all traffic then this would be my assumption that
we are doing.

The other approach is to use PKIs as a tool define
*what* various entities may do. This is generally
a less used approach and there may not be enough
tools around to do everything necessary. However,
on the particular case of IP address ownership
there is a field in X.509 certs to store one or
several IP addresses. Implementations are also
checking for the identities in the certs wrt. to
real identities. So, in theory you could
use this to declare the particular node must use
a particular address. However, I'm not sure how
practical that approach is given DHCP, frequently
changing static addresses, and the extra management.

If we had SPKI and not X.509, the address ownership
would be a lot easier to solve.

I'm not sure about the value of return routability with
strong authentication. If you really do authenticate
through some root, then this buys some protection
against a good guy turned to a bad guy. If you had
the IP address in the cert, you didn't add any value.
If you do not authenticate through some root, then
the whole strong authentication was useless, and you
could have achieved the same with just a return
routability test.

In conclusion, I think we can easily do the 
strong authentication in closed networks, but
you have to assume everyone's included in the
CA's trust is trustworthy. Other options also
exist, but are propably not very desireable.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Nov 2001 08:31:13 -0800 (PST)

I agree with Jari's analysis of the
authentication/authorization distinction below,
but it might prove useful to consider first
principles here, especially in light of Erik's
hindsight draft.

My understanding of IPsec is that it is a means of
enforcing access control which may be bound to
cryptographic mechanisms. That is, IPsec's first
step is to match an incoming packet to an access
control policy (SPD), and decide whether it should
admit or deny the packet's movement forward. For
entries which require a cryptographic policy, the
enforcement is accomplished by translating the
(effectively) static policy of the SPD into an
active entry in the SADB for some finite lifetime.
This translation can happen in two ways: either
statically by having the host manually create SADB
entries, or dynamically using a key distribution
protocol like IKE or KINK.

In both cases, what is important is the flow
classification step. The flow classification in
IPsec is much like flow classification elsewhere,
ie the normal 5-tuple. As such, what IPsec checks
on incoming packets is the source, destination,
protocol and abstracted transport layer ports.
There may be others, but they aren't important for
this discussion.

So when we talk about identity, we're talking
about what credentials are necessary to cause the
SDP's policy to be translated into active SADB
entries. For manual configuration, this is easy;
sneakernet is your identity module. For dynamic
establishment, it is whatever credentials the
policy module demand for that SDP rule. That might
be a preshared key, a signed X.509 certificate, or
a Kerberos credential. Thus the procedure is that
the presentation of given credential causes a
given policy entry to instantiate a SADB entry.
Then, subsequent packets will be subjected to the
cryptographic policy in the SPD of that 5-tuple
identifier.

Thus, it seems to me that the identity is linked
pretty closely to the actual presented IP address.
This gets somewhat murkier when you have
wildcarded SPD entries, but as Jari points out,
this is still useful for Bad Guys/Good Guys
filtering. If you cannot make that sort of broad
classification (say, users are not trustworthy),
you are forced to make either your policy or your
credentials very fine grained. That is, they need
to explicitly match a very fine grained policy
(eg, this credential matches this 5-tuple). With
fine grained policy comes provisioning issues. One
could have a complete enumeration of 5-tuple to
credential in the SPD, but this would be rather
onerous. Thus as Jari points out, it might be nice
to have the credential itself carry the
authorization information so that the SPD rule can
be relatively simple, where the construction of
the 5-tuple is based on the authorization in the
credential. How well IPsec actually provides for
this right now, I'm not sure -- I tend to believe
that Good Guys/ Bad Guys is the least common
denominator since that's generally all you need
for VPN's.

Mobile IP complicates this picture. While it's
pretty straightforward to fix the problems that
were in previous mipv6 drafts, IPsec's flow
classification rules are only limited to the same
5-tuple. That is, it matches off of *CoA*, not
home address. One implication here is that new
CoA's require new SADB entries to be established.
While this is certainly possible, it doesn't seem
especially optimal. There are two possible ways to
make this more efficient: add the ability for the
IPsec selector to consider the Home Address, or to
put the home address back into the source address.
I should point out that *everything* else that
classifies off of 5-tuples is in the same quandary
as IPsec, such as diffserv and intserv flow
classifiers. I'll also note that multihoming
presents a simliar quandry, so this entire
question needs to be considered with that issue in
mind as well; it's possible that the ultimate
culprit here is basing anything off of the classic
5-tuple, and that maybe we need an identity layer
ala HIP, or maybe prefix-less source address for
the 5-tuple classification.

So the question in my mind is why the CoA was
chosen over the home address for the source of the
IP packet from the mobile node. The main reason
I've heard is to play well with RPF checks.
However, recent discussion puts its utility in
some doubt: even if I pass RPF checks, I could
conceivably put any home address option I feel
like in the HAO thus defeating source spoofing
checking. Also: if the HAO needs to be bound to a
particular binding update to prevent this, then I
wonder why the HAO needs to be sent _at all_ since
the binding cache could record the home address
and do the substitution locally, rather than via
the protocol.

So what's the punchline for the 1% of people still
reading this? I think placing the CoA into the
source address causes many unforseen problems and
its stated goal of friendliness to RPF is
trivially defeated given the current formulation.
As such, I think that all of these protection
mechanisms should be reconsidered so that in the
end we have a solution which plays well with other
protocols, and is capable of providing useful edge
policing of source spoofing. It should be noted
that RPF is but *one* way to achieve that, and it
has known imperfections.

	  Mike

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 Nov 2001 18:30:02 +0100 (CET)

> an attacker can't just use a random certificate name.

Agreed.

> all traffic then this would be my assumption that

OK.

> changing static addresses, and the extra management.

I agree this is just a theoretical thing.
I have a hard time understanding how IP addresses in X.509 certs would
work in practice. How does the CA verify that the person requesting the
cert in fact "owns" the address?
How does the CA get notified when that entity no longer owns it
e.g. due to a whole site being renumbered?

For the first question the CA could use return routability at the
time of asking for the Cert, or it could try to track down and verify the
address delegations from the registries and down to the machine.
But that doesn't provide a mechanism for the CA to detect changes.

> would be a lot easier to solve.

How? Anything I can read to learn how SPKI is different in solving
this issue?

> could have achieved the same with just a return

I can envision combinations such as "only allow route optimizations for
folks that are minimally trusted by having a cert signed by X or with
a cerificate name *.example.com" but still verify return routability
to deal with potential bad apples in that large set of entities.

There are other cases where a (local) PKI can be used to do authorization
such as "allow incoming telnet if certificate name is *.example.com"
"allow nfs is certificate name is *.eng.example.com".
That works fine with X.509 certs.

The difference in MIPv6 is that we need to authorize not for broad classes
like telnet vs. nfs vs. no access, but instead authorize to speak on behalf
of a single IP address. This can of course be solved configuring an access
control entry for each IP address as in
	cert name [email-masked] IP address 2000::59:a00:20ff:feec:f5bc
but that obviously doesn't scale. But it is the logical equivalent of the
"nfs" and "telnet" authorization.

> exist, but are propably not very desireable.

Kind of like firewalls - hard outside and soft inside!
I'm hoping we can do better.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 Nov 2001 18:50:51 +0100 (CET)

> pretty closely to the actual presented IP address.

Yes, once you have created the SPD entry you've effectively tied whatever
cert or manual keying that was used to an IP address identity.
But my concerns are how this relationship is established when using
certs in IKE (although I suspect IKE vs. son-of-IKE doesn't make a difference
here).

> especially optimal. 

I think the existence proof of MIPv6 implementations based on
the I-D using IPsec indicates that this can be avoided - just
make sure that the SADB and SPD lookups occurs on the content of the
Home Address Option instead of source address.

Doesn't IPsec VPNs with IPinIP tunneling work the same way with
the outer IP addresses ignored and the inner IP address used for lookups?
[Looking at my laptop VPN config as I type this it appears to not be the
case - the SADB entries are for the outer IP addresses. This is something
that needs to be understood for "hindsight" idea to use tunneling.]

> and do the substitution locally, rather than via

I think it still needs to be sent for robustness. Without it certain
bugs like having the wrong HoA for a CoA will cause silent TCP checksum
errors. Thus explicitly checking and sending an ICMP error when
there is a mismatch is more robust. I think this is needed to allow the CN
to "loose" a BCE (garbage collect a BCE or crash+reboot)
and still be able to send a useful error message back.

> trivially defeated given the current formulation.

Which we need to fix, right? Or are you assuming we can continue to
allow unverified HoA options?

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Nov 2001 15:17:05 -0800 (PST)

> cert or manual keying that was used to an IP address identity.

   Note that this isn't quite the same thing as saying that
   you "own" the address. It's more like saying "if you have
   this credential, I'll let you use this SPD
   entry which will allow the packet to advance".

 > certs in IKE (although I suspect IKE vs. son-of-IKE doesn't make a difference

   Yes, I agree, this is an issue. For the Home
   Agent I don't think it's too much of a
   stretch make an equivalence class between the
   SPD entry and the binding update; it's sort of
   like saying that it blocks via access control
   all binding updates which aren't attached to
   a (authenticated) SPD entry. This allows it 
   to prevent hijackers of its subnet by putting
   up a barricade before the binding update
   manages to get to the soft squishy heart of
   binding management code.

   Now there's an interesting question of how
   that translates to a correspondent node that
   also wanted to use IPsec. I _suppose_ that 
   it could work equivalently, but I'd be a little 
   wary about it's scaling in the SPD. Of course,
   we're already wary about that, so maybe the
   answer is that it's left as an exercise to
   the developers who want that capability :-)
   
 > Home Address Option instead of source address.

   I don't think that RFC 2409 has any mention of
   HAO's, so what you're positing isn't what exists.

 > that needs to be understood for "hindsight" idea to use tunneling.]

   This is an interesting point. I forget which
   one it uses to filter on egress. It might even
   be both!
 
 > and still be able to send a useful error message back.

   I think this needs to be discussed further
   because requiring a binding update to trust
   a Home Address option seems to imply that
   that your soft cached state of bindings is
   getting a lot harder. Ie, if my cache entry is
   evicted, the CN will stop honoring the HAO,
   which will also pooch TCP connections...

 > allow unverified HoA options?

   I'm not sure. The internet itself doesn't deal
   well with source spoofing, and RPF is an
   imperfect beast at best. It looks like all
   we've done with the HAO is move the problem
   around, so maybe we ought to consider the larger
   picture.

		Mike

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 22 Nov 2001 09:51:50 +0100 (CET)

>    manages to get to the soft squishy heart of

I think the home agent is easy - it would need to have an explicit
list of the MNs that it might serve in any case as far as I can tell.
Thus for the home agent to know that a given manually created SA or
a certificate name can perform binding updates for a given Home Address
is easy.

>    the developers who want that capability :-)

But how would the CN know what SPD entries to use?
How would it be told to allow BUs for Home Address X by somebody
using certificate name Y?

>    HAO's, so what you're positing isn't what exists.

I said implementations - not specifications.
Yes, this is a very important distinction in this case.

The fact that there exists implementations means it can't be an
unsolvable problem and I read your mail as heading down that path.
Perhaps I misread ...

>    which will also pooch TCP connections...

Who said that?
The MN would need to get an error indicating back from the CN that doesn't
honor the HAO. THen the MN can either 1) reverse tunnel through the HA
or 2) perform a new BU with that CN - when it receives a BAck it is safe
to start sending the HAO again.

>    around, so maybe we ought to consider the larger

Ingress filtering is only one part.
I've exchanged some mail on the mobile-ip mailing list (with Pekka Savola
I think) about ITRACE and the IPPT (upcoming BoF).
If unverified HAO are allowed we need to understand to what extent they
make ITRACE and IPPT more difficult or perhaps impossible.

   Erik

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 22 Nov 2001 22:04:40 +0200

> How? Anything I can read to learn how SPKI is different in solving

Well, one way to explain is to say that both SPKI and KeyNote2
allow the access control list to be included into the certificate,
so to say.  In this respect both SPKI and KeyNote2 have the same
level of expressing power, even though in some other ways KeyNote2
is more expressive.

I guess the old I-D by Matt Blaze is still relevant, even though it
doesn't address this specific problem directly.

http://www.crypto.com/papers/draft-blaze-ipsp-trustmgt-XX.txt

--Pekka

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Nov 2001 12:28:11 -0800 (PST)

> level of expressing power, even though in some other ways KeyNote2

   I know this is pretty far afield, but I have a hard time
   reconciling how you could scale a PKI based authentication/ 
   authorization scheme with longish lived certificates, with
   the ever increasing realization that IP addresses (or at least
   their prefixes) should be viewed as transient. To work properly,
   you'd want certs with lifetimes roughly equivalent to the
   lifetime of addresses, which I would think shouldn't be more
   than a day or two maximum. Issuing signed certificates that
   often makes me shudder at what CA could keep up with a large scale
   deployment...

		Mike

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 23 Nov 2001 10:20:35 +0100 (CET)

Agreed.

Continuing further afield ...

I'm getting more and more convinced that if we want a solution which
 - depends on a global infrastructure like a PKI, 
 - provides fine grained control (i.e. not just allow everybody with a 
   *.example.com ceriticate names to perform a BU for anybody), 
 - which can tell us that the MN in fact owns the home address,
then current CA/PKI doesn't cut it - some other type of
infrastructure would be needed.
(Note, I'm not arguing MIPv6 should depend on such an infrastructure
or that such an infratstructure should be built. I'm just trying to
understand the security properties in the whole design space ...)

A possible such infrastructure (not arguing that it should be built) would
be to 
 - DNSsec secure all of the ip6.arpa tree
 - store certificates or public keys in the ip6.arpa tree for each IPv6
   address (e.g. using CERT or KEY or APPKEY??? records)

The properties of such an approach would be that a node receiving a BU could
do a reverse lookup of the home address, find the public key in the DNS
(and verify that the DNSsec signatures for the delegations in the ip6.arpa
tree are ok), and verify the public-key signature on the BU.

Such an approach would strictly be more secure than CAM/SUCV, because it
prevents somebody from creating bogus home addresses on the fly.
The creator of a home address must convince their DNS to install their
public key in their part of the ip6.arpa tree. (Of course, this might be 
at odds with the ability to create RFC 3041 temporary addresses...)

Given that we are *not* going to build the above,
it seems like we only have two fundamental security corner stones that we can
build on that provide per-home-address control:
 - return routability
 - the interface ID of the address being a (truncated) hash of a public key
   (as in CAM and SUCV)

Throwing a PKI on top of this adds an *orthogonal* ability to be able to
reject or accept route optimization attempts based on which CA signed the cert
and/or the certificate name, but doesn't provide the per-home-address 
verification.

Does this make sense?

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Nov 2001 13:31:46 +0200

Yes.

> ... DNSsec ...

I'm not very convinced that calling the PKI 'DNSsec' will solve
the problem. As you mention about the RFC 3041 problems
for instance, and bringing in secure dynamic DNS on top of
everything else...

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 26 Nov 2001 09:20:46 +0100 (CET)

> However, I did some back-of-the-envelope performance analysis on this some
> time last spring when I considered the options.  I don't remember the exact
> results any more, but if we asssume a reasonable delegation architecture,
> the number of DNS queries that you have to do, and more importantly, the
> number of public key signatures that you have to check are quite large,
> i.e. in the order of 5-10 signature checks.  Quite high penalty for being
> able to use route optimizations -- how many servers would be willing to
> pay that?

Agreed that this is not cheap.

> Well, I think that the HIP approach of throwing in an architecturally
> new protocol layer, with public keys acting as Host Identifiers, is
> yet another approach.  But, of course, we wouldn't have the home address
> any more (only the host ID), so perhaps that doesn't count.

I'm not up to spead on all the flavors of HIP - it might be better
to take my education off line. My question is whether HIP is really adding
any new mechanisms to authenticate the identity (it does add new flavors of
identity - public keys, host names, what else?).

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 24 Nov 2001 21:45:37 +0200

Michael Thomas wrote:

>    than a day or two maximum. 

Sure.  That's part of the idea.

>    Issuing signed certificates that

Well, the KeyNote2 and SPKI people have more or less given up
the concept of CAs.  Basically, any node can act as a CA.
In practice, you would have a few "top" nodes that would still
act as CAs and issue static long living certificates, but then
you would have something else, e.g. the local access router,
to issue the short living certificates for the actual addresses.

We also had a student looking at this problem.  Her thesis
is available at http://www.tml.hut.fi/~tpv/Zhou.pdf

The chapter worth reading is Chapter 5, starting at PDF page 68
(printed page 57).  The real beef is in Section 5.2, starting
on PDF page 73.  All the stuff is distilled into Figure 5.3
(on PDF page 78).

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 24 Nov 2001 21:36:27 +0200

> at odds with the ability to create RFC 3041 temporary addresses...)

I agree.

And then we would have the administrative problems, too....

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 26 Nov 2001 08:14:26 +0100 (CET)

> for instance, and bringing in secure dynamic DNS on top of

I don't think I claimed that.

The point was about tying the PKI to the ip6.arpa tree so that 
the delegation of IP addresses (and renumbering) is taken care of.
Thus unlike a X.509 cert which contains an IP address, storing the
public key or cert under a.b.c.d.0.1.2.3.4.5.6.7.8.9.2.3.ip6.arpa
means that when 3298/16 gets allocated to somebody else then 8.9.2.3.ip6.arpa
will be delegated to that other entity. (Note that I'm not avocating that this
is a good idea - just that it would provide some higher trust in the identity
of the sender of a BU.)

Using DNSsec as a "normal" PKI by putting keys under foo.example.com
doesn't change anything. 

    Erik