FW: w2000 DNSSEC compliance?

Tue Mar 7 13:00:59 UTC 2000

	I have read some messages related to MS.  Came across this email, I
forwarded just for information.
	John

> -----Original Message-----
> From: Stuart Kwan [mailto:skwan at EXCHANGE.MICROSOFT.COM] 
> Sent: Monday, February 28, 2000 10:04 PM
> To: NTBUGTRAQ at listserv.ntbugtraq.com
> Subject: Re: w2000 DNSSEC compliance?
> 
> 
> Hi Dan,
> 
> When RFC 2137 "Secure Domain Name System Dynamic Update" was written, it
> was
> based on the then-current DNSSEC spec, RFC 2065 "Domain Name Security
> Extensions".  RFC 2535, a re-write of DNSSEC based on implementation and
> deployment experience, obsoletes RFC 2065.  A side-effect of the
> deprecation
> of RFC 2065 is the invalidation of RFC 2137.  RFC 2137 is not safe for
> implementation.
> 
> Upshot:  there is no IETF standard for DNS secure dynamic update.
> 
> Two years ago we had to make a call on whether or not we should implement
> DNSSEC (RFC 2065) in Windows 2000.  DNSSEC - which is a public key
> infrastructure unto itself - is very complex.  In our judgment, at the
> time,
> it was not ready for implementation and deployment.  It followed that RFC
> 2137 was also not ready for implementation and deployment.
> 
> Still, we needed a solution for secure dynamic update.  As it happened,
> the
> DNSIND working group in the IETF had already recognized that DNSSEC was
> not
> appropriate in all situations, and that there was a demand for a
> lightweight
> (shared secret) alternative.  Two complementary Internet-Drafts were
> published to satisfy this requirement: "Secret Key Transaction
> Authentication for DNS (TSIG)", and "Secret Key Establishment for DNS
> (TKEY
> RR)".
> 
> TSIG and TKEY alone do not solve the key distribution problem inherent in
> any secret key system.  However, both mechanisms allow for extension,
> which
> permitted us to publish a third complementary draft, "GSS Algorithm for
> TSIG
> (GSS-TSIG)".  The GSS-API mechanism enables us to use integrated Windows
> security to solve the key distribution problem, and ensure our customers
> will have no additional key management burden associated with secure
> update.
> 
> The GSS-TSIG draft has been available since November of 1997.  Microsoft
> would be happy to assist any vendors who wish to develop an independent,
> interoperable implementation.  We have already demonstrated
> GSS-API/Kerberos
> interoperability between Windows 2000 and other GSS/Kerberos
> implementations
> (see below for more information).
> 
> The DNSEXT working group (a consolidation of the DNSIND and DNSSEC working
> groups) is currently working on an Internet-Draft to replace RFC 2137.
> This
> draft, called "Simple Secure Domain Name System (DNS) Dynamic Update",
> separates the authentication of an update from the later DNSSEC
> authentication of the data.  The draft acknowledges the TSIG/TKEY method
> as
> a way to authenticate updates.  When TSIG, TKEY, GSS-TSIG, and Simple
> Secure
> Dynamic Update reach standard status, there will be an IETF standard for
> DNS
> secure dynamic update.
> 
> Microsoft is continuing to evaluate the viability of and demand for
> DNSSEC/public key-based security for DNS.
> 
> Cheers,
> - Stuart
> 
> The DNSEXT working group home page:
> http://www.ietf.org/html.charters/dnsext-charter.html
> RFC 2065: http://www.ietf.org/rfc/rfc2065.txt?number=2065
> RFC 2137: http://www.ietf.org/rfc/rfc2065.txt?number=2137
> RFC 2535: http://www.ietf.org/rfc/rfc2065.txt?number=2535
> "Secret Key Transaction Authentication for DNS (TSIG)":
> http://www.ietf.org/internet-drafts/draft-ietf-dnsind-tsig-13.txt
> "Secret Key Establishment for DNS (TKEY RR)":
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-00.txt
> "GSS Algorithm for TSIG (GSS-TSIG)":
> http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-05.txt
> White paper on Kerberos interoperability:
> http://www.microsoft.com/windows2000/library/howitworks/security/kerbint.a
> sp
> Press release on Kerberos interoperability:
> http://www.microsoft.com/PressPass/press/2000/Jan00/CyberSafePR.asp
> "Simple Secure Domain Name System (DNS) Dynamic Update":
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update
> -0
> 0.txt
> 
> 
> -----Original Message-----
> From: Dan Stromberg [mailto:strombrg at NIS.ACS.UCI.EDU]
> Sent: Thursday, February 24, 2000 10:55 AM
> To: NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM
> Subject: w2000 DNSSEC compliance?
> 
> 
> It appears that Windows 2000 requires DDNS for active directory.  This
> is not an entirely unreasonable thing.
> 
> It appears that DDNS is not secure without either RFC 2137 (DNSSEC for
> DDNS: http://www.isi.edu/in-notes/rfc2137.txt), or microsoft's
> now-proprietary version of DNSSEC which was based on a now-orphaned IETF
> draft.  This is not good.
> 
> Naturally, Microsoft, as with any other vendor, should be expected to
> implement the RFC.  This is what interoperability and good faith are all
> about in the computer industry.  This has obvious security implications
> - if you can't interoperate with the products of other vendors without
> weakening security because of microsoft's race to get w2000 to market
> (or cavalier attitude toward interoperability?), that's a big problem.
> It is in microsoft's power to fix this.
> 
> Anyway, has anyone heard any rumors as to Microsoft's plans for
> implementing RFC 2137 properly?
> 
> For more information, see
> http://www.ins.com/knowledge/whitepapers/win_2k_dns_integration.asp.
> This looks like a pretty good paper on the subject, but the paper fails
> to acknowledge that one option is to simply not use active directory
> until microsoft fully implements RFC 2137.
> 
> ------------------------------------------------------------------------
> Delivery co-sponsored by Trend Micro, Inc.:
> 
> http://www.antivirus.com/neatsuite.htm
> 
> ScanMail for Microsoft Exchange
> * Stops viruses from spreading through Exchange Servers.
> * Eliminates viruses from email in real time, even unknown macro viruses
> * Filters spam (unsolicited junk email).
> * Sends customized virus warning messages to specific parties and admins
> * Remote installation and management via web or ScanMail's Windows GUI
> ------------------------------------------------------------------------