INTERNET-DRAFT Greg Hudson
Expires: November 21, 2000 ghudson@mit.edu
MIT
Security in the Instant Message and Presence Protocols
draft-hudson-impp-security-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
This document describes the security issues and options associated
with instant messaging and transmission of presence as they are being
considered in the IMPP working group.
This document uses many terms described in [RFC 2778], which describes
a model for instant messaging.
3. IMPP architecture and payload characterization
The architecture favored by the IMPP working group involves two
different kinds of network elements, clients and servers. Clients
represent IMPP entities (senders, instant inboxes, presentities, or
watcher), and only speak to the server of their home domain. Servers
communicate with each other in order to carry out presence operations.
A server may choose to communicate with entities other than IMPP
clients; in this case, the server is called a gateway. For instance,
MIT might set up a server which appears to be an IMPP server to other
servers, but which communicates with Zephyr clients instead of
standard IMPP clients.
A server may choose to communicate with "clients" only on the local
host, without using the standard protocol, or with only one "client"
built into the server program.
Servers for a domain are located using a SRV [RFC 2782] lookup in the
DNS, similar to how email servers for a domain are located using an MX
lookup. Also as with email, there is a fallback to an A record lookup
if no SRV record exists.
Compared to email, IMPP traffic is expected to be characterized by
larger numbers of smaller messages. Currently, a heavy email user
subscribed to many email lists might receive a few hundred messages in
a day, while a user of many instant messaging "chat rooms" or IRC
channels might receive a few hundred messages in an hour or less.
The forms of the IMPP transfer protocols are not finalized. This
document will be written assuming that the transfer protocols between
clients and servers and between servers and servers use long-lived TCP
connections.
4. Goals
The security goals of the IMPP system are presented in [RFC 2779].
They can be summarized as follows:
* Secrecy: Eavesdroppers should not be able to read message
content. Ideally, they should not be able to do traffic
analysis either, beyond watching where the actual IP packets
go.
* Authentication and integrity: It should be difficult to
forge IMPP operations or modify them in transit.
5. General methods
Security goals can be achieved in one of two general ways:
1. Data can be authenticated or encrypted at the level of the
transfer protocol or, equivalently, at the level of the
underlying transport protocol (e.g. using TLS or IPsec).
This method requires the communicating parties to trust the
intermediary servers to do their job properly.
2. Data can be authenticated and/or encrypted from the sender
to the receiver, even though they do not enjoy a direct
connection. This method does not require the communicating
parties to trust any intermediaries, but does require them
to agree on a security mechanism and key management
structure.
Of course, these two methods can be layered together for added
protection. And it is possible to mix the two methods; for instance,
presence information might be authenticated from a presence service to
a watcher, which would require the presentity's server to be trusted
but not the watcher's.
6. Secrecy
Preventing passive eavesdroppers from reading traffic, including
headers, is relatively easy. At the beginning of each transfer
connection, the two parties can conduct an anonymous Diffie-Hellman
key exchange and encrypt the transfer stream using a symmetric
algorithm. This scheme requires no infrastructure and would prevent
passive eavesdroppers from reading traffic, but a man-in-the-middle
attacker can defeat this scheme while remaining invisible to the two
parties. Also, there is currently no standardized protocol method
that I know of for doing anonymous Diffie-Hellman key exchange,
selecting symmetric encryption algorithms, and deriving keys.
Secrecy of IM and presence payloads can also be achieved in an
end-to-end manner if the sender can obtain the a public key for the
receiver or can somehow negotiate a shared secret with the receiver.
This category of method requires infrastructure, of course, and does
not prevent attackers from doing traffic analysis.
7. Authentication
Authentication is a fundamentally more difficult problem than secrecy.
Authentication between two unfamiliar parties cannot be achieved
without some kind of infrastructure, and authentication
infrastructures are inherently limited in strength. In considering
the options below, note that each option proves something slightly
different about the sender.
7.1. Transfer-level or transport-level authentication
Authentication at the transfer protocol or transport protocol level
has some attractive properties:
* Assuming the transfer protocol uses long-lived TCP
connections, security associations can be set up at the
beginning of a connection and efficient symmetric protocols
can be used to encrypt and integrity-protect traffic.
* Proper authentication at the transfer level can allow
improved secrecy, preventing even man-in-the-middle
attackers from eavesdropping or performing traffic analysis.
* Domains can reuse their existing security infrastructure to
authenticate clients.
Between a client and its home server, authentication is essentially a
solved problem. Either SASL [RFC 2222] or SPNEG0 [RFC 2478] allow
clients to use a variety of methods of varying strengths to
authenticate to a server and to protect traffic. Server operators can
decide what sorts of authentication they will allow from clients.
Between servers for two domains, however, the problem is harder.
Although SASL or SPNEG0 can be used between domains, most of the
existing mechanisms within those frameworks are not as useful between
domains, and the problem of configuring a minimum security level
between domains is essentially unsolvable without help from the
protocol specification.
Following are descriptions of two possible options for transfer-level
authentication between domains. Neither is particularly optimal.
7.1.1. Using DNS KEY records for inter-domain authentication
If we wish to authenticate that a server is properly representing the
DNS domain it claims to be representing, then it would make some
amount of sense to use the DNS as the authority for keys. The secure
DNS specification [RFC 2065] envisions that DNS might be used to store
public keys for application protocols. Ideally these keys would be
signed to protect against DNS spoofing attacks. Public keys in the
DNS could be used in a variety of ways for authenticating domains; one
option would be authenticated Diffie-Hellman key agreement as
described in [RFC 2631].
This scheme has some nice properties:
* Because servers look up each others' key records in the DNS,
and because DNS records usually expire after a relatively
short time period, there is no certificate revocation
problem, and key roll-over is possible by including multiple
keys in the RRset.
* Because servers look up each others' key records in the DNS,
this mechanism can be made optional without allowing an
attacker to spoof a domain by claiming that the domain does
not support security. If a domain has a public key for IMPP
in the DNS, then it would not be allowed to authenticate to
another secure domain without the private key.
* Even in the absence of signed key records, an attacker would
have to perform a DNS spoofing attack to forge a request.
This would be considerably better than email, where forging
email is as trivial as lying about the from address.
* Because the same authority is used for keys as for server
lookup, there is no concern that a certification authority
separate from the relevant DNS authorities might be issuing
certificates to parties other than the authorized domain
administrators.
However, there are some important disadvantages to this scheme:
* Secure DNS is essentially vapor at the current time. Some
implementations exist, but we have essentially no
operational experience with it.
* Upon receiving a connection and an authentication request, a
server would have to go out and perform a DNS query to get
the public key for the domain the connection initiator
claims to be. This may not be a real problem, since server
implementations already have to perform DNS queries to
initiate connections to other domains.
* There is no standard mechanism for authenticating domains
using public keys stored in the DNS; a new one would have to
be invented.
7.1.2. Using TLS and X.509 certificates for inter-domain authentication
TLS [RFC 2246] describes a transport-layer security protocol using
X.509 certificates. This approach is currently in wide use for
securely authenticating World Wide Web sites to web users and for
protecting traffic (especially for passwords and/or credit card
information used in web commerce). TLS could be used for mutual
authentication between domains, since it allows for certificates to be
passed in both directions.
The advantages of this scheme are obvious: it is an existing standard
with significant deployment experience (although most of it with
certificates only going in one direction) with existing publicly
available implementations. However, it poses the following problems:
* Certificates typically expire after a long period of time,
much longer than a typical DNS expiry time. If a private
key is compromised, TLS provides no mechanism for revoking
the corresponding certificate.
* Domains would provide each other with the entire certificate
chain leading up to the CA as part of the transfer
connection; servers do not and cannot look up certificates
in any outside directory. This is potentially convenient
for the server implementors, but means there is no way to
look up whether a domain supports security or not. So if
the TLS mechanism is optional, a domain has no way of
knowing whether to trust another party's assertion that they
represent a domain which does not employ the mechanism.
* Although TLS allows the receiving party to specify to the
initiating party which certification authorities it
respects, it does not allow the initiating party to
specify that information to the receiving party. So a
server with certificate chains leading to two different CAs
does not know which certificate chain to present upon
receiving a connection from another server.
* A certificate chain leads to a certification authority which
may not be the same as the authority which controls the root
DNS zone. The risk exists that a certification authority
might hand out certificates to parties other than authorized
domain owners.
7.2. End to end authentication
End to end authentication has some nice properties relative to
transfer-level or transport-level authentication:
* The parties involved do not have to trust the servers
between them.
* You can use end to end authentication to authenticate facts
other than authorized use of a particular IMPP identifier.
Two familiar parties can use manually exchanged keys to
authenticate their actual identities. Similarly, two
previous unfamiliar parties can exchange keys and use
them to authenticate the fact that they are the same two
parties conversing over a long period of time, even if
neither of them is certain of who the other one is.
* Servers don't have to do any work to support end to end
authentication between users; the computational work is
pushed out to the edges. This is good for traditional
Internet deployments involving powerful client machines,
although it poses problems for battery-operated wireless
clients.
Unlike transfer-level or transport-level authentication, end to end
authentication cannot be leveraged to protect against traffic analysis
(although it can be leveraged to protect against eavesdropping of IM
and presence payloads), and it does not allow administrative domains
to reuse their existing key security infrastructure if it does not
happen to gel with the end to end security mechanism in use. Finally,
end-to-end authentication does not apply (or at least applies
differently) to requests between users and servers, such as for a
presentity's request to change its presence information.
7.2.1. End to end authentication using existing MIME-based mechanisms
PGP/MIME [RFC 2015] and S/MIME [RFC 2633] are existing methods for
authenticating MIME payloads. They are designed for mail, a
non-interactive medium characterized by larger, less frequent
payloads, and may not perform adequately for large, smaller payloads.
The bandwidth overhead imposed by PGP or S/MIME signatures may be
unacceptable for one-line messages, and the computation overhead of
doing a public key operation for each instant message may be
unacceptable for battery-powered devices. However, they are existing
standards with available implementations.
7.2.2. End to end authentication using new mechanisms
A new, more interactive MIME-based mechanism could be designed in
order to reduce the bandwidth and computation overheads of PGP/MIME
and S/MIME. For instance, two parties communicating secretly over
many messages could establish a shared secret in the first message,
and then use efficient symmetric algorithms to protect the remaining
messages.
A mechanism along these lines could help enormously for users
participating in IM redistribution lists or "chat rooms," but only if
the redistribution list is considered an "end" and is trusted to
properly represent the identities of users who send through it. In
the absence of such trust, it is difficult to do better than one
public key operation per message for a redistribution list scenario.
8. Conclusions
Security in the IMPP area is a difficult problem, and none of the
solutions presented above is very satisfactory, at least by itself.
10. References
[RFC 2015]
M. Elkins. "MIME Security with Pretty Good Privacy (PGP)". RFC 2015,
October 1996.
[RFC 2065]
D. Eastlake, 3rd, C. Kaufman. "Domain Name System Security
Extensions." RFC 2065, January 1997.
[RFC 2222]
J. Myers. "Simple Authentication and Security Layer (SASL)." RFC
2222, October 1997.
[RFC 2246]
T. Dierks, C. Allen. "The TLS Protocol Version 1.0." RFC 2246,
January 1999.
[RFC 2478]
E. Baize, D. Pinkas. "The Simple and Protected GSS-API Negotiation
Mechanism." RFC 2478, December 1998.
[RFC 2631]
E. Rescorla. "Diffie-Hellman Key Agreement Method. E. Rescorla." RFC
2631, June 1999.
[RFC 2633]
B. Ramsdell, Ed.. "S/MIME Version 3 Message Specification." RFC
2633, June 1999.
[RFC 2778]
M. Day, J. Rosenberg, H.Sugano. "A model for Presence and Instant
Messaging." RFC 2778, February 2000.
[RFC 2779]
M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Messaging /
Presence Protocol Requirements."
11. Author's address
Greg Hudson
Massachusetts Institute of Technology
Cambridge, MA 02139
ghudson@mit.edu