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

From: [email-masked]
Date: Mon, 8 Jul 2002 19:34:41 GMT

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

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?

Thank you.

RFC Editor

> From [email-masked]  Fri Apr  5 10:09:55 2002
> Date: Fri, 05 Apr 2002 13:10:07 -0500
> From: [email-masked] (Randy Hall)
> X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: Erik Nordmark <[email-masked]>
> CC: Bill Manning <[email-masked]>, Danny Mayer <[email-masked]>,
>    [email-masked], [email-masked], [email-masked],
>    [email-masked]
> Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to  Proposed  
>  Standard
> Content-Transfer-Encoding: 7bit
> X-AntiVirus: scanned by AMaViS 0.2.1
> 
> Erik Nordmark wrote:
> 
> > > There were (IMO) bugs in the TKEY, TSIG, and other protocols
> > > that needed fixing, and some changes (IMO) were needed (and
> > > made) to the protocol, but there were no IP issues relating
> > > these issues.
> 
> > Where these bugs in the RFCs or bugs in an implementation of 
> > those RFCs?
> 
> Implementation.
> 
> 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/>

---

From: Kevin Dunlap <[email-masked]>
Date: Tue, 09 Jul 2002 21:37:03 +0000

I have found something in GSS Algorithm for TSIG (GSS-TSIG)
draft-ietf-dnsext-gss-tsig-05.txt, that is in conflict with 
RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG).

In draft-ietf-dnsext-gss-tsig-05.txt, Section 3.1.3.1:
Second Paragraph:

    Confirmation is in the form of a query response with RCODE=NOERROR
    and with the last client supplied TKEY record in the answer section of the
    query. The Response MUST be signed with a TSIG record.......

In the TSIG RFC,  RFC 2845, section 4.2 says:

       When a server has generated a response to a signed request, it signs
       the response using the same algorithm and key.  The server MUST not
       generate a signed response to an unsigned request.

I think the fact that the GSS-TSIG TKEY exchange contains a TSIG on a
response when the request did not contain one violates the TSIG RFC.

I find this problem on April 19.  At that point I notified two of the 
Authors of GSS-TSIG and the DNSEXT WG Co-chairs. 
I now realize, I forgot to post somthing to namedroppers.

-Kevin

-------------------
Your message dated: Mon, 08 Jul 2002 19:34:41 GMT

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 14 Jul 2002 15:26:56 +0200 (CEST)

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

Thanks,
   Erik

---

From: Danny Mayer <[email-masked]>
Date: Sun, 14 Jul 2002 21:25:02 -0400

>it. But the hope is that a fix will be presented and reviewed before Sept 1.

It would be wrong to publish a document with a bug in it.

Danny

---

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];
> Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
> 
> > Erik and Randy,
> >
> 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.

---

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

> 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];
> Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
>
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.
> 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.

---

From: "Levon Esibov" <[email-masked]>
Date: Tue, 23 Jul 2002 09:14:09 -0700

Hi Rob,
please see my comments below.

Thanks,
Levon.

> From: Rob Austein [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 2:01 PM
> To: [email-masked]
> At Mon, 22 Jul 2002 12:09:35 -0700, Levon Esibov wrote:
> >
> 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.
[Levon Esibov] 
I-D based code is widely deployed. Namely it is included in Windows 2000
Professional and Windows XP Professional, all versions of Windows 2000
Server and Windows.Net 2003 Server, Lucent DNS Service 3.1 and VitalQIP
6.0.
> 
> 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.

[Levon Esibov] 
Just to clarify, my proposal to update Section 4.2 of RFC 2845 (TSIG)
addresses wider issue than enabling backward compatibility (enabling
backward compat is just a side-effect of the proposed modification).
Namely my proposed modification removes unnecessary restriction to use
TSIG to sign server's response to un-signed TKEY query in case if secret
key is established on the server side before it is established on the
client side.

For the record: here is my proposal to update Section 4.2 of RFC 2845
(TSIG):
Replace:
"The server MUST not generate a signed response to an unsigned request."

With:

---

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

Below, please.

> Sent: Tuesday, July 23, 2002 10:36 AM
> At Tue, 23 Jul 2002 09:14:09 -0700, Levon Esibov wrote:
> >
> Ok, it's deployed.  Which leaves the other half of the question: how
> badly will lack of backwards compatability harm the users?
> 
> In case it's not clear: there's a lot of stuff out there that's
> deployed but not used (in any operating system, I'm not picking on
> Windows here), so the fact that code has shipped doesn't automatically
> imply a need for backwards compatability.  What will this break, and
[Levon Esibov] 
GSS-TSIG algorithm enables secure dynamic DNS updates. Latter is widely
used/deployed in the intranets of large number of organizations. If we
break backward compatibility then new DNS servers will not be able to
support the secure dynamic DNS updates based on the GSS-TSIG mechanism.

> why is the correct solution not just for the vendors to ship patches?
[Levon Esibov] 
Of course this is a legit possibility. But in my opinion such approach
puts too large burden on users (read administrators) since administrator
of each organization using secure dynamic update will have to deploy
such patch on all (or at least on a large number) of the clients in the
enterprise. Taking into account the number of organizations affected, I
think we should consider alternate solution.

> Why is it that everybody who suggests adding additional complexity to
> DNS these days phrases it as removing unnecessary restrictions? :)/2
> 
> I don't have a serious problem with your proposed change per se, but
> (a) others who've been tracking TSIG and GSS-TSIG more closely might,
> and (b) I'm not (yet) convinced of the need to change RFC 2845.

