DNS security has been advocated as "the" answer for IPsec key management. >From: Steven Bellovin > >The problem we have is the name-to-address mapping. Even though security for DNS is a serious problem, it would be a bad architectural design to link IPsec strongly to DNS security. First, it violates some of the basic IETF guidelines for Internet architecture to link mechanisms together in a way that makes successful fielding require both systems to function. Second, name-to-address mapping does not matter for many applications of IPsec. It does not matter what authenticated address a computer has as long as it has the correct authenticated "name" (eg dynamic assignment of IP addresses). Given the above issues with DNS security, DNS certificates still are a viable mechanism for establishing trusted names for end systems. The use of DNS as a certificate distribution system seems less important given the architectural issues and the ability of peer systems to exchange certificate chains. While I have reservations on the use of DNS, the ongoing work to rapidly field DNS based solutions is exciting and will provide significant benefits. I hope that additional work will continue on solutions using other certificate formats. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! --------------------------------------------------------------
-- BEGIN included message
- To: dpkemp@missi.ncsc.mil
- Subject: Re: Key Management, anyone?
- From: "Steven Bellovin " <ipsec-approval@neptune.hq.tis.com>
- Date: 23 Jul 96 00:39:56
- Cc: rja@cisco.com,wdm@tycho.ncsc.mil,mjo@tycho.ncsc.mil,ipsec@tis.com
What smb said (not what you think he said, or what you think he should have said) was that "without DNSSEC, there's an unauthenticated step." I disagree. PGP provides some level of authentication, without DNSSEC, using plain DNS (plus PGP cert resource records) as a directory service. I confess that my mind is boggled by the thought of people arguing over what I did or didn't say or mean. Makes me feel like some sort of mystic oracle (but please don't offer me any goat entrails, even as a MIME attachment...). Anyway -- I stand by my statement, though I can and will expand on it a bit, and add a few qualifiers. The problem we have is the name-to-address mapping. Without DNSSEC -- or some local mechanism -- this step is completely unauthenticated, from the perspective of more-or-less vanilla applications that just call gethostbyname() or equivalent. The certificate for plugh.com may be signed by the director of NSA, the head of the (former) KGB, and John Gilmore -- and it's quite useless if an enemy can slip in a bogus IP address, since the firewall-based encryptor knows nothing but the IP address. To be sure, the DNSSEC tree does have what is (for some purposes) an inappropriate root. That can be dealt with by using manually configured certificates for subtrees of interest. It may not be a great solution -- and it's certainly not pretty -- but it permits local control and policies over an important step. (One could even use a PGP-like web of trust to distribute sets of zone keys.) To be sure, this only works if the implementations of DNSSEC permit local override keys -- but I think that it does. If not, it can be changed to do so, without affecting the over-the-wire protocol. What are the alternatives, assuming a smart application? If I want to talk to plugh.com, I can retrieve its certificate from my own trusted certificate hierarchy. I still need its IP address, though, which implies that I need DNS. If an enemy can spoof that, through lack of DNSSEC, we'd have a denial of service situation -- which is still better than information leakage, but far from ideal. What we still lack, though, is some standard way to tell a firewall encryptor, or even a bump-in-the-cord encryptor, which certificate to use. There's no reason we can't design such a protocol, of course, but we don't have one yet, and we'd have to confront the issue of identifying the proper outbound encryptor(s). Would that scheme work? Sure. The problem is that it doesn't scale well on the Internet, if our goal is ubiquitous cryptographic security. We'd need a separate tree, parallel to the DNS, with operational characteristics very similar to the DNS, but without a decade or so of operational experience in the implemenation. Outbound certificates are much less of a problem, since the local host or firewall can be told what certificate to use. My laptop may use its Fortezza card (well, your laptop might; I don't have a Fortezza card), a multiuser host might look up the user's certificate or use a per-host certificate, the firewall can check the source IP address (and if you can't trust that locally, you have no business using firewall-based encryption), etc. In a separate message, I list several important challenge areas for the IPSEC group. By challenges, I mean ``problems we have to solve in order to use IPSEC''. DNSSEC isn't on the list, since I consider that to be a solved problem for our purposes. --Steve Bellovin
-- END included message