Re: Key Management, anyone? (DNS keying)
"David P. Kemp" <dpkemp@missi.ncsc.mil> Thu, 01 August 1996 15:51 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa08256; 1 Aug 96 11:51 EDT
Received: by relay.hq.tis.com; id LAA16379; Thu, 1 Aug 1996 11:54:18 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016376; Thu, 1 Aug 96 11:54:10 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01031; Thu, 1 Aug 96 11:53:28 EDT
Received: by relay.hq.tis.com; id LAA16366; Thu, 1 Aug 1996 11:53:21 -0400
Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1) id xma016350; Thu, 1 Aug 96 11:52:54 -0400
Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA13272 for <ipsec@TIS.COM>; Thu, 1 Aug 1996 11:55:17 -0400
Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma013267; Thu Aug 1 11:55:04 1996
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA13723 for <ipsec@TIS.COM>; Thu, 1 Aug 1996 11:51:42 -0400
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA02388; Thu, 1 Aug 1996 11:54:55 -0400
Date: Thu, 01 Aug 1996 11:54:55 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Message-Id: <199608011554.LAA02388@argon.ncsc.mil>
To: ipsec@TIS.COM
Subject: Re: Key Management, anyone? (DNS keying)
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
John Gilmore wrote: > In the context of "If you use the IPSEC WG's key management protocol", > it would be a perfectly fine statement for us to say "the key > management software MUST use DNS to obtain IPsec keys". That is unacceptable, given the current state of DNSsec. I don't believe that the requirement to use real certificates for IPSEC keying is going to disappear, and DNSsec has made an explicit decision not to support X.509, PGP, or any other mainstream certificate format. > Those folks who use somebody else's key management protocol, of course, > can get keys by telepathy, voodoo, or by extracting them from a key > escrow database. Instead of telepathy and voodoo, perhaps keys could be gotten by using LDAP (RFC 1777/1798, or LDAP V3: draft-ietf-asid-ldapv3-protocol-01.txt). Or they could be gotten from a Web directory server using URLs as pointers. Or instead of X.509, certificates could be in SPKI format as defined by Ellison, Frantz, and Thomas. Will DNSsec support SPKI certificates? This isn't about "somebody else's" protocol; we're talking about the IPSEC key management protocol which will standardize a set of mandatory, recommended, and optional mechanisms. Manual keying and proprietary key management can still be used with IPSEC data transforms, of course, but that's not particularly germaine to the topic of IPSEC key management. > The WG should never say "this is the only key > management protocol or key publication protocol you can use". Instead > it's "if you want to interoperate with all the other hosts that use > this standard, then you should use the protocols we specify". That is contradictory to the first paragraph. I believe the IPSEC WG position is: "Implementations of the (yet-to-be-agreed-upon) IPSEC Key Management Protocol MUST *include code* to support using DNS to obtain keys." There appears to be rough consensus for that position; I will agree to disagree as long as DNSsec keys are limited to the existing format. But there is no WG requirement that they "MUST *use* DNS to obtain keys." If you want to interoperate with other hosts, you need to implement a mechanism (recommended or required) that is implemented on those other hosts. It is entirely possible that a recommended mechanism could achieve nearly universal coverage, if the mandatory mechanism doesn't meet user's needs. DNS is well-suited as a mechanism to distribute keys associated with IP addresses. It is not as well-suited as an exclusive mechanism to generate and certify long-term keys. It could be used as a default for users who aren't motivated to use any other method. But if I were a cheap Internet user (I am! :-) and had just shelled out a whole 6 bucks for a Verisign cert, I would want to be able to use it. With the world, not just with other owners of the same brand of firewall. The trust models of DNSsec are currently controversial. If it is technically impossible to define DNS RRs to carry X.509, SPKI, or PGP certs (because of their size), then it should at least be possible to define RRs to carry URLs or DNs to allow certs to be retrieved from some other directory. I view that step as a requirement before making a mandatory link between IPSEC key management and DNSsec. > The military will be using different packet-level transforms as well, > since Skipjack is not as far as I know on the IETF standards track. > That would be troublesome, since there is no published spec. I don't > think NSA can twist IESG's arm the way they twisted NIST's, to issue a > standard which says "Poof, it's a standard, even though we refuse to > tell you how it works". They might even have trouble getting IANA to > issue them an algorithm number without specifying the algorithm that > it identifies. Hogwash. 1) The military will be using DES/3DES transforms just like everyone else to get interoperability with the rest of the world. The military believes that there are security advantages to doing crypto in hardware, as well as potential performance advantages and disadvantages, and is including DES in FORTEZZA(tm). (See recent GCN article by Paul Constance.) 2) FORTEZZA(tm) (including Skipjack) is on the IETF standards track, as an algorithm suite in the Transport Layer Security (TLS) protocol. That doesn't imply that anyone other than posessors of FORTEZZA(tm) cards will be expected, or even able, to use that particular mechanism. It meets the need of a large community of users; no objections to standardization of FORTEZZA(tm) as an optional CipherSuite have been raised, or even mentioned, within the TLS WG. Sorry for shouting the name of the card; the lawyers made me do it :-(.
- Key Management, anyone? Joe Tardo
- Re: Key Management, anyone? David P. Kemp
- Re: Key Management and DNSSEC John Gilmore
- Re: Key Management, anyone? David P. Kemp
- Re: Key Management, anyone? John Gilmore
- Re: Key Management, anyone? Ran Atkinson
- Re: Key Management, anyone? Steven Bellovin
- Re: Key Management, anyone? Joe Tardo
- Re: Key Management, anyone? John Gilmore
- Re: Key Management, anyone? Theodore Y. Ts'o
- Re: Key Management, anyone? Steven Bellovin
- Re: Key Management, anyone? Robert Moskowitz
- Re: Key Management, anyone? Hilarie Orman
- Re: Key Management, anyone? Joe Tardo
- Re: Key Management, anyone? Bill Sommerfeld
- Re: Key Management, anyone? Robert Moskowitz
- Re: Key Management, anyone? Stuart Jacobs
- Re: Key Management, anyone? (DNS keying) John Gilmore
- Re: Key Management, anyone? (DNS keying) David P. Kemp
- Re: Key Management, anyone? (DNS keying) Bill Sommerfeld
- Re: Key Management, anyone? (DNS keying) Scott Bradner
- Re: Key Management, anyone? (DNS keying) Scott Bradner