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

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 10:33:37 -0700

> -----Original Message-----
> From: Brian Wellington [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 9:59 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:
> 
> > > -----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."
> 
> 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.

[Levon Esibov] 
Section 4.6 of RFC 2845 reads "When a client receives a response from a
server and expects to see a TSIG, it first checks if the TSIG RR is
present in the response."

There are two possible scenarios in secret key exchange:
1. when client knows that coming response must be the last message
2. when client doesn't know that coming response must be the last
message

Individual secret key establishment algorithm may require that in case
1. client first checks if the TSIG RR is present in the response.

In case 2. client indeed doesn't know that the message it received is
the last one and therefore doesn't check if the TSIG RR is present in
the response when it receives the response, but this behavior does NOT
violate Section 4.6 of RFC 2845 because it says "and expects to see a
TSIG", while client in case 2. does not expect to see TSIG.

> 
> > 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?
> 
> It still means that a compliant RFC 2845 client will need to deviate
from
> strict compliance to deal with broken servers.
[Levon Esibov] 
I think my explanation above demonstrates that client will not deviate
from strict compliance w/ RFC 2845.
Agree?

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

--
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 10:54:21 -0700 (PDT)

> TSIG", while client in case 2. does not expect to see TSIG.

You're assuming a particular implementation.  Another implementation might 
see and attempt to verify the TSIG before doing anything else.  This isn't 
too important, though, so I won't bother arguing.

> > > 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.
> > >
> > It still means that a compliant RFC 2845 client will need to deviate from

It requires that a server have special case code to allow deviation from 
strict compliance in a special case.  Is that any better?

> > not be the default behavior of any new implementations.

Do you have any opinion on this?

Brian