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

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 11:19:57 -0700

> -----Original Message-----
> From: Brian Wellington [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 10:54 AM
> To: Levon Esibov
> Cc: Rob Austein; [email-masked]
> Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
> 
> > [Levon Esibov]
> > I think my explanation above demonstrates that client will not
deviate
> > from strict compliance w/ RFC 2845.
> > Agree?
> 
> It requires that a server have special case code to allow deviation
from
> strict compliance in a special case.  Is that any better?

[Levon Esibov] 
Frankly I don't see any negative impact of such server behavior. I'm
also not sure why you refer to this as "special case code". Yes, I
recommend specifying this "special case" server behavior in the RFC
2845, but as far as I understand it doesn't cause any "special case
code" on the server side. It simply removes unnecessary restriction (/*
I see Rob smiling... */) allowing implementations of secret key exchange
algorithms to start using TSIG as soon as secret key is established.

> 
> 
> > > 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.
> 
> Do you have any opinion on this?
[Levon Esibov] 
Yes, I prefer making modification to TSIG rather than prohibiting
GSS-TSIG server to sign responses to unsigned TKEY queries for the
following reasons:
1. Allowing response to unsigned TKEY query to be signed enables
client-recipient of such message to determine whether the secret key is
indeed established on the server's side.
2. Enabling GSS-TSIG servers to interoperate with old and new clients
complicates server implementation.

--
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 11:45:23 -0700 (PDT)

> algorithms to start using TSIG as soon as secret key is established.

You're suggesting changing an existing (proposed) standard to allow
backwards compatibility in a limited case with clients that implemented a
fundamentally broken non-standard draft.  Sure sounds like a special case
to me.

> indeed established on the server's side.

Doesn't the verification of the GSSAPI token allow this too?

> complicates server implementation.

Yes, but this is a GSS-TSIG issue, not a TSIG issue.  TSIG works and is 
deployed.  It shouldn't be changed to support old, broken applications.

Brian