[Levon Esibov] 
Any TSIG experts care to comment whether they see any problems with
proposed modification?

Thanks,
Levon.

---

From: Brian Wellington <[email-masked]>
Date: Wed, 24 Jul 2002 09:33:34 -0700 (PDT)

> Any TSIG experts care to comment whether they see any problems with

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.

Brian

---

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

> From: Brian Wellington [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 9:34 AM
> To: Levon Esibov
> Cc: Rob Austein; [email-masked]

[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?

---

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

---

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

> Sent: Wednesday, July 24, 2002 9:59 AM
> To: Levon Esibov

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

> 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

---

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.

> from strict compliance w/ RFC 2845.

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

---

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

> Sent: Wednesday, July 24, 2002 10:54 AM
> To: Levon Esibov

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

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

---

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

---

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 12:07:02 -0700

> Sent: Wednesday, July 24, 2002 11:45 AM
> To: Levon Esibov

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

[Levon Esibov] 
When secret key is established on the server side (major_status is
GSS_S_COMPLETE) and output_token is NULL, then no token needs to be
returned to the client and there is no further processing of any tokens
on the client side. In this case TSIG returned in server's response
would enable client to verify that secret key is indeed established on
the server's side.

> deployed.  It shouldn't be changed to support old, broken
applications.

[Levon Esibov] 
Brian, 
I don't think this is the right approach. If modifying RFC 2845 (TSIG)
is the "optimal" for customers and development community then we should
do it. If namedroppers believe that modifying GSS-TSIG draft is more
optimal - then I don't object it. But simply closing the door saying
that "it's not TSIG issue" because it works and because it's a proposed
standard is probably not the right approach, especially since suggested
modification does NOT affect working implementations.

---

From: Brian Wellington <[email-masked]>
Date: Wed, 24 Jul 2002 12:16:38 -0700 (PDT)

> would enable client to verify that secret key is indeed established on

I wish someone had brought this up before.  This is the first time I've 
seen anyone say that the TSIG in this message actually helps with the 
protocol's security.  This really should have come up in April or May when 
the problem was first found.

Maybe the right solution is to change GSS-TSIG so that this can be 
verified within the TKEY exchange, not relying on TSIG.

> modification does NOT affect working implementations.

I've stated my opinion, but we'll see what other people have to say...

Brian

---

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 12:43:41 -0700

> Sent: Wednesday, July 24, 2002 12:17 PM
> To: Levon Esibov
> > > > client-recipient of such message to determine whether the secret
key
> > is
[Levon Esibov] 
Just to clarify, this is not a security issue. If secret key was not
established on the server (while client believed it was) client will
discover it when it tries to use the secret key for the first time, i.e.
when client doesn't receive a properly signed response to its signed
request.

Ability of client to discover that secret key is not established on the
server's side allows client to start a new secret key negotiation
process earlier than later which may be useful in time-sensitive
operations.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Jul 2002 13:08:40 -0700

> verified within the TKEY exchange, not relying on TSIG.

yes

---

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 12:59:25 -0700

> I've stated my opinion, but we'll see what other people have to say...
[Levon Esibov]
I absolutely agree, and encourage other members of the namedroppers to
express their opinion.

Below I summarize opinions/suggestions expressed so far to eliminate
conflict between RFC 2845's (TSIG) requirement to not sign responses to
unsigned queries and GSS-TSIG draft requiring servers to sign the
responses to the TKEY queries as soon as the secret key is established.

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:

2. Update the GSS-TSIG draft to not require that Server signs with TSIG
its last response to the client.

2a. In addition to 2 (above) mention in the updated GSS-TSIG draft that
previous implementations of GSS-TSIG clients require TSIG to be present
in the last server response and mention that implementers of the update
GSS-TSIG protocol may consider including TSIG record on the server side
to interop with old clients. Client may ignore TSIG record in response
from old servers. (version of the draft reflecting these updates is
attached)

2b. In addition to 2 (above) change the algorithm name in the GSS-TSIG
protocol to allow new implementations to distinguish old implementations
(using old algorithm name) from the new implementations.

2c. Do just what 2 above says. Do not even mention any previous
implementations and let new implementations to not interop with widely
deployed old implementations.

Please let us know which solution you prefer.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Jul 2002 14:23:11 -0700

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

(though i would have preferred to see GSS-TSIG always sign its requests, and
to see TKEY specified in a way that made this possible.)

> deployed old implementations.

none of these are practical due to the installed base.

> Please let us know which solution you prefer.

those were my two cents.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 24 Jul 2002 19:27:07 -0400

>deployed old implementations.

I'm stepping into this debate rather gingerly since I'm not totally familiar
with the draft and implementation.  With that caveat, I'd like to say that
2c is really the right approach since an implementation prior to the adoption
of a standard takes that risk knowing that they may have to change
their implementation due to valid issues and changes that have to be
made to a draft. Also the last paragraph of section 3.1.3.1 should be
eliminated. Specific behaviors of implementations of the flawed draft
don't belong there. Those are business decisions.

I am aware that Microsoft has millions of desktops that depend on this
previous behavior but that problem is a business issue that should not
be part of an IETF wg discussion. Though I sympathise with your need
to solve that issue too.

The underlying issue here is that GSS-TSIG is being used as an
authentication mechanism for allowing dynamic updates to DNS by
clients. That updating mechanism should have been the responsibility
of the DHCP server which is responsible for issuing the IP addresses
and ensuring non-duplicate names for the client PC's.  Only PC's
using a DHCP server to get an address need to have the DNS updated,
since PC's with static addresses should already be registered in the DNS.
Unfortunately the strategy of having the clients do the update results in
"dynamic update denied" messages appearing in everyone's syslog
all over the Internet, masking real security problems. Unfortunately more
than 99% of all users of Windows 2000 and later systems are ignorant
of these update attempts.  Moving the dynamic updates to the DHCP
Server, eliminates more than 99% of the underlying problem. Moreover
there is already some sort of trust relationship between the DHCP server
and the PC clients, or at least we hope so since the clients are relying on
it for IP addresses and other information.

FWIW.

Danny

---

From: Yuji KAMITE <[email-masked]>
Date: Thu, 25 Jul 2002 12:42:42 +0900

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

If you take this alternative, the meaning which MAC in the response
implies comes to differ according to protcol (GSS-TSIG or the others).
I think it might be better to add some kinds of description
for notice. For example: 
In GSS-TSIG, the MAC in a response (to an unsigned request) means
confirmation and notification telling that secret is successfully established
via GSSAPI; meanwhile, in the original TSIG, MAC in a response (to a signed 
request) means that the response validly corresponds to the 
received request itself (i.e. secures the transaction), 
as well as authenticates the host's identity. 
client-recipient must be aware of this difference by checking
which algorithm is now being used.

---
Yuji Kamite   (mailto: [email-masked])
NTT Communications
Tel:+81-3-6800-3261, Fax:+81-3-5365-2990

---

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 29 Jul 2002 11:39:14 -0400

> since PC's with static addresses should already be registered 

Well, not really IMHO.  Not to completely excuse the Win2K "enable
dynamic update by default even for statically-assigned IP addresses",
but there are several cases in which a host could benefit from an
ability to update its own DNS info independent of DHCP servers:

1.  System gets its IP address by DHCP, but has more than one valid
    DNS entry (usually in multiple domains).  It's quite likely
    that the DHCP server does not have the power to update DNS
    information in all the appropriate places.  Example:  I might
    have a system that I want to be able to contact as
    gateway.vanitydomain.com, but which gets its IP address as
    part of the PPP negotiation when dialing into an ISP.

2.  System has multiple static IP addresses assigned, but the
    "preferred" IP address may change over time.  Example:  at one
    time recently my laptop had separate static addresses when
    on two separate corporate networks, plus a third static
    address for my home network.  At any one time, only one of
    these addresses was valid--and there were times when it would
    have been nice to update contact info in DNS for that laptop
    when the IP changed.  (Yes, there are automagic ways to do
    this without a DHCP server, although they're fairly painful).

Both of the above are limited/unusual cases, but I believe that
they are valid.

TSIG in general (not just GSS-TSIG) has the concept of secure
dynamic update, and it's there for good reason--without being in
any way limited to DHCP servers only.  So the underlying
issue is not that GSS-TSIG is being used as an authentication
mechanism...that's by design.  The underlying issue appears to be
that GSS-TSIG escaped from the lab as a highly proprietary protocol
rather than being worked on in the standards arena first.

--
Rip Loomis                         Senior Systems Security Engineer
SAIC Secure Business Solutions Group         www.saic.com/securebiz
Center for Information Security Technology   www.cist-east.saic.com

---

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

> > "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:
> 

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