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

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

> -----Original Message-----
> From: Brian Wellington [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 12:17 PM
> 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 11:45 AM
> > > To: Levon Esibov
> > > Cc: Rob Austein; [email-masked]
> > > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> > > Proposed Standard
> > >
> >
> > > > [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.
> > >
> > > 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.
> 
> 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.
> 
[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.

--
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: Danny Mayer <[email-masked]>
Date: Wed, 24 Jul 2002 19:27:07 -0400

At 03:59 PM 7/24/02, Levon Esibov wrote:

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

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