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

From: [email-masked]
Date: Tue, 10 Jul 2001 14:10:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: TKEY Secret Key Renewal Mode
	Author(s)	: Y. Kamite, M. Nakayama
	Filename	: draft-kamite-dnsext-tkey-secret-renewal-00.txt
	Pages		: 12
	Date		: 09-Jul-01
	
TKEY [RFC2930] provides methods of setting up shared secret keys for
TSIG [RFC2845] other than manual exchange. But TKEY itself cannot
control timing of key renewal very well though it can add or delete
shared keys.  Since continuing to sign messages with old keys
permanently is not safe, hosts which make use of TSIG should pay
attention to the time limit of secret usage.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kamite-dnsext-tkey-secret-renewal-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kamite-dnsext-tkey-secret-renewal-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-kamite-dnsext-tkey-secret-renewal-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 12 Jul 2001 07:38:59 -0700

First, I'm really happy that someone is working on TKEY usage - it is one
of the open areas for improvement in DNS Security.

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.

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"

...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.

>	Filename	: draft-kamite-dnsext-tkey-secret-renewal-00.txt

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

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

---

From: Yuji Kamite <[email-masked]>
Date: Fri, 13 Jul 2001 06:45:54 -0700

On Thu, 12 Jul 2001 07:38:59 -0700

> 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. 

> 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).

> as a reaction to BADKEY, so the clarification isn't for the software, but

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: [email-masked]