Subject: Discuss: TKEY renewal

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 18 Jun 2002 12:10:04 -0400

This is a major update to the old version and I encourage people to
read this document and comment on the direction this document should
take, options
	Limit to DH exchange
	Expand to include other keyexchanges GSSAPI, Server assigned ...
	Not standardize.

This version reflects all input that authors have got from members of
the working group.
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-01.txt

	Olafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 20 Jun 2002 08:36:31 -0400

Limiting this to just DH is a bit worrisome to me.  TKEY operations are not
so limited (in the spec), but I know most implementations would do DH only
anyway.  If multiple key exchange algorithms are to be supported, DH should
be considered for MANDATORY status.  Some way of indicating which algorithm
is used would also be assigned. (KEY or TKEY RDATA field).

I am assuming this is for supporting primary-secondary interactions,
correct?  Since only two parties can be involved.

Scott

----- Original Message -----
From: "Ólafur Guðmundsson" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 18, 2002 12:10 PM
Subject: Discuss: TKEY renewal

> This version reflects all input that authors have got from members of
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-01.t
xt

---

From: "Yuji KAMITE" <[email-masked]>
Date: Tue, 25 Jun 2002 09:48:00 +0900

>         If multiple key exchange algorithms are to be supported, DH should
>be considered for MANDATORY status.

I think so, too.

> correct?  Since only two parties can be involved.

Basically correct.
TKEY is a protocol for two entities -- server and client.
So, primary-secondary authentication ( zone transfer)  would be
a typical and major target.
However, TKEY Renewal can also be used in other areas,
such as server and client over Dynamic Update, as long as
they agree to make use of it, too.

> Expand to include other keyexchanges GSSAPI, Server assigned ...

It would be meaningful to expand to other algorithm.
Now I guess it is not so difficult to modify the current draft.

However, I still have one concern here;
 As for TKEY Renewal, how to deal with GSS-TSIG algorithm?
 (or, should we take it into consideration?)

My understanding is, "security context" established via GSS is
virtually equivalent to shared secret used in normal TSIG.
Because TKEY Renewal procedure is usually invoked by server's Partial Revoke
notification to client, probably client can make new "security context"
only if it sends a Renewal requet with indication that hopes gss-tsig
algorithm, and then starts rekeying based on GSS-TSIG method.

But, on the other hand, I have several questions.  For example, how can we
interprete security context's lifetime in GSS, and map it into TKEY Renwal
Mode's definition, and  how can we revoke unnecessary security context over
GSS-API ?, and so on.
If TKEY Renewal is expanded to include GSSAPI,  ample studies are needed,
which is due to GSS's peculiarity and abstractness compared with other
algorithms like DH.

If it is ensured that using GSSAPI does not need so much complicated surgery
to current basic Renewal Mode's framework, it will be sufficient to add some
sentences to current draft.  If not, possibly it might be good to do in the same
way as TKEY RFC and GSS-TSIG draft are proposed separatedly. (i.e,
Renewal Mode's proposal only refers to the existence of GSS-TSIG method;
meanwhile, its actual details are expected in the other document, if necessary.)...

Now, I appreciate comments and advice from GSS-API -familiar people.

-- Kamite

---
Yuji Kamite (E-mail [email-masked])
NTT Communications Corporation
         TEL: +81-3-6800-3261 FAX: +81-3-5365-2990

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Scott Rose
> Sent: Thursday, June 20, 2002 9:37 PM
> To: DNSEXT WG Mailing list
> Subject: Re: Discuss: TKEY renewal
>
>