[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key Management, anyone?
Flame off, please.
> Are you saying that, despite the seesaws on user keying from
> mandatory to recommended and now back to mandatory, you believe there is
> *no hope of ever doing user-specific keying in IPSEC* ???
It will be hard to do user-specific keying in IPSEC firewalls, which
are certainly a large part of the IPSEC market. I think ten or twelve
commercial firewall vendors have interoperated
(http://www.rsa.com/rsa/SWAN/), while no commercially available
end-systems like Unix or Windows boxes have yet done so. For IPSEC
firewalls to work, DNSSEC or something very much like it will need to
work.
As for what is implemented in end-user systems that run IPSEC, that's
up to the system implementer. Certainly the information is available
to do user-specific keying, if the market demand exists. I expect
that if a user provides key material, and the system at the other end
of the connection accepts it, it can be used; if not, a default host
key will be used if one can be found.
> In other words, network stacks are not to be allowed to propogate user
> context down to whatever layer the transform engine communicates with
> the key management daemon, and key management daemons are not to be allowed
> to contact the user or consult configuration files or caches or directory
> servers other than DNSSEC to verify certificate names?
This sounds like a vast overstatement. Let's not bash too much on this
particular strawman.
Key management daemons will be "allowed" to do whatever falls within
the documented end-to-end protocols. If they want to pop up a window
to the user, examine config files, or talk to a user-specific smart
card, they can do that. 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.
> This is a critical point, because a community of users (such as the
> DoD) can establish a certificate structure that it trusts to be correct,
> but may (will :-) not be willing to trust a DNS directory service
> administered by who knows whom.
The DoD can certainly put in the effort to configure their systems to
trust or mistrust any particular keying method or set of sites. 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.
Secure DNS only requires the use of a specific algorithm for general
interoperability; the algorithm in use is identified in each
signature. If DoD doesn't trust the RSA algorithm, I'm sure IANA
would assign DoD an algorithm identifier for a classified signature
algorithm and certificate format. It could use that algorithm to
interoperate among its own hosts. Please explain how using DNSSEC
packet formats to communicate these signatures and keys would somehow
render them untrustworthy.
If the problem is not with DNS or RSA security per se, but that DNS
doesn't provide the features that DoD needs, it should define its own
unique key management protocols and key communications methods. I
understand that there's a need to use key-escrowed and/or classified
algorithms in the DoD community; these needs are not shared by the
rest of the world. Bending the protocols used to secure
general-purpose traffic, so that they can accomodate unique and
intrusive requirements, is probably not the best use of the working
group's energy.
John Gilmore
References: