Subject: RE: Allocating a bit in the RFC2437 Interface Identifier

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 20 Mar 2002 23:16:14 -0600

> In which case, I violently agree with Keith. We've already
> overloaded IP addresses with two functions - locator and
> identifier. 

I would rather see the WG focus on the value of using a bit to specify
whether the address is intended to be both a locator and identifier or just
a locator. I personally believe this would be a far better use of real
estate than the other proposal. I certainly wouldn't expect any dicision
soon on either proposed use, though.

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 21 Mar 2002 08:05:37 -0600

Glenn Morrow wrote:
> whether the address is intended to be both a locator and identifier or 
> just a locator. I personally believe this would be a far better use of 
> real estate than the other proposal. I certainly wouldn't expect any 
> dicision soon on either proposed use, though.

Well, the original idea was to reserve a bit to indicate that the
address is Cryptographically Generaged Address (CGA), basically
meaning that

    if the bit is set, then
       interface id = low64(hash(PK, stuff)) & mask

    where
       PK      is a public key to be used as an identifier for the host
       stuff   is contains other parameters (see the earlier messages)
       hash    is a cryptographic hash function, e.g. SHA1
       low64   is a function that takes lowest 64 bits
       mask    indicates that we have to clear/set some bits of the iid

In essense, that would allow anyone to determine if a given public
key belongs to a host, just inspecting the public key, the address,
and the "stuff" above.  See e.g.

   Michale Roe and Greg O'Shea, "Childproof authentication for MIPv6",
   Computer Communications Review, April 2001,
   http://www.research.microsoft.com/users/gregos/CAM-v9.pdf

or

   Pekka Nikander, "Denial-of-Service, Address Ownership, and Early
   Authentication in  the IPv6 World", Cambridge Protocols Workshop,
   April 2001, http://www.tml.hut.fi/~pnr/publications/cam2001.pdf

for research papers touching the idea.  There is also a number of
internet drafts that describe in more detail how CGA could be
used for a number of purposes, including but not limited to Mobile
IPv6.

Unfortunately, this method is encumbered by IPR claims from Microsoft
and Ericsson, and therefore it received violent opposition at the
mobile-ip working group.  As a result, the MIPv6 Design Team resolved
to the more modest proposal of just allocating the bits, in the
hope that the IPR issues could be dealed in a way or another.

--Pekka Nikander

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Mar 2002 16:15:41 +0200 (EET)

> hope that the IPR issues could be dealed in a way or another.

"We (MIPv6) can't use it due to IPR, so we'll just move the problem to
ipng and have them reserve bits in the address instead"...?

Doesn't sound discouraging enough to me.

We MUST NOT reserve bits in the address to support IPR'd mechanisms.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 21 Mar 2002 08:37:26 -0600

> We MUST NOT reserve bits in the address to support IPR'd mechanisms.

Actually, the intention is just the reverse.  The intention is to
reserve a bit (or bit pattern) so that the IPR'd mechanims NEED NOT
to be used for future better security protocols.  CGA can be used
independent on whether there are any bits reserved or not.

The bit method would leave the door open to any future security mechanisms,
including those based on AAA and CGA.

But I think Erik is better in expressing the issue, he first
proposed the bit method anyway.

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Mar 2002 16:41:36 +0200 (EET)

> including those based on AAA and CGA.

Our assumptions are different: you assume CGA is used (except when
signalled not to), I assume CGA will not be used (unless signalled to do
so).

In the latter case, I'm not sure if bits are necessary.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 16:57:21 +0200

> We MUST NOT reserve bits in the address to support IPR'd mechanisms.

That wasn't the case. The proposal is:

1) Allocate the bit
2) Use the bit value 0 to signify "default parameters" for ANY use (not just MIP)
3) Reserve the bit value 1 for future purposes

There's two important things here. One, point 2 is not just for MIP.
Second, we *reserve* the possibility to do something else than the default
use in point 3. We don't know what that something could be. It could be
something else than what Pekka mentioned about the IPRd mip mechanisms.
Just that it would be prudunt to not paint ourselves in the corner that
we can never have anything else than the default behaviour.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Mar 2002 16:06:16 +0100 (CET)

> In the latter case, I'm not sure if bits are necessary.

The bidding down issue has been discussed on the mobile IP mailing list
and so far nobody has proposed an infrastructure-less way to
avoid this attack short of the bit-methods. Doesn't mean that one
doesn't exist - but I think it means that there aren't obvious
easy alternatives.

Awaiting your proposal (but not on this mailing list - MIP is a better
mailing list for this part I think).

  Erik

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Mar 2002 12:29:40 -0500

> and the "stuff" above.  See e.g.

given that you need all of that "stuff" in order to verify the key
anyway, why not make the CGA bit part of that "stuff" also? 

Keith

---

From: "John F. Leser" <[email-masked]>
Date: Thu, 21 Mar 2002 16:27:05 -0500 (EST)

Just an idea:

If there is an entire class of problems that can only be solved by a flag
in the address itself, why not reserve the top 16 bits of the Interface
Identifier?  To put it another way, if having semantically significant
bits in the address is the best solution for a problem or two now, we
might well want more bits in the future.  Also, if we are not going to
support a full 64-bit identifier, 48-bits is the next logical break.

-John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2002 23:42:44 +0100

Kind of tricky for FireWire

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Mar 2002 23:49:50 +0100

In your previous mail you wrote:

=> Brian, do you suggest that FireWire (aka I-Link aka IEEE 1394) uses
64 bit addresses?

Regards

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Mar 2002 03:42:08 +0100

> => Brian, do you suggest that FireWire (aka I-Link aka IEEE 1394) uses

Now that would be a silly suggestion wouldn't it? I think I mistyped...
it's late in the week.

   Brian

---

From: "Rami Lehtonen" <[email-masked]>
Date: Fri, 22 Mar 2002 08:46:44 +0200

>Pekka Nikander wrote:

Does this prove that the public key belongs to the host? What if the
attacker just uses different network prefix and the same interface id than
the original host?

Am I missing something?

-Rami Lehtonen

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 22 Mar 2002 07:28:26 -0600

> attacker just uses different network prefix and the same interface id than

Well, I guess my language was just too loose.

CGA, as such, only says that "there has been, at some point of
time, some party A, who created this interface id IID, using the
parameters (PK, stuff)".  This comes from the cryptographic properties
of the hash function; that is, we assume that it is sufficiently hard
to invert the hash function so that the only plausible way for creating
(IID, PK, stuff) triples is first to first generate PK and stuff, and
only then to calculate IID.  Taking a given IID and generating PK or
stuff from that is assumed to be hard.  (There are details but I don't
want to go the them here.  Read draft-roe-mobileip-updateauth-02.txt.)

To extend from this, we make the agreement that "since A has created
this IID using PK, that indicates that A wants to be identified
with PK".  That creates a binding IID -> PK.  Now, if you want to
check that the host using IID is really A, you need to create also
the reverse binding, PK -> IID.  To do that, you ask A to sign
a random number (a nonce) using the private key corresponding to PK.

Thus, if an attacker takes the (IID, PK, stuff) triple and goes to
another network, it can still use the same IID, but it can't sign
anything since it doesn't have the private key corresponding to PK.

Or am I missing something?

--Pekka Nikander