[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key Management, anyone? (DNS keying)
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 :-(.
Follow-Ups: