El 19/09/2006, a las 11:39, Christian Vogt escribió:
Hi Marcelo,
thanks for the feedback! Responses in-line.
(1) Since there are only 8 possible Sec values, wouldn't it make
sense to recycle the semantics of these values over time?
yes, but my concern is about how much time do we need to start re
using an previously assigned value safely
Keep a registry entry considered insecure deprecated as long as
possible. Re-use it only when a new registry entry is needed, but all
8
available Sec values are occupied. In that event, re-use the oldest
deprecated registry entry.
or the less used entry i.e. suppose that one assignment was made that
was not successfull at all for any reasons (like IPv5 for instance)
Specifically, if an old CGA SEC registry entry is found to be
insecure, it could be deprecated for a certain (minimum) time, so
that CGA implementations have time to migrate to a more secure
combination of hash function and number of leading zero bits in
Hash2. When there is need for a new combination, the oldest
deprecated registry entry would eventually get replaced.
agree but i would like to hear some comments about how long does this
process take. I mean, i guess that there are quite a few old
implementations that do not get upgraded and we would need to support
these.
See above. We only re-use registry entries as a last resort.
agree
Note that a CGA implementation that is hard-coded for a stale registry
entry uses insecure/broken cryptographic functions anyway. This means
that it does not matter that much if such an implementation falls back
to standard IPv6 if it turns out that it is incompatible with a more
up-to-date implementation at a peer.
Along this line, we could deprecate registry entry 0 (SHA-1 + 0
leading zero bits in Hash2) today.
Are you proposing to do this now? I am not sure that at this point
the sec = 0 is unsafe... Do you have some information about specific
threats with this Sec= 0?
I'm not saying there are existing threats for Sec=0.
but then there is no point in deprecating it imho
I mean, as i see it, we need to deprecate an entry because it is no
longer safe to be used, not because there are stronger options...
agree?
Deprecating the
value now would simply ensure that new CGA implementation default to a
more secure hash function.
Optimally, new CGA implementations should include an interface via
which they could be updated to registry changes. But since such
changes are expected to occur only at a very low frequency, it may
just be sufficient to pre-configure CGA implementations.
Erroneous use of an obsolete CGA SEC combination would not be
dramatic: CGA verification would fail in the worst case and nodes
would have to revert to unprotected IPv6 addresses. But note this
would happen only if the obsolete CGA SEC combination was
considered insecure anyway.
I am not sure about this....
wouldn't this open the doors to downgrading attacks?
I don't think so. See below.
I mean, suppose that an attacker wants to hijack a CGA e.g. in SeND.
suppose that the CGA being used contains a Sec parameter that has
been reasigned. We have the old parameters associated with the Sec
value and the new paramters suppose that the attacker can crack the
old paramters but not the new ones so, the attacker will send SeND
validation information using the old paramters and the receiver will
beleive that this is just an old implementation that has not been
upgraded, so the attack can succeed...
We have to ensure that a CGA implementation does never accept two
different parameter sets for the same Sec value. Only this would allow
for downgrading attacks.
Now, the alternative would be to simply not accept the old paramter
information as valid, but this would break interoperation, hence we
need very long periods of time for changing reasigning a sec value.
Right, the timeout periods have to be very long. But if we do not
allow
for re-use after such a long period, then we would eventually run out
of
registry entries. There are only 8 available.
And note we must use the 8 Sec values to encode BOTH, a hash function
and a number of leading zeros for Hash2. While the hash function may
have to be replaced only very rarely, we may have to increase the
number
of leading zeros for Hash2 more frequently, requiring a new Sec value
each time...
So, i would preffer delaying the reassignemet of sec values as much
as possible, in particular, till we run out of sec values. Then we
could start reassigning the initiallly assigned values (or other
values that had prooved not to be widely implemented)
This is what I was proposing in my email.
OTOH, i am not we need to do anything in the draft in order to
support this... I mean AFAICT is a matter of the registry
administration and we will need to deal with this when we run out of
Sec values, i guess...
It would be good to specify the intent for re-use in the draft so that
sophisticated CGA implementations could provide an interface via which
they can be updated to registry updates.
i don't have a problem with including a section with this.
does anyone else has an opinion on this? Jari?
basically the additional text would to state that:
- since there are few sec values, it may be needed to reuse sec values
- this is a last resource option, since it may affect interoperation
- a long time is required between the deprecation of the old value and
the reassignment in order to prevent misinterpretation of the value by
old implementations
- this may affect interoperation (if an old implementation receives a
CGA generated with the new meaning of the sec value, it will fail)
- by no means an implementation should support both meaning of the Sec
value, since it may lead to downgrading attacks,
anything else needed in this section?
The current CGA standard also includes the option of falling back to
standard IPv6 in case the correspondent node does not support (or
claims
not to support) CGAs.
(2) Wouldn't the length of the modifier have to be defined as part
of the CGA SEC registry, too?
If we define the number of leading zero bits for Hash2, say N, as
part of the registry, we are no longer bound to the limit of 16 *
(23 - 1) = 112 bits which the 3-bit Sec parameter provides.
However, the length of the modifier should be at least as long as N
plus a certain number of bits for location privacy. Since this
may, at some future time, exceed the limit of 112 bits, it may be
good to define the modifier length as part of the IANA registry,
too.
I think this is a good point, indeed
However, I am not sure this needs to be encoded in the address itself
i.e. in the sec value itself. I mean the only reason to encode
information in the address itself AFAICS is to prevent downgrading
atttacks, agree?
I wasn't saying that the length of the modifier needs to be encoded
into
the CGA, but it should rather be defined as part of the registry entry.
You mean like additional information...
I don't know...
i guess that if a new sec value is assigned, the details will need to
be defined in a RFC so i would say that the RFC would be right place to
describe all the related information, including the modifier length for
this particular sec value... i mean, as you mention, current 128 bit
modifier seems to be good enough for our needs now...
Summarizing, i don't have a strong opinion on this neither, but i think
it would be easier/simpler to store this information in the associated
spec and reduce to the minimum the information contained in the
registry itself.
does anyone else has an opinion?
thanks again for your comments, marcelo
If we define the modifier length in the registry entry, then CGA
verifiers can see how long the modifier field is when they
recompute/verify a given CGA.
I do agree that there is no possibility for downgrading in this case.
that is why we need to encode the hash function there.
Yes.
<snip>
Alright, best regards,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
