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

From: "Levon Esibov" <[email-masked]>
Date: Mon, 22 Jul 2002 08:10:31 -0700

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Sunday, July 14, 2002 6:27 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
[email-masked];
> [email-masked]
> Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
> 
> > Erik and Randy,
> >
> > We have <draft-ietf-dnsext-gss-tsig-05.txt> ready to go.  Should we
be
> > waiting for an updated version of this document?
> 
> Yes, this issue needs to be inspected further.
> We've set the deadline to have a proposed solution to be Sept 1 -
after
> that we either publish the document with the bug or figure out how to
> withdraw
> it. But the hope is that a fix will be presented and reviewed before
Sept
> 1.
[Levon Esibov] 
Kevin Dunlap (who discovered this issue) and authors of the draft
continued investigation and determined that GSS-TSIG draft requires
minor modification to not contradict RFC 2845. The essence of the
modification is to not sign GSS-TSIG server's response in response to
not-signed-query sent by GSS-TSIG client. This modification makes
GSS-TSIG compliant with RFC 2845's requirement "The server MUST not
generate a signed response to an unsigned request" without jeopardizing
security of GSS-TSIG algorithm.

I attach the updated version of the draft (-06) that resolves this last
issue. Sections modified to resolve this issue are 3.1.3.1, 3.1.3.2,
4.1.3 and 6. Please let us know if you find any problems with this
modification. If you have any feedback, please respond by the end of day
Wednesday, July 24, 2002. I'd like to submit the updated draft on
Thursday.

Thanks,
Levon.

> Thanks,
>    Erik

---

From: [email-masked] (Randy Hall)
Date: Wed, 31 Jul 2002 17:17:29 -0400

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

I read thru the archives on this discussion and this seems to 
make the most sense of the options presented.  I'm unaware of a
technical downside to this change, and there appears to be less
pain for the installed base (in the interest of disclosure - certainly 
less pain for Lucent and its customers).

I wasn't around when 2845 was developed, nor am I an expert on it, but 
it seems to me that if all the protocols were developed at the same 
time, that it would not have been unreasonable to have written 2845 
this way, since it doesn't seem unreasonable to me to allow the server 
to append a signature if it has the means to do so (and the algorithm
allows this).

Cheers
Randy

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