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

. 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.

. 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.

. 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.

. 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.

. 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.

. 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.

. 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.

. Conclusions

Security in the IMPP area is a difficult problem, and none of the
solutions presented above is very satisfactory, at least by itself.

. 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."

. Author's address

Greg Hudson
Massachusetts Institute of Technology
Cambridge, MA 02139
ghudson@mit.edu