OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: (Fwd) Re: Win2000 and BIND GSS-TSIG Interoperability?
From: Paul B. Hill (pbhMIT.EDU)
Date: Fri Mar 10 2000 - 10:11:39 CST

Hi,

> > ...I recall past discussions
> > on this list where some at the ISC had indicated that
> > Microsoft had released insufficient details about
> > their GSS extensions to TSIG to allow interoperability
> > for secure dynamic updates to be built into BIND.
>
>We have been unable to determine whether or not it is possible to implement
>Microsoft's GSS-TSIG DNS extension that does not require the use of
>Microsoft's version of Kerberos to be a "first class citizen" in Microsoft's
>DNS architecture. From the numerous press reports (e.g.,
>http://dailynews.yahoo.com/h/zd/20000228/tc/20000228169.html), it doesn't look
>too good.
>...

Since I was one of the people quoted in the referenced article I feel I
have the responsibility to help clarify the situation.

First, Microsoft's Windows 2000 Domain architecture does require that the
Windows Domain Controller runs the Microsoft Kerberos server (KDC).
However, it does not preclude a site from running other non-Microsoft
Kerberos servers as well. This leads us into the topic of cross realm
configuration and support. Microsoft does provide tools to configure cross
realm configurations and interactions with non-Microsoft Kerberos
implementations. This message does not go further into the details of cross
realm support.

If a developer writes an application or application server that uses the
MIT Kerberos libraries and/or GSSAPI libraries to add authentication there
are few interoperability issues that will be encountered. When a UNIX-based
KDC or application server receives a ticket from a Microsoft realm/Domain
the authorization field will be ignored. The authentication can still be
validated in the same manner that would be used if the ticket came from any
other implementation.

In the case of a BIND implementation that wishes to support Microsoft's
GSS-TSIG DNS extension, the BIND server would have to determine the
authorization using the same method that it would have to use when
presented a ticket from a different implementation.

In other words, my server may assert to your server that a DNS record
should be changed. Your server can determine that my server is who it
claims to be. Then your server must determine if I should really have the
privilege of making that change.

It should also be possible to write application servers that are hosted on
Windows 2000 that use a different authorization method than the
authorization field. The interoperability problem that sites face today is
that all Microsoft application server expect and require the data in the
authorization field. The corollary is that Microsoft application servers,
such as Exchange, require a ticket that was generated by a Microsoft KDC.
This doesn't prevent a 3rd party application server developer from writing
a more generic solution in their product, even when it is running on
Windows 2000.

There are other details that have to be considered. I have not examined the
details of Microsoft's DNS extensions. Although it should be possible to
write an implementation of BIND that will support the extensions, I do not
know if Microsoft has provided sufficient configuration options to enable a
3rd party DNS server to be referenced.

Microsoft's lack of full disclosure about the internals of the
authorization data field does present other interoperability issues that
should not affect possible implementations of BIND. It does a require a
site that either requires Kerberos version 4 support or has other reasons
to operate a UNIX-based Kerberos realm to go to the additional expense of
maintaining cross realm support for a Windows 2000 Domain. It causes
interoperability problems for sites using DCE. It prevents 3rd party
application developers that wish to host their services on operating
systems other than Windows 2000 from taking advantage of the authorization
data field; this in turn will tend to skew benchmarks and take additional
round trips on the network which may put the application developer at a
competitive disadvantage when being reviewed by shallow journalists. It
also raises large barriers to developers wishing to provide a 3rd party
alternative to a Microsoft Domain Controller, for example the SAMBA
development community.

I hope this has helped to clarify the situation more than further confuse it.

Paul

----------------------------------------------------------------------------
Delivery co-sponsored by SUNBELT SOFTWARE - http://www.sunbelt-software.com/

STAT: NT VULNERABILITY SCANNER - http://www.sunbelt-software.com/stat.htm

Ever had that feeling of ACUTE PANIC that a hacker has invaded your
network? Plug NT's holes before they plug you. There are now over 750
known NT vulnerabilities. You just have to protect your LAN _before_ it
gets attacked. STAT comes with a responsive web-update service and a
dedicated Pro SWAT team that helps you to hunt down and kill Security
holes. Built by anti-hackers for DOD sites. Download a demo copy before
you become a statistic.
----------------------------------------------------------------------------