Subject: Crypto-based host identifiers

From: <[email-masked]>
Date: Wed, 29 Oct 2003 20:42:52 +0100 (CET)

I have some questions about this psposal:

Why do you set the group bit to "group"? i mean, it is not a multi-cast 
address, right?

I still don't understand the need for a new public registry.
You also mention the need to use the DNS, wouldn't be enough to use 
only the DNS?
If i understnd correctly, you need the new registry, because in order 
to avoid collisions, right?
But a collision means that someone else has the private key that 
matches the hash of 
someone else's public key. This situation by itself it is a 
vulnerability 
to the solution isn't it?, since if it has such a private key it can 
impersonate 
the original holder, right?
So, in order to overcome this, you propose the usage of the DNS, is 
this correct?
My question is then, why don't you use only the DNS and avoid the new 
registry?
The new public registry may not be so simple than just a list of 
allocted site prefixes, 
i mean, you have to protect from several type of attacks, for instance 
depletion attacks, 
where a malicious part starts registering site prefixes in a bulk 
fashion.
You can address this charging a fee, but as you see things get more 
complicated.

Another question, how do you generate the host part of the CBHI? i 
can't find it in 
the document. I guess it would be a hash of its own public key.

My question then is why do you want a site key and a host key? i don't 
see any benefit of 
its usage in the current document. Why don't you just use a host key, 
just a regular CGA?
Another issue related to this, what is the benefit of using 64 bits 
long identifiers. I mean,
TCP and other ULP use 128 bit long identifiers so you will have to 
complete the 128 bits or 
modify the ULP. I guess that you will complete the 128 bits, so why 
don't you just use them all
to contain a key. I guess that the benefit would be that you can carry 
both the locator and 
the identifier in the address field of the IPv6 packet and that you can 
obtain them in a regular
DNS AAAA query, but i don't know how important is this. First you don't 
really need to carry
the identifier in all packets, once that the context is set up, you 
just carry the locators 
and things should work, i guess. Second, storing the 128 bit long in 
the DNS as a new RR 
wouldn't be complex, and it could be used to distinguish host that 
support the new mechanism 
form those who don't. 
Besides, using 64 bit only for the id really introduces some 
limitations as the ones mentioned 
above, so i still don't see clearly why this is a good option.

Another issue is related to section 6 turning site id into prefixes.
Why don't you use a Hinden Haberman local scope address prefix insted 
of asking for 
a new address range for this usage?

About the addres authentication section.
I don't understand some parts of the procedure, for instance in step 7 
(the 7th -) you say that
B also looks up B's site identifier in the DNS, shouldn' B already know 
its own site id?
or is that B looks A's site identifier in the DNS? the same question 
about the next sub-step (*)
about B checking B's public keys.

As a final observation, this proposal uses public key crypto and DNS 
querys to provide security, 
(and if i understand correctly, it imposes a DNS query to the target 
node (B) which is not 
currently needed in a communication i.e. it is like imposing that A 
performs a DNS query, 
which would mean that when A performs the regular AAAA query it would 
also obtain additioanl info, 
such as a new RR), besides it also requires a new public registry.
So in brief this seems lika a pretty expensive mechanism to me, 
couldn't you provide some similar 
level of security using just one of them, for instance just public key 
crypto like HIP? 
In other words, what are the benefits obtaine after incurring in all 
these additional costs? 

Thanks, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Oct 2003 22:56:44 +0100

> Why do you set the group bit to "group"? i mean, it is not a multi-cast

Nope. It's just that this gives us the largest block of unused EUI-64 
space. All potential values with the u/l bit set to "local" may be used 
by RFC 3041, while all values with the u/l bit set to "universal" and 
the group bit unset are governed by the IEEE and a good number of these 
values are in use. In theory this also goes for the  universal + 
group=yes values (see Radia Perlman's discussion of MAC addresses in 
"routers and switches" (first edition, not sure if it's in the second 
one)) but in practice I don't see how this could be an issue.

> I still don't understand the need for a new public registry.

To quickly discover colliding hashes.

> You also mention the need to use the DNS, wouldn't be enough to use

