[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
challenges for the IPSEC group
At the Montreal IETF, I posed several open issues for the IPSEC group.
I regard these as very important, since I don't think we can achieve
operational deployment of IPSEC until they're solved (or, in some
cases, until we find a suitable rug to sweep them under).
Conspicuous by its absence is DNSSEC. Apart from the fact that
I consider it to be a solved problem for IPSEC's purposes, that
issue is being discussed in another thread.
The first big issue is name formats. I hate naming discussions,
since they're worse than religious arguments -- not only does everyone
think they're right, they *are* right, because their postulates --
and environment -- differ. But we have to decide how to name the
endpoints we want to protect, because if we don't have a name, we
can't find the right certificate.
An obvious choice is the DNS name, or perhaps the reversed IP address.
These schemes have the advantage that we can use the DNS to distribute
the certificates. (This is, of course, independent of whether or
not we should use the DNSSEC structure to sign the certificates.)
But DNS-like names may not fit into some existing certificate
hierarchies. Also, in an era of DHCP and PPP, the owner of an
address is transient.
If we use DNS-like names, we may want to extend the syntax and/or
mechanism to permit user@domain.name, or maybe user.domain.name.
(But my laptop is smb.research.att.com; does it have a separate key
from me?) A syntax with user names is necessary for user-oriented
keying.
For the server side, we may need something like portnum.TCP@ip.address;
this would let us give each service a separate certificate if we
wished. But we still need a way to have a default key for a host
or even a zone.
Using X.509 certificates has some obvious advantages. But the
disadvantages are even more obvious, at least in the IETF... If
we do adopt X.509, though, we need to munge its name structure
so that we can name the sorts of objects described above. (I've
contemplated trying to register country=cyberspace or some such.)
The second big issue is certificate discovery. How does a host find
the certificate it needs? The DNS is one answer, of course; if we
use X.509 certificates, we could use ``the'' directory service, if
only we had such a beast deployed. SKIP's Certificate Discovery
Protocol, unbundled, is another option, though we'd still need to
define and implement a distributed database so that you could get
a certificate for someone you've never talked to before.
Regardless of syntax, we need a way to find the certificate for the
*real* firewall router for a domain. Even assuming that the encryption
structure precisely matches the DNS name space -- and if firewall
encryptors are used, that is indeed an assumption -- there are some
difficult problems. For example, suppose that there is a firewall
router for gue.com, with the appropriate certificate, but that host
flood-control-dam.gue.com has its own certificate because it has
special security needs. A query for flood-control-dam.gue.com's key
should return that certificate, but an enemy might substitute the
*.gue.com certificate record instead. DNSSEC won't help; private
keys are offline with DNSSEC, so the query/response pair can't be
signed. Possible, the *.gue.com record could have an exception
list, but I fear that that would be unwieldy.
We do need to pick a certificate format -- and that won't be easy,
especially given the feelings on that subject. (The IETF has two
different working groups on the topic.) If the certificates can
have multiple signatures, we need some way to turn this signature
graph into an authorization list. For example, I may wish to allow
John Gilmore access to my system. But I'd should, perhaps, be a mite
suspicious if what purported to be his certificate were signed by
Louis Freeh. But what if it's also signed by Jeff Schiller, using
a key I know to be valid? Or what if there are three levels of
unknown and circular indirection in there? How do I build an ACL
that captures the proper policy? As has been noted, a simple tree
has operational advantages, but it's not at all clear that we can
or should restrict ourselves to such a structure.
Our final challenge is to build something that can be used for other
purposes. It would be nice if SNMPvN could use the same key structure,
for example. Similarly, if we have many PGP keys (and even a few PEM
keys) floating around; it would be pleasant if we could dispense with
the current ad hoc key servers.
--Steve Bellovin
Follow-Ups: