Part of Steve Crocker's message mentioned the idea of moving the security
boundary away from the end user. I believe this to be the key concept in
understanding and evaluating gateways and message security.
First of all, it should be clear to everyone that end to end security is the
goal we should all strive for, if for no other reason than it provides the best
overall security. The quicker you encrypt and the longer you wait to decrypt
the better -- limit exposure of the clear text version of the message to the
maximum extent possible. In fact it would be best if we could wire the service
into the heads of the end users! Similarly, its best to have the end user
actually do the signing and to have the end user be the one who verifies the
signature.
Next it is important to understand that the goal of end to end security
directly conflicts with the use of gateways. The reason for this is pretty
obvious -- both signature and encryption services necessarily bind their
content into a particular format, and the reason gateways exist is to convert
content from one format to another. This is a fundamentally irreconcileable
conflict, and something has to give somewhere to resolve it.
In a perfect world we'd simply give up on gateways. I realize that this may
sound strange coming from someone who spends much of his time working on and
selling gateway solutions, but nevertheless its my belief that gateways should
be eliminated whereever possible.
But like it or not, we're not going to give up gateways anytime soon. In fact
it seems clear that gateways are destined to flourish in the short term as
never before. And this leads to one of three alternatives:
(1) Tunnel security enclosures through the gateway and hope that end users will
have the necessary capabilities to deal with what they receive.
(2) Convert the security enclosure.
(3) Move the security services away from the end user.
Tunelling is clearly preferred from the security standpoint -- it brings us
back to end to end security. However, we have vast experience with tunneling in
the email world as a result of having had to deal with so many different
formats for so long. And the experience we have clearly indicates that
tunneling is a dog that won't hunt in many if not most environments. People
simply are not willing to add specialized add-on facilities to their email
clients to read, say, MIME formatted material. If you want a specific instance
where this has been tried and has failed, you have to look no further than the
HARPOON work to tunnel MIME material with no corresponding X.400 representation
through X.400 systems. Despite the widespread availability of free software to
interpret the resulting objects this approach has proved to be nothing but a
dismal failure. It bothers me to have to say this, since it was at least partly
my idea to use the tunneling approach rather than lose all the MIME semantics
we worked so hard to specify, but its true nevertheless.
There has been considerable discussion of the conversion approach on these
lists and elsewhere. Note that "conversion" here refers to changing out the
security service that surrounds the key/signature interchange. It does not
refer to decrypt-reencrypt or signature-verify-resign gateway operations, which
are effectively not especially different from moving the security boundaries
aroud.
I believe that both the difficulty and utility of implementing conversions of
security services have been overstated. MOSS, for example, can be used to
represent most applications of PEM and PKCS, so the three could be made to
interoperate. Its even conceivable that we could come up with ways of matching
keys against certificates so that more complex conversions would be possible.
Security multiparts even allow for simultaneous parallel use of multiple
security services on the same content.
But so what? The problem with security conversions is that while you may be
able to change out the security service, you cannot change the format of the
underlying content, and its that format that causes most of the problems, not
the security service itself. In the case of both security multiparts and S/MIME
the underlying material is still going to be MIME, and thus depends on the
availability of MIME capabilities at either end of the message path. But the
lack of the availability of these capabilities is usually why gateways are
deployed in the first place. Its largely axiomatic that the presence of
gateways must indicate a lack of universal capbility support.
So in many cases this leaves us with no other choice but to move the security
boundaries around. Security will no longer be implemented directly on end user
systems. And this in turn divides up into two subcases -- you can move them
along the path the message takes or you can move them sideways, implementing
remote signature and authentication services users can submit messages to. The
latter has the advantage that messages can be stored in their encrypted and
signed forms, thus offering a small measure of added security. (There are also
some problems peculiar to S/MIME that I've discussed previously.)
In either case, however, moving the security boundary away from the end user
leads to a situation where a group of systems has to be secured as a group
rather than as individual machines. This in turn is just one of many cases
where groups of systems with specialized policies, procedures, and requirements
arise. There are plenty of reasons why such groupings exist independent of
security issues, with the use of a proprietary mail systems behind a gateway
being the most obvious. We've been calling such groups of systems enclaves when
they have arisen in other aspects of email work. I will therefore refer to this
specific case of them as security enclaves here.
Since security services are implemented at the borders rather than within a
security enclave has to be treated as an entity which is secured as a whole.
This can be done in various ways, with varying degrees of effectiveness. Its
regarded as axiomatic that the larger an enclave is the harder it is to secure.
This may even be true in general, but it breaks down when you get to specifics,
especially when you attempt to enclose smaller regions at the expense of
putting the boundaries in funny places. The placement of the boundaries becomes
more important than overall enclave size. What does seem to be generally true
is that better defined the boundaries are the easier the enclave is to deal
with.
There are two special subsubcases that are of particular importance. The first
arises when a proprietary email system is directly front-ended with a gateway
that provides security services. The location of the gateway itself thus
defines the security enclave.
This actually works fairly well in practice because many of the proprietary LAN
email systems have their own means of providing internal security. They may not
provide all that much (cc:Mail, for example, only uses 40 bit keys internally
to avoid problems with export), but its better than nothing. These things
typically reside well inside of corporate firewalls, which also helps some.
These sorts of systems are generally called upon to interoperate with lots of
other stuff. This in turn argues for message content security at the
application layer, for signatures to be as transparent as possible, for it to
be possible to sign things using multiple signature interchange methods at the
same time, for encryption to be as clearly labelled as possible, and for it to
be possible to encrypt using multiple key interchange methods at the same time.
These were all major goals of the design of security multiparts, and I believe
we addressed all of them in that specification.
The second important subsubcase is where the security service is located as far
away from the user as possible -- specifically, as part of an Internet firewall
or just behind it. There may be one or more internal gateways between the user
and this service. In this case the entire corporate net is seen as secure. Its
the Internet that's regarded as insecure.
This case really raises the hackles on a lot of people, myself included. I am
getting tired of the notion, heavily promoted in the media, that the Internet
is nothing but a huge collection of hackers just waiting to steal anything you
send out, whereas your own local network is nothing but sweetness and light --
a veritable fountain of truth and virtue.
The reality is that most people out there on the Internet *don't* *care* about
you or the messages you send. Its hard for a lot of people to grasp their
relative unimportance in the overall scheme of things (corporate officers, it
seems, are often so afflicted). And worse, if there's any real danger, its far
more likely to be local, where there often are people who *do* *care*, and in
fact may not like you at all... In other words, I see this approach as all too
often being one that solves the wrong problem.
My animadversion of it notwithstanding, its an undeniably popular approach. And
this is an especially difficut problem because there are so many ways to
approach it.
For one thing, you can definitely make a case that enclave-to-enclave security
might best be addressed at the transport or network layers. Why not secure
everything and not just email? Why expose any part of the traffic between
enclaves? IP level security may well be the best solution in this case.
Security at the message transfer level is also an option. We know how to build
such services and there's a draft that describes how to do it for SMTP.
Securing the entire email transaction provides at least some protection against
traffic analysis, something that PEM, MOSS, PCKS#7, S/MIME and even PGP do not
address at all.
Of course one disadvantage of such approaches is that most of the defined
services don't scale as well as those that are intended for end to end use do.
There is nothing that precludes the definition of such services that do scale,
but the ones that are readily available now (e.g. Kerberos V4) do not.
So what are gateway writers supposed to do? Well, the first conclusion to be
drawn is that gateways get drawn into security matters by their very existance.
The ability to use of tunneling or conversion cannot be counted on, so gateways
get called upon to perform these functions when clients cannot do it
themselves.
The second conclusion is that gateways may be asked to host a variety of
security services packaged in a variety of ways. One of the goals of security
multiparts was to lessen the burden on gateways by providing a single message
content encapsulation that could be used by multiple services. S/MIME's non-use
of this approach thus considerably complicates the life of gateway writers --
unnecessarily, in my opinion. But even if everyone used security multiparts
there would still be the cases where services are implemented at other layers.
The long and short of it is that its all pretty messy, and it will probably
get a whole lot messier in the future.
Ned