I regret that I'm unable to attend the W^5, though I had hoped to. I
have a reasonably stable set of rough recommendations for addressing
the security needs of HTTP in the short-to-medium term; I've tried to
write it in an accessible way. I'm interested in any comments or
whatever, and would like to remain involved with what people want to
do for integration.
- Marc
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
ADDING SECURITY TO THE HYPERTEXT TRANSFER PROTOCOL
--------------------------------------------------
This document is intended to be a review of some available security
mechanisms and their usefulness in adding security to the HyperText
Transfer Protocol (HTTP), a protocol associated strongly with the
World Wide Web (WWW).
I assume security will be useful in the short run for interactive uses
of HTTP (e.g. the PUT and CHECKIN/OUT commands) as well as possible
access control. In the longer run, a security service would be
necessary if publishers are going to make copyrighted material
available via HTTP on some basis for charge. In considering
solutions, I believe an answer to the first set of problems is most
urgent, though something which will also address commercial concerns
is preferable.
First, I'll address what I believe the security needs for HTTP will
be, both for the short term and for the long term.
- LOCAL USER AUTHENTICATION seems likely to be needed, and soon. As
authoring tools become available and become integrated with browsing
tools, it will be desirable to allow people to create and edit their
hypertext documents through the standard HTTP protocol. By "local"
I mean "mostly used for people within the same administrative
domain"; it seems likely that this will be a big need early on.
User authentication and message integrity checking should suffice
for this application; disclosure protection may be desirable in some
cases. This authentication could also serve as a mechanism for
access control if restricted information is to be put in the Web.
- REMOTE USER AUTHENTICATION for similar purposes, such as group
editing, collaborative hypertext, and annotations is also a
significant need. It will probably be needed somewhat later than
local authentication. User authentication and message integrity
checking are also probably enough, though disclosure protection is
also sometimes desirable.
- COMMERCIAL TRANSACTION AUTHENTICATION will likely be slower to catch
on than the above; the political barriers to its widespread use are
nontrivial. Commercial transactions require the greatest security,
obviously, and authentication should be bolstered with
non-repudiation of origin. Disclosure protection becomes more
important, and the access control of the server is critical.
Four different approaches were considered seriously (not including toy
solutions, like cleartext password authentication.) First, I'll
mention the two that I am not reviewing in detail:
PRETTY GOOD PRIVACY (PGP) is an implementation for public-key email
encryption. PGP is in the process of becoming more "respectable;"
however, there is currently no abstract specification for message
format, encapsulating MIME objects, and the like. There is not yet
a PGP FAQ.
COMMON AUTHENTICATION TECHNOLOGY (CAT) has an IETF working group
building a general framework for this kind of security service. It
looks good, but it also doesn't look ripe for coding yet; it's
likely that this will be the solution HTTP should migrate to in the
long term. It's described in a variety of Internet Drafts starting
with "draft-ietf-cat".
The two systems which I will review in detail:
KERBEROS is a network authentication system based on a tickets
obtained from an authentication server. More information, including
pointers to specs and the like, is available in the
comp.protocols.kerberos FAQ.
PRIVACY ENHANCED MAIL (PEM) is a specification for security services
for electronic mail and, more generally, MIME objects. Its
specification is in RFC 1421-1424.
Kerberos (KRB):
- Kerberos, version 4 (KRB-4) is a widely used security protocol; it
is typically used for mutual client-server authentication in a local
or campus network. KRB-4 is based on DES, and authentications
are performed by a trusted authentication server.
- Kerberos, version 5 (KRB-5) is in beta, and its specifications are
still an Internet draft. KRB-5 enhances 4 in a number of ways, and
is not backward compatible.
Privacy Enhanced Mail (PEM):
- Privacy Enhanced Mail with symmetric keys (PEM-S) allows secure
electronic mail but provides no key management support.
- Privacy Enhanced Mail with asymmetric keys (PEM-A) allows secure
electronic mail via public key, and defines a key certification
structure. PEM-A and PEM-S are compatible in that they share a
specification, and a full implementation of PEM supports both.
All of these mechanism are essentially the same with regard to content
protection (a session key is somehow agreed on) so I won't dwell on
that issue too much (but that doesn't mean it isn't important.)
GENERAL APPROACHES
------------------
KRB is based on a shared secret symmetric key between the user and a
central server. The user may then obtain "tickets" for using specific
services, such as an HTTP server, which the server may validate using
its own secret key which is shared with the central server.
Services sharing the same central server are said to be in the same
"realm"; authentication across different realms not really viable in
KRB-4; KRB-5 does somewhat better, allowing the possibility of a realm
hierarchy.
Kerberos was designed with the intention of allowing mutual
authentication between two entities (normally the user and the server)
on an assumed insecure network; it is reasonably robust with regard to
things like replay attacks. Only the main servers must be secure.
PEM is an extension to Internet mail to allow symmetric and asymmetric
encryption of contents. PEM-S is based on a secret shared key between
the two users (in this case, the user and the server); a different
shared key would be needed for each user/server combination, which
would not scale well. The real point of PEM, though, is its use with
public-key.
PEM-A readily allows peer-to-peer authentication (via certificates)
without the need for central servers (which could become bottlenecks.)
Certificates issued by hierarchically structured certifying
authorities verify key validity, easing key management. It is worth
noting that asymmetric cryptography tends to be much more
CPU-demanding than symmetric. The HTTP servers will be doing a lot of
this, and it could bog them down; typically, servers will be verifying
signatures. Fortunately, the RSA algorithm (unlike the DSA) allows
verifying signatures to be reasonably cheap, helping reduce server
load concerns.
LOCAL AUTHENTICATION
--------------------
Many sites already run KRB-4. For them, it seems plausible that
simply adding HTTP to their existing secure setup would be the easiest
short-term solution.
For sites not already running KRB-4, it cannot easily be added and
would not be likely to be worth bothering with for security on just
one service. KRB-5 faces a similar situation.
PEM-S might be a more suitable solution for small sites who want
something quick and simple with less setup than Kerberos. However,
each user must establish a shared key with the server; this is viable
only if the number of users is reasonably small.
PEM-A is arguably overkill for just local authentication, though it
would work fine.
REMOTE AUTHENTICATION
---------------------
KRB-4 is unsuitable, since cross-realm authentication of n different
administrative domains requires n^2 secret keys.
KRB-5 allows hierarchical structuring of realms, which introduces the
possibility of effective cross-realm authentication for such services.
However, central servers near the top of the hierarchy could become
central points of failure, bottlenecked, or compromised (jeopardizing
the security of the whole net.)
PEM-S is unsuitable, since each user-server pair would require a
separate key.
PEM-A allows peer-to-peer authentication without regard to
administrative domains, and does not require real-time contact with
any central server. This makes it suitable to this application
without the same bottleneck or central-failure problems. Compromise
of certifying authorities is possible, though the PCA structure should
allow clear delineation of how secure these things are. PEM's
relationship with mail also makes it particularly suitable for
non-interactive HTTP through an email gateway, which I believe is also
an important consideration.
COMMERCIAL AUTHENTICATION
-------------------------
Non-repudiation of origin is critical for commercial transactions,
particularly given the desirability of a proliferation of small
publishers. If the publisher says "Joe Smith requested document x at
a price of $1,000" and Joe says "No I didn't" there needs to be a way
to prove who is lying.
Non-repudiation of origin is only possible with asymmetric
cryptography, and thus PEM-A is the only system of those reviewed
which seems viable for this purpose.
Commercial use of PEM-A within the U.S. will require licensing the
right to use the asymmetric crypto algorithms. While this will be an
impediment in the U.S. for the short term, it does not change the fact
that public-key is needed to do secure electronic business.
RECOMMENDATIONS
---------------
An appropriate interoperation standard for Kerberos (certainly KRB-4,
probably also KRB-5) and HTTP should be created. However, by itself,
Kerberos does not seem sufficient to meet the security needs of HTTP
over a large and growing network. Adding Kerberos to a site not
already so equipped is nontrivial; Kerberos needs central servers and
probably could not scale to a system with 100,000 different
administrative realms and 10,000,000 users.
Allowing interoperation of PEM and HTTP should not be inordinately
difficult, since HTTP/1.0 is essentially MIME and the PEM-MIME
interaction is already defined (though still in an Internet draft.) I
have proposed a mechanism for this involving creating MIME types
message/http-request and message/http-response; I'm sure it will need
some refinement but I believe some approach like this can be viable.
Some additional features may need to be defined; for example, PEM has
no explicit mechanism for handling replay attacks, so a timestamp
within the http-request would be desirable.
This extension is just a part of the work that needs to be done in
bringing WWW and MIME closer together; some other things might
include:
- Allowing mail gateways to WWW services to work automatically
(this is a domain where PEM is an obvious big win and KRB is
probably completely impractical)
- Allowing a multipart MIME message with HTML parts that reference
other parts within the message
- Allowing URLs as an access spec for message/external-body (or
making the two different specifications for fetching information
closer in some way)
Kerberos is a good system, and more sites should use it. Sites using
it should be able to use it for HTTP authentication for their users.
However, that paradigm does not seem to effectively scale to the needs
of HTTP in a very large network with the need for authentication
across a large number of users and administrative entities. Of the
systems sufficiently defined to talk about in concrete terms today,
PEM-A seems the only one with the potential to meet those needs.
PEM-S is not terribly useful except as a stopgap solution for non-KRB
sites wishing simple security and not yet wishing to move to PEM-A.
Although PEM-S is sort of awkward (though not really harder to manage
than cleartext passwords, and much more secure) it leaves the door
wide open to PEM-A.
SOME OTHER CONCERNS
-------------------
Cryptography, particularly public-key, is an issue with some amount of
disagreement and political bickering. To answer a few commonly held
misconceptions:
- Public-key is patented in the U.S. buy Public Key Partners; they
hold several patents which they claim collectively cover all known
methods of doing public-key. A reference implementation of the
algorithms needed for doing PEM called RSAREF is available free for
noncommercial use only. Since other WWW software, such as Xmosaic,
already has noncommercial restrictions this doesn't seem like an
insurmountable problem. The rule more or less boils down to "if you
make money, PKP will get a share" until the patents expire (the
patent on RSA expires in late 2000) or are struck down in court
(some think this could happen, but I'm not holding my breath.)
- The U.S. (and some other nations) classifies strong cryptographic
software as munitions and thus there are legal problems with regard
to export. The worse-case scenario regarding this is likely similar
to the current situation with regard to Kerberos; a dumbed-down
no-crypt version of Kerberos is exported, and the crypto software is
engineered and attached abroad.
- Contrary to some claims, there are no license restrictions on PEM to
email only. In particular, the implementation (TIS/PEM) for which
this was a concern may be used for HTTP as long as it's
noncommercial in nature. (I have this on authority from Stephen
Crocker <crocker@tis.com> who wrote the license in question.)
------- =_aaaaaaaaaa0--
-- Marc VanHeyningen mvanheyn@cs.indiana.edu MIME, RIPEM & HTTP spoken here