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

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 09:40:39 -0700

> -----Original Message-----
> From: Brian Wellington [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 9:34 AM
> To: Levon Esibov
> Cc: Rob Austein; [email-masked]
> Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
> 
> On Wed, 24 Jul 2002, Levon Esibov wrote:
> 
> > Any TSIG experts care to comment whether they see any problems with
> > proposed modification?
> 
> It causes many clients to break, since a client may treat a signed
> response to an unsigned query as an error, and at least one common
> implementation does.

[Levon Esibov] 
Hi Brian,
Please note that my proposal doesn't blindly allow any server to start
signing responses to unsigned queries. My proposal reads:
"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."

Please note that statement "Signing responses to unsigned TKEY queries
MUST be explicitly specified in the description of an individual secret
key establishment algorithm." prevents breaking existing clients unless
their individual secret key establishment algorithm allows such signing.

Does that address your concern?

--
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: Wed, 24 Jul 2002 09:58:41 -0700 (PDT)

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

I don't think this is sufficient.  Section 4.6 of RFC 2845 implies (it
only states it when a TSIG is expected) that the TSIG check should be the 
first thing done, which would mean that the client wouldn't know that it 
was the last message of a secret key exchange.

> Does that address your concern?

It still means that a compliant RFC 2845 client will need to deviate from
strict compliance to deal with broken servers.  I still think the bahavior
should be disallowed in TSIG, and GSS-TSIG should mention that 
this might be necessary for backwards compatibility, but should 
not be the default behavior of any new implementations.

Brian