Subject: Re: TKEY updates, time fields

From: Robert Elz <[email-masked]>
Date: Sun, 20 Sep 1998 08:39:24 +1000

Date:        Sat, 19 Sep 1998 16:50:19 -0400
    From:        Donald Eastlake <[email-masked]>
    Message-ID:  <5010400027048054000002L042*@MHS>

    I just don't
    think a ceiling of 18 hours on the life of a symetric key is reasonable.

I would certainly agree with that, but I am confused, I think.  Where is
that 18 hour lifetime limit supposed to come from?

(Yes, I know that 18 hours is (close enough to) 2^16 seconds).

As I read things, the 16 bit time field in tsig isn't in any sense a key
lifetime, its a clock fudge factor (also to allow for network transmission
delays I guess).   That is, the time indicates "now", and is supposed to be
equal on the client and server, within the fudge factor.  For that, an 18 hour
fudge limit (actually, 9 hours before or after) is just fine.

As I read tkey, there's a pair of times, which bound the key validity,
one of which is probably in the past, and the other which will be at some
random time in the future.  These may or not need a settable clock fudge
factor to allow for keys which have only just become valid (and remote clock
is slower than ours) or for very short expiration times and non-synchronised
clocks.

What I don't see is how using a 48 bit absolute timer (which consequently
will fall flat on its face somewhere about the year 9000000 AD) in any way
would be imposing an 18 hour lifetime limit on the key - if anything, it seems
it would instead be allowing absurdly long lifetimes.   That is, unless you
were planning to replace the two current 32 bit timers (Inception and
Expiration) with a 48 bit value, and a 16 bit offset, and that I agree would
certainly not be a good idea - but replacing both with 48 bit absolute
timers should work just fine, or replacing one with a 48 bit absolute timer
and the other with a shorter offset field, and allow the other to be
calculated - a 32 bit field would certainly be good enough, a 24 bit field
(just over 6 months) probably would be a little short.  Perhaps a 32 bit
field specifying tenths of seconds (13 year range)?

    I plan to leave them 32 bit fields but make them modulo 2**32.

Could you describe again how that is supposed to work?   It would certainly
eliminate the year 9000000 sunset clause on the standard, but it seems to be
that timers which aren't absolute cannot protect against replay attacks, all
they can do is make the attacker wait a long time before a replay with a
saved old packet will work.   If this is so, for the cost of 16 bits, would
it not be better to simply use 48 bit absolute values (none of us will care
when someone has to spend mega-trillions of tollars to fix all the year 9000000
design limitations...)

kre

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 19 Sep 1998 16:50:19 -0400

Hi,

I'm updating draft-ietf-dnssec-tkey-*.txt, because it is about to expire.  It
has inception and expiration fields that need to be either (1) updated to be
modulo 2**32 like draft-ietf-dnssec-secext2-*.txt or (2) modified to 48 bit
inception and 16 bit life time fields as in the latest
draft-ietf-dnsinc-tsig-*.txt.  While TKEY is very closely associated with TSIG
and my initial inclination would be to go with the TSIG fields, I just don't
think a ceiling of 18 hours on the life of a symetric key is reasonable.
Although many will have a shorter life, I think there will be people who will
want symetric keys that are good for days if not weeks.  So, unless there is a
consensus otherwise, I plan to leave them 32 bit fields but make them modulo
2**32.

Thanks,
Donald

Donald E. Eastlake, 3rd
318 Acton Street, Carlisle, MA 01741 USA
1-978-287-4877, fax 1-978-371-7148

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 20 Sep 1998 15:56:03 -0400

Hi Robert,

From:  Robert Elz <[email-masked]>
To:  Donald Eastlake <[email-masked]>
Cc:  [email-masked], [email-masked]
In-Reply-To:  Your message of "Sat, 19 Sep 1998 16:50:19 -0400."
	                  <5010400027048054000002L042*@MHS> 
Date:  Sun, 20 Sep 1998 08:39:24 +1000
Message-Id:  <[email-masked]>
Sender:  [email-masked]

>    I just don't think a ceiling of 18 hours on the life of a symetric key
>    is reasonable.
>

I don't see much logical difference between a start time and a stop
time, a start time and a forward delta, an end time and backward
delta, or a middle time and forward/backward fudge.  In the first case
you have two absolute times that might "overflow" while the rest have
only one absolute time that could increase without bounds plus a time
delta of some form which could reasonable be limited in the protocol
specification.

>field specifying tenths of seconds (13 year range)?

TKEY RRs provide keying material for use in TSIG RRs sort of like KEY
RRs provide keying material for use in connection with SIG RRs.
Therefore it seems, at first glance, reasonable to use the "same"
variety of validity interval time fields in TKEY as in TSIG, which
could a 48 bit start and a 16 bit forward delta (or, to be strictly
the same, a 32 bit center of life time and a 16 bit fudge).  However,
that has the problem I specified of an 18 hours maximum keying data
lifetime (or maybe 36 hours if the fudge goes both ways).  While that
is a reasonable, if not generous, maximum life time for a TSIG, it
seems to me too short for a keying material maximum life.

It seems to be better, if one can, to use an existing time format,
such as the one in TSIG or the one in SIG, rather than inventing a new
one as you suggest.  Furthermore, it is my understanding that at least
one mode of TKEY is implemented in Windows NT Beta, so there is some
reason not to change the field lengths, etc., in the current
definition of TKEY.

>when someone has to spend mega-trillions of tollars to fix all the year 9000000

While the timers do not protect against replay attacks, the
authentication on the message with the TKEY in it and the
authentication of the SIG that signs a KEY do.  In particular, the
protocol specifications must require that keys be rolled over to new
random keys no less often than every 2**31 seconds.  (And the secops
draft recommends that no key ever be used for more than 5 years, which
is about 1.175 * 2**27 seconds.)  The probability that you can
successfully replay a TKEY (or SIG) N * 2**32 seconds later for some
whole integer N>0 is the probability that you have randomly selected
exactly the same key for that rollover epoch which should be the same
as someone being able to randomly guess the key.  Therefore this does
not represent an increased threat.

>kre

I'm going to go ahead and submit the revised draft it with 32 bit
modulo timers.  If a consensus develops to do it differently, the
draft can always be changed.

Thanks,
Doanld