Subject: Re: Proposal for TSIG update

From: Paul Vixie <[email-masked]>
Date: Tue, 19 Nov 2002 23:51:00 +0000

> I propose that TSIG-bis allows TKEY to sign the last response as soon as
> shared secret key is established (even if the query was not signed).
> 
> Comments?

sounds right to me.

--
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: Brian Wellington <[email-masked]>
Date: Tue, 19 Nov 2002 17:41:06 -0800 (PST)

On Mon, 18 Nov 2002, Levon Esibov wrote:

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  so fix subscription addresses! ]
> 
> I'd like to ask namedroppers to support a proposal to update TSIG (RFC
> 2845) as described below:
> 
> Currently section 4.2 reads: "The server MUST not generate a signed
> response to an unsigned request.". In my opinion this restriction
> unnecessarily prevents TKEY mechanism from signing the last response
> (i.e. as soon as shared secret key becomes available) in the exchange of
> queries/responses that establish shared security key, which would be the
> right thing to do for the TKEY protocol.
> 

As I said last time this came up, I think this unnecessarily complicates 
the protocol, and the only reason to do this would be so that the GSS-TSIG 
draft becomes standards compliant.  I believe GSS-TSIG should be fixed, as 
this has no benefit for other TKEY methods.

Are there any other reasons for a TSIG-bis?  I haven't seen any.

Brian

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 20 Nov 2002 09:37:04 -0500

> > shared secret key is established (even if the query was not signed).

In the DNSEXT meeting yesterday, I asked for the "sense of the room"
on this issue.

After explaining the issue as a general conflict between two RFC's[1] both
trying to do the right thing but for different reasons:
TSIG RFC (I'm one of the authors) was trying to make sure that the parties
in the exchange would never be surprised by a spontaneous TSIG in the
middle.
GSSAPI TSIG document is trying to do the right thing from security point
of view by protecting the last message of a key exchange and allows
client to determine that it and the server have agreed to the same secret.

The change that has been proposed supports both TSIG intent (no surprises)
and the security desire of GSSAPI.
This change is only seen by a TSIG enabled entity that engages in a
GSSAPI TKEY exchange. Thus it is harmless to the installed base.
Any further additions of TSIG messages in a middle of a exchange will
be limited to new uses of TSIG and thus are harmless to installed base.

The only drawback to this change is that some implantations make design
choices that prevent/make hard to add support for GSSAPI TKEY exchange.

         Olafur
[1] TSIG is an Proposed Standard RFC, GSSAPI TSIG is in RFC editors queue
after passing working group and IETF review.