[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crypto-based host identifiers
On 29 okt 2003, at 20:42, <mbagnulo@ing.uc3m.es> wrote:
Why do you set the group bit to "group"? i mean, it is not a multi-cast
address, right?
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
only the DNS?
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.
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?
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
this correct?
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
registry?
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
allocted site prefixes,
Why not?
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.
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.
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.
It isn't generated, just a simple number, start at 0, increase for each
new host...
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?
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.
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.
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.
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?
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.
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.
Correct, it should be A. Sorry...
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
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