The problem with the DNS is that there are some organizations that seem 
to think they have authority over what's in it. That's not what we want 
for this. So sure, put a copy of the data in the DNS, but don't make 
the DNS the authorative source of this information.

> to avoid collisions, right? But a collision means that someone else 
> has the private key that matches the hash of someone else's public 
> key. This situation by itself it is a vulnerability to the solution 
> isn't it?, since if it has such a private key it can impersonate the 
> original holder, right?

Yes. Fortunately it isn't as bad as it sounds. Suppose you're making a 
44 bit has and there are already 2^24 hashes in use. You then have a 1 
in 2^20 chance of colliding with an existing hash. However, the chance 
that you're going to collide with Google, Microsoft or the White House 
is significantly smaller than the chance you're going to collide with a 
grocery store in Milan, a home office in New Jersy or a cell phone in 
Osaka, which aren't nearly as much fun to impersonate. Also, as soon as 
you use your fake hash and someone detects it, you're found out and the 
holder of the original hash is going to abandon it. So you have to make 
the first time that you're going to abuse the colliding hash count real 
good because it's likely it's your only chance.

> So, in order to overcome this, you propose the usage of the DNS, is

Yes, DNS or some other way of distributing the full public keys can be 
used to add extra security.

> My question is then, why don't you use only the DNS and avoid the new

I don't see the new registry as a huge problem. Could be as simple as a 
bunch of PGP key servers.

> The new public registry may not be so simple than just a list of

Why not?

> depletion attacks, where a malicious part starts registering site 
> prefixes in a bulk fashion.

If people generate these keys I would rather have them registered than 
kept secret... Not much we can do if people are inclined to do this.

> can't find it in the document. I guess it would be a hash of its own 
> public key.

It isn't generated, just a simple number, start at 0, increase for each 
new host...

> see any benefit of its usage in the current document. Why don't you 
> just use a host key, just a regular CGA?

Host keys don't have internal structure so they can't be put in the DNS 
in large enough numbers. With the site as an intermediate step there 
should be enough hierarchical structure to be able to put them in the 
DNS.

> long identifiers. I mean, TCP and other ULP use 128 bit long 
> identifiers so you will have to  complete the 128 bits or modify the 
> ULP. I guess that you will complete the 128 bits, so why don't you 
> just use them all to contain a key. I guess that the benefit would be 
> that you can carry
> both the locator and the identifier in the address field of the IPv6 
> packet and that you can obtain them in a regular DNS AAAA query, but i 
> don't know how important is this.

I'm not too interested in the AAAA query. What I want to accomplish is 
that the identifier remains the same and visible in each packet even 
though the locator prefix changes.

> of asking for a new address range for this usage?

Basically what I'm doing is taking GSE/8+8 and modifying it a bit to 
make it compatible with current IPv6 implementations. On the wire, the 
top 64 bits (the locator part) can change while only the lower 64 bits 
(the identifier) remains the same end-to-end. However, current 
protocols don't understand this. Rather than change routers to route 
based on the low 64 bits, change TCP and UDP checksums and so on, we do 
some magic and suddenly we have something that looks enough like a 
regular prefix to be used by existing hosts and routers. The 
multihoming can then be done by a proxy multihoming box.

> (the 7th -) you say that B also looks up B's site identifier in the 
> DNS, shouldn' B already know its own site id? or is that B looks A's 
> site identifier in the DNS? the same question about the next sub-step 
> (*) about B checking B's public keys.

Correct, it should be A. Sorry...

> querys to provide security,  (and if i understand correctly, it 
> imposes a DNS query to the target node (B) which is not currently 
> needed in a communication

Use of the DNS isn't required for regular operation, only when 
additional security is desired. However, the same results can be 
achieved without using the DNS. For instance, a site could periodically 
download all known public keys and store them locally.

Iljitsch

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 31 Oct 2003 13:49:53 +0100 (CET)

> good because it's likely it's your only chance.

Another mechanism to limit the exposure by short hashes is
that the first time a host performs the PK challenge with the peer
it records the actual public key.
Later if somebody tries to redirect the traffic it can verify not
only that the ID=hash matches, but also that it is the identical
public key.

This doesn't provide for strong "ownership" of the actual ID, but it
does prevent redirection attacks.

  Erik