Re: I-D ACTION:draft-kamite-dnsext-tkey-secret-renewal-00.txt

[Yuji Kamite <[e-mail]>]

On Thu, 12 Jul 2001 07:38:59 -0700
Edward Lewis <[e-mail]> wrote:

> However, I think most of what is suggested in this document can be
> accomplished by adding another extended RCODE to the TKEY definision.
> "REKEY" could be a reply from a server to a client when there is an
> existing secret (temporally valid) that the server wishes to see go away.

Thanks for your comments.

I guess adding a new RCODE may be another choice.
I wonder which is better to use TSIG errors (in our drafts,
we proposed "PartialRevoke" error), or other things like RDODE.
If there are any strong good reasons for using extende RCODE,
your indication would be considered better.

I think the essential idea is that servers should return
messages with some information that secret refreshment is necessary,
thus in that sense, our draft is one way for its fulfillment
and your indication may be another. 

Anyway, I think we should make it clear the process for TSIG key
refreshment because only by TKEY RFC2930 implementors cannot
provide key renewal mechanism, and we need to prepare some new
definitions such as new RCODE, Error Code etc. and rollover processes. 

> 
> E.g.  At 11pm, client and server agree on a secret to last from 11pm to 3am.
> 
> At 12am (midnight), client queries with secret, server replies with secret.
> 
> At 1 am, the server decides the secret is unacceptable (and the client
> doesn't know this).
> 
> At 2am, client queries with secret, server replies with "REKEY"
> 

I guess this is a good example.

At 2am, client gets "REKEY".
At 2:01am, client sends TKEY to make new secret.
At 2:02am, client sends queries with new secret.

This is an ideal case.
On the other hand, 

At 2am, client gets "REKEY".
At 2:01am, client needs to suspend for some reasons or emergency 
At 3:00am, the key went away from the server
At 3:05am, client recovered, and sends TKEY to make new secret.
           but gets "BADKEY" because client has used
           removed key.

In this case, clients need another authenticaion for TKEY,
maybe SIG(0) or another shared secret not expired.
This is a littel complicated case because it depends wholely
on client when it sends a TKEY request message.
We've tried to describe it in our draft.


This makes servers be deleberate about the timing of real expiration,
i.e. 11am(inception)--2am(demand renewal)---3am(real expiration).

Our proposal's "PartialRevoke" seems to have
almost the same meaning as demanding renewal by "REKEY".
Real expiration above is defined "compulsory revocation" in our drats.

On the other hand, your indication and our drafts have
some differences about how to deal with expiration time
agreed between server and client (by TKEY).



> ...Without this new rcode, the choices the server has are "BADKEY" and a
> few others.  "BADKEY" might be confusing to the client as this indicates a
> secret that is unknown/invalid to the server.  As far as the client knows,
> the secret is agreed upon, perhaps the server is just suffering from
> amnesia.  I think REKEY would help clarify this.
> 
> Of course, the probably action by the client would be to start a rekeying
> as a reaction to BADKEY, so the clarification isn't for the software, but
> for the implementors.

I agree it is not enough to use "BADKEY" error for managing
secret keys for TSIG. 

Today, clients will get "BADKEY" both when they have signed with keys
which are not agreed by servers and when the keys are removed
from the servers.
Current implementation (BIND9) seems to delete keys in memory
whose secret expiry time agreed by TKEY Diffe-Hellman exchage
is past the current time, thus clients must be very careful about
the expiry times because only by the error code "BADKEY",
they cannot distinguish their secret expiration,
simple misconfiguration by the client key, and somebody's spoofing.


--
Yuji Kamite
Information Technology Center, Univ. of Tokyo
E-Mail: [e-mail]



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.