Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 12:59:25 -0700

> -----Original Message-----
> From: Brian Wellington [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 12:17 PM
> To: Levon Esibov
> Cc: Rob Austein; [email-masked]
> Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
> 

> >
> > [Levon Esibov]
> > Brian,
> > I don't think this is the right approach. If modifying RFC 2845
(TSIG)
> > is the "optimal" for customers and development community then we
should
> > do it. If namedroppers believe that modifying GSS-TSIG draft is more
> > optimal - then I don't object it. But simply closing the door saying
> > that "it's not TSIG issue" because it works and because it's a
proposed
> > standard is probably not the right approach, especially since
suggested
> > modification does NOT affect working implementations.
> 
> I've stated my opinion, but we'll see what other people have to say...
> 
> Brian
[Levon Esibov]
I absolutely agree, and encourage other members of the namedroppers to
express their opinion.

Below I summarize opinions/suggestions expressed so far to eliminate
conflict between RFC 2845's (TSIG) requirement to not sign responses to
unsigned queries and GSS-TSIG draft requiring servers to sign the
responses to the TKEY queries as soon as the secret key is established.

Here are the proposed solutions.
1. Modify RFC 2845 (TSIG) as follows:
Replace:
"The server MUST not generate a signed response to an unsigned request."

With:
"The server MUST not generate a signed response to an unsigned request,
except in case of response to client's unsigned TKEY query if secret key
is established on server side after server processed client's query.
Signing responses to unsigned TKEY queries MUST be explicitly specified
in the description of an individual secret key establishment algorithm."

2. Update the GSS-TSIG draft to not require that Server signs with TSIG
its last response to the client.

2a. In addition to 2 (above) mention in the updated GSS-TSIG draft that
previous implementations of GSS-TSIG clients require TSIG to be present
in the last server response and mention that implementers of the update
GSS-TSIG protocol may consider including TSIG record on the server side
to interop with old clients. Client may ignore TSIG record in response
from old servers. (version of the draft reflecting these updates is
attached)

2b. In addition to 2 (above) change the algorithm name in the GSS-TSIG
protocol to allow new implementations to distinguish old implementations
(using old algorithm name) from the new implementations.

2c. Do just what 2 above says. Do not even mention any previous
implementations and let new implementations to not interop with widely
deployed old implementations.

Please let us know which solution you prefer.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Jul 2002 14:23:11 -0700

> in the description of an individual secret key establishment algorithm."

right now the base tsig document is independent of tkey.  this was originally
due to the order of their creation, but it's still a good property to have.
so if approach #1 is taken, i recommend broader wording:

	The server MUST NOT generate a signed response to an unsigned
	request, unless the signature algorythm's specification allows
	this (for example, see GSS-TSIG).

(though i would have preferred to see GSS-TSIG always sign its requests, and
to see TKEY specified in a way that made this possible.)

> deployed old implementations.

none of these are practical due to the installed base.

> Please let us know which solution you prefer.

those were my two cents.

--
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: Yuji KAMITE <[email-masked]>
Date: Thu, 25 Jul 2002 12:42:42 +0900

> in the description of an individual secret key establishment algorithm."

If you take this alternative, the meaning which MAC in the response
implies comes to differ according to protcol (GSS-TSIG or the others).
I think it might be better to add some kinds of description
for notice. For example: 
In GSS-TSIG, the MAC in a response (to an unsigned request) means
confirmation and notification telling that secret is successfully established
via GSSAPI; meanwhile, in the original TSIG, MAC in a response (to a signed 
request) means that the response validly corresponds to the 
received request itself (i.e. secures the transaction), 
as well as authenticates the host's identity. 
client-recipient must be aware of this difference by checking
which algorithm is now being used.

---
Yuji Kamite   (mailto: [email-masked])
NTT Communications
Tel:+81-3-6800-3261, Fax:+81-3-5365-2990