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

From: "Levon Esibov" <[email-masked]>
Date: Mon, 22 Jul 2002 12:09:35 -0700

> -----Original Message-----
> From: Levon Esibov
> Sent: Monday, July 22, 2002 8:11 AM
> To: 'Erik Nordmark'; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; iesg-
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
>
> 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.
>
[Levon Esibov] 
Olafur brought to my attention that in order to enable interoperability
between the old clients and new servers we may need to introduce new
"Algorithm Name". This will allow clients to request new behavior when
they negotiate security context with servers that support both old and
new GSS-TSIG behavior. Such servers will be able to decide whether to
include or not include TSIG record in its response to client's TKEY
query. If new client sends a TKEY query with new "Algorithm Name" to an
old server, then server will not recognize the new name and client may
need to restart negotiation of the security context using the old
"Algorithm Name". 

An alternate suggestion to resolve the issue is to update Section 4.2 of
RFC 2845 (TSIG). Namely, I propose to extend the statement "The server
MUST not generate a signed response to an unsigned request." as follows:
"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."
Allowing response to unsigned TKEY query to be signed enables
client-recipient of such message to determine whether the secret key is
established on the server's side, thus preventing signing of messages
that are going to fail.

Please respond with your feedback on which solution you prefer.

Thanks,
Levon.

--
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: Rob Austein <[email-masked]>
Date: Mon, 22 Jul 2002 17:00:51 -0400

> Please respond with your feedback on which solution you prefer.

Well, if you're going to phrase it that way....  Other things being
equal, I'd prefer a third option that you didn't list: fix the
GSS-TSIG RFC-to-be and punt on backwards compatability with clients
that implemented from the now-known-to-be-broken GSS-TSIG I-D.

In theory, anybody who ships product code based on an I-D deserves
what they get if the protocol changes out from under them.  If we're
going to bend over backwards trying to help such folks out, it'd be
good if somebody could first explain why this is worth doing, perhaps
in terms of how widely used the I-D-based code is and how seriously
those users would be harmed if we ignored the issue.

In other words: bug-compatibility has costs, so it'd be nice to know
whether the problem is serious enough to be worth paying those costs.

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Jul 2002 14:33:50 -0700

> I'd prefer a third option that you didn't list: fix the GSS-TSIG
> RFC-to-be and punt on backwards compatability with clients that
> implemented from the now-known-to-be-broken GSS-TSIG I-D.

this seems like the normal plan, yes?  there is a doc/spec bug.
we fix it.  that's our normal job, yes?

randy