[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Key Management, anyone?

> From: John Gilmore <gnu@toad.com>

> Flame off, please.

I hope the tone of my message was not perceived to be antagonistic; it
wasn't intended to be.  Incredulous is more like it.

> It will be hard to do user-specific keying in IPSEC firewalls
>  ...
> For IPSEC firewalls to work, DNSSEC or something very much like it
> will need to work.


Bellovin's second of three firewall properties is:

    "Only authorized traffic, as defined by the local security
     policy, will be allowed to pass." (C&B, page 9.)

If the definition of authorized traffic is "anything that can be
tunnelled between IPSEC firewalls is allowed", then relying on the
security of DNS to provide unspoofable name-to-IP translation may
be useful.

But some local security policies require firewalls to authenticate users
before traffic is allowed to pass.  Since users don't have IP addresses,
DNSSEC is irrelevant except to the extent that it serves as a convenient,
but not necessarily trusted, transport mechanism for keying material that
may have been certified elsewhere. In that sense, requiring the
"Security" part of DNSSEC is a misnomer, because all that is required is
a generalized Resource Record format that can accommodate the distribution
(not the certification) of keys.
 
>    I think Steve was talking about what we
> expect to be the most common case, which will have to be invisible to
> users and very easy to administer (no config files required) so that
> it will be easy to deploy.  We're interested in operational security,
> not theoretical security so complex that nobody uses it.

That may be what Steve meant, but it didn't appear to be what he said.
It appeared that he was claiming that a single-rooted key certification
heirarchy explicitly tied to the DNS heirarchy should be *required* in
order to use IPSEC, or equivalently, that IPSEC is useless without DNSSEC.

It's interesting that some of those who have strenuously objected to
single-rooted key heirarchies in the past are now finding that they have
some operational advantages.

> If DoD doesn't trust the DNS to communicate keys among DoD-trusted
> sites, it can write its own hardened DNS implementation, or can tell the
> public community what isn't trustworthy about the DNS so that we can
> all fix it together.

That's the whole point - we don't need a hardened DNS*.  Regular old
DNS, with new record types to allow it to distribute certificates, would
be fine. Perhaps it would be clearer to separate the roles of DNS as a key
certification heirarchy and as a directory service. There is no question
that DNS is pre-emininently qualified for the latter role.

It may also be convenient for some people with low-end security requirements
(not a pejorative term - the data to be protected may be of low value)
to use DNSSEC in the former role, but there should be no implication that
DNS-certified keys are required in order to use IPSEC - we as a working
group should not be that narrowly-focused.


--
*Hardened DNS (DNS-certified keys for the purpose of improving
the reliability of name-to-address mapping) is quite useful for it's
own sake. It's just seductively misleading to extend the use of
"DNS keys created to secure DNS data" into the domain of "keys to
secure IPSEC traffic".
Follow-Ups: