INTERNET-DRAFT E. Aoki
`<draft-aol-imx-00.txt> A. Wick
` AOL
`Expires: December 15, 2000 June 15, 2000
`
` The IMX Architecture
` Interoperability with America Online’s Instant Messaging Services
`
`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.
`
` This memo provides information for the Internet community.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2000). All Rights Reserved.
`
`Abstract
`
` The ability to exchange instant messages and presence information
` provides users with a powerful mechanism for communicating in
` real-time.
`
` This document outlines an architecture for interoperability among
` Instant Messaging Systems which allows disparate systems to
` exchange messages and presence information while being
` relatively easy to implement and maintaining a high standard of
` security and scalability.
`
`Table of Contents
`
`1. Introduction .........................................
`2. Requirements .........................................
`3. Terminology ..........................................
`4. Architecture .........................................
`4.1 Servers and Gateways ................................
`
`2
`3
`4
`6
`6
`
`Aoki & Wick [Page 1]
`
`Apple 1011
`U.S. Pat. 7,535,890
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
`4.2 Namespace and Addressing ............................
`4.2.1 Address identifiers ...............................
`4.2.2 Domains ..........................................
`4.2.3 Server Discovery ..................................
`4.3 Connection Management ...............................
`4.3.1 Originating Connections ...........................
`4.3.2 Accepting Connections .............................
`4.3.3 Relays ............................................
`4.4 Protocol Considerations .............................
` 4.5 Additional Protocol Considerations for Presence
` Information .........................................
`4.6 Additional Protocol Considerations for Attributes ...
` 4.7 Additional Protocol Considerations for Instant
` Message Information .................................
`5. Instant Message Format Considerations ................
`6. Security Considerations ..............................
`6.1 Objectives ..........................................
`6.2 Assumptions .........................................
`6.2.1 Client Authentication .............................
`6.2.2 Scope .............................................
`6.2.2.1 Types of Attacks Within the Scope ...............
`6.2.2.2 Types of Attacks Outside of Scope ...............
`6.3 A Trust Model for Server to Server communications....
`6.3.1 The Dial-Back Mechanism ...........................
`6.3.2 Enhanced Security .................................
`6.4 SPAM ................................................
`7. Authors’ Addresses ...................................
`8. Additional Documents .................................
`9. Acknowledgements .....................................
`10. References ..........................................
`A. Appendix - Performance Against Objectives ............
`A.1 Scalability and Efficiency ..........................
`A.2 Ease of Implementation ..............................
`A.2.3 Reliability .......................................
`A.2.4 Security ..........................................
`
`7
`7
`7
`7
`8
`8
`8
`9
`9
`
`10
`10
`
`10
`11
`11
`11
`12
`12
`12
`13
`13
`14
`14
`15
`16
`16
`17
`17
`17
`17
`18
`19
`19
`19
`
`1. Introduction
`
` Today’s instant messaging systems are typically comprised of a
` client, through which the end-user interacts, and servers which relay
` information between compatible clients. Tight integration between
` clients and servers allows instant messaging services to provide a
` secure, reliable channel through which authentication, presence, and
` messaging information is passed between users and the service.
`
` As the number of instant messaging providers has grown, there is
` increased interest in enabling IM users to exchange presence and
` messaging information not only with users on their system, but
` with those on other systems as well Some vendors have responded by
` creating "multi-headed clients," clients which can simultaneously
` communicate with servers on disparate instant messaging systems.
`
`Aoki & Wick [Page 2]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` Such clients achieve interoperability at a high price, however.
` Since each service has its own feature set, clients may advertise
` features that do not work across systems. Since each service
` implements its own security model, multi-headed clients must
` often resort to mechanisms that circumvent security or require
` the user to provide passwords to third parties. Inconsistent
` terms of service also make it difficult to enforce anti-spam
` measures or encourage equitable resource sharing. And vendors
` are forced to constantly upgrade clients to keep up with
` changes in features and services across the instant messaging
` universe.
`
` An alternative approach is to provide a mechanism for the services
` themselves to interoperate in a peering arrangement, much like the
` Internet mail system works today. In such a system, the interaction
` between instant messaging clients and their associated servers would
` remain much as it is today, but servers could communicate with other
` servers to exchange presence information, messages, or other data.
` This approach helps to preserve existing models for security
` and allows Instant Messaging Service providers to manage client
` authentication, service policy, and privacy.
`
` This document describes how America Online intends to develop such
` an architecture to allow its services to discover other servers
` (and be discovered by other servers), exchange data, and ensure
` security. It also describes implications that any architecture for
` interoperability may have for the spread of unsolicited instant
` messaging (spam).
`
`2. Requirements
`
` The authors set out to design a system that would be flexible,
` yet practical to implement. In that vein, many of our design goals,
` listed below, are the same as or similar to those specified in
` [RFC 2779], but with additional consideration paid to implementation
` issues.
`
` The primary requirements were to design a system which:
`
` 1) is scalable to hundreds of millions of instant messaging users.
`
` 2) is scalable to hundreds of thousands (or perhaps millions) of
` individual instant messaging systems and domains, so every
` company or ISP could have its own instant messaging system.
`
` 3) allows existing instant messaging implementations to manage
` their own user namespace.
`
` 4) is self managed (like the Internet mail system) such that new
` servers and new systems could be added without administration
`
`Aoki & Wick [Page 3]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` by some central authority and without manual administration
` by other service providers.
`
` 5) initially supports at least five main end-user features:
`
` - Requesting/Renewing/Canceling presence subscriptions
` - Sending/Receiving presence notifications (in response to a
` subscription)
` - Routing and delivery of instant messages
` - Retrieval of named user attributes (at minimum an "alias"
` and current presence state)
` - Retrieval of named domain attributes
`
` 6) allows traffic between users in a single instant messaging
` system to stay within that system.
`
` 7) makes it possible to implement interoperability between
` instant messaging systems by adding gateways to existing
` systems without rearchitecting existing core systems.
`
` 8) is extensible, so new features can be added incrementally
` without requiring redesign and while allowing for backwards
` compatibility.
`
` 9) has a well thought-through security strategy such that:
`
` - Messaging data or state can’t be easily spoofed or replayed
` by a third party
` - Messaging data or state can’t be easily intercepted,
` hijacked, or stolen by a third party
` - More advanced security measures such as end-to-end
` encryption or signing can be layered on top of the initial
` implementation, but are not required in the initial
` implementation.
`
` 10) easily supports clients that are inside of a common company
` firewall (e.g. incoming connections are often refused).
`
` 11) easily supports international usage.
`
` 12) leverages existing standards in as many places as practical.
`
`3. Terminology
`
` [RFC 2778] specifies a common terminology for the discussion of
` Internet Messaging and Presence Protocol information; however, that
` document defines terms which are considerably more granular than
` are required by this document. Accordingly, this document uses
` the following terms:
`
`Aoki & Wick [Page 4]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` Aggregator - A special kind of Gateway, which services multiple
` domains and routes messages between other IMX Servers and
` Servers which service a particular domain. The protocol
` between the Aggregator and each Server is arbitrary. An
` example of an Aggregator might be a Gateway which acts as
` a front-end to multiple, privately-labeled Instant Messaging
` Services.
`
` Attributes - metadata about an End User, such as a nickname or
` alias; or about a domain, such as a timeout value. Attributes
` consist of a key, which is scoped at a domain, and a value.
` It may be desirable to have certain attribute keys which are
` global to the IMX architecture and interpreted identically
` by all participating services.
`
` Data - any of Instant Messages, Attributes, Notifications,
` Subscriptions, or requests for these that are exchanged
` between Servers.
`
` End User - a human or other entity whose presence information is
` reflected by the service and who can send and receive Instant
` Messages through an Instant Messaging Service.
`
` Instant Message - a short, real-time or near-real-time message
` which is sent between Instant Messaging clients. While this
` document does not prescribe a definition for "short," the
` intent is to prevent streams of arbitrary length from
` being sent as Instant Messages. This is consistent with the
` definition of an INSTANT MESSAGE in [RFC 2778].
`
` Instant Messaging Client (or Client) - a User Agent which provides
` an End User with the ability to initiate and receive Instant
` Messages, and request Subscriptions and receive Notifications for
` Presence Information. This term is used in this document to
` encompass a SENDER, INSTANT INBOX, PRESENTITY, and WATCHER in
` [RFC 2778], and is roughly consistent with the generic description
` of an "instant messenger" in section 2.7 of that document.
`
` Instant Messaging Gateway (or Gateway) - a special type of
` Instant Messaging Server which does not communicate directly
` with Clients but sits between Servers which service a particular
` domain and the world of other IMX servers. Gateways act
` essentially as routers, potentially performing protocol
` translation between an Instant Messaging Service’s local
` protocols and the IMX protocol. An example of a
` Gateway would be a Server which routes messages to an
` already existing, private Instant Messaging Service.
`
` Instant Messaging Server (or Server) - an entity which
` maintains Presence Subscriptions for and delivers Instant
`
`Aoki & Wick [Page 5]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` Messages on behalf of End Users of a given Instant Messaging
` Service. Typically, Instant Messaging Clients connect
` to a Server in order to send and receive Instant Messages,
` Attributes, and Presence Information.
`
` Instant Messaging Service - a collection of Instant Messaging
` Servers and their associated clients which together make up
` an integrated service offering. Instant Messaging Services
` administer their own namespace of End User names and are
` generally associated with one or more domains they serve.
`
` Notification - a message sent from a Server to a Client to
` indicate a change in the Presence Information for a given
` End User. Notifications are sent only to Clients who
` have previously created a Subscription to receive such
` information for a particular End User. (Presence Information
` may be retrieved in real-time without a Subscription by
` making a request for a presence Attribute). This term
` is essentially identical to the corresponding definition
` in [RFC 2778].
`
` Presence Information - information regarding the state of a
` particular user. Examples might be online, offline, away,
` busy, etc. Specific formats for the conveyance of Presence
` Information are not specified here.
`
` SPAM - unwanted (and typically unsolicited) Instant Messages.
`
` Subscription - Information kept by an Instant Messaging Server
` which maintains a Client’s desire to be Notified when an
` End User’s Presence Information changes. Subscriptions are
` entered by Instant Messaging Clients on behalf of End Users,
` and time out if not renewed. This term is essentially
` identical to the corresponding definition in [RFC 2778].
`
`4. Architecture
`
` The basic architecture behind IMX (Instant Messaging eXchange) is one
` of multiple independent Instant Messaging Services (as exist today),
` which can interoperate at the Server-to-Server, Server-to-Gateway, or
` Gateway-to-Gateway level.
`
`4.1 Servers and Gateways
`
` Each Instant Messaging Service exchanges Data with other Services
` through well known Servers or Gateways. For the purpose of this
` document, Servers and Gateways are distinguished in that Servers
` can be the same physical or logical entities that service Clients,
` whereas Gateways essentially relay information between Servers
` within a Service and those outside of it. Absent this distinction,
` the terms Server and Gateway can be used interchangeably.
`
`Aoki & Wick [Page 6]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` Each Server is said to "service", "be responsible for", "act on
` behalf of," or be "in" a domain, which is a shortcut to saying that
` a Server listens for requests intended for a given Instant Messaging
` Service (identified by a domain), and provides answers on behalf
` of the End Users who belong to that Service. In this way, the model
` is very similar to the way that SMTP servers exchange mail with other
` SMTP servers.
`
`4.2 Namespace and Addressing
`
`4.2.1 Address identifiers
`
` Each End User has an identifier which can be used to uniquely
` address that user across various Instant Messaging Systems.
` Like internet mail addresses, the identifier used to identify a
` given End User consists of a local part and a domain, separated by
` at-sign (@). (The at-sign is therefore a reserved character
` in an Instant Messaging address).
`
` The address used for Instant Messages may or may not be the same as
` an End User’s email address.
`
`4.2.2 Domains
`
` The domain portion of the address is assumed to be an internet
` domain, compliant with [RFC 1034] and is used to identify the
` Servers responsible for that domain by the process described in
`Section 4.2.3.
`
`4.2.3 Server Discovery
`
` Servers which service a particular domain are published in DNS using
` an IMX record. An IMX record is a new type of DNS record that works
` similar to the MX record used by mail. It lists one or more Servers
` that accept Instant Messaging connections for that particular domain.
` If more than one server is listed, the originating Server picks one
` of the listed servers randomly (just like with MX records) and
` attempts to establish a connection. If the chosen server doesn’t
` respond, the originating server may attempt to connect on one of the
` other listed servers.
`
` The IMX record may also list other attributes of the connection such
` as a port number.
`
` A full specification of IMX records will follow in a separate
` document.
`
`Aoki & Wick [Page 7]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
`4.3 Connection Management
`
` Connections between Servers use TCP for transport. They are
` established on-demand by the originating Server as needed and are
` semi-persistent. Connections are kept open for as long as the
` originating host desires, as long as there is activity on the
` connection. Connections may be closed by the receiving Server after
` some period of inactivity; they would then be re-established by the
` originator on-demand when next needed.
`
` Data for multiple End Users can and likely will flow across a given
` connection. Conversely, Data for a given user may flow over any
` active connection that exists between the two domains and is not
` guaranteed to flow over the same connection as previous requests.
` If a Server handles requests for more than one domain, Data for
` multiple domains may flow over a given connection. These connections
` must be authenticated multiple times, once for each domain they
` serve.
`
`4.3.1 Originating Connections
`
` A Server would establish a connection to another Server in order to
` request Data on behalf of an End User within the originating server’s
` domain. This would include connections to send Instant Messages,
` initiate or refresh Subscriptions, send Notifications, and to
` request Attributes.
`
` A Server may establish more than one connection to communicate with
` another Server (i.e. for load balancing or to handle increased
` traffic); however, in consideration of scalability, implementers
` should take care to limit the number of such connections to a
` reasonably small number. For example, it would not be appropriate
` for a Server to establish one connection per End User; it would be
` appropriate to establish one connection per Server process or Server
` thread. In any event, a receiving server may refuse to accept
` more than a given number of connections from Servers at a single
` domain.
`
` Servers will also establish connections in order to perform
` authentication handshaking as specified in Section 6.3.1.
`
`4.3.2 Accepting Connections
`
` A Server would accept a connection from another Server in order to
` receive Data for an End User within the receiving server’s domain.
` This would include connections to receive Instant Messages, update
` or establish Subscriptions, receive Notifications, and receive
` requests for Attributes.
`
` Servers will also accept connections in order to perform
` authentication handshaking as specified in Section 6.3.1.
`
`Aoki & Wick [Page 8]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
`4.3.3 Relays
`
` Server should only accept traffic for the domains they service.
` That is, this architecture explicitly disallows relaying services
` because of their possible unauthorized and unintended use (see
` SPAM, section 6.4).
`
` Instant Messaging Services will be held accountable for traffic
` originating from their Servers.
`
`4.4 Protocol Considerations
`
` This document does not specify the details of the protocol between
` Servers (the IMX protocol). However, we believe that the following
` requirements should be considered in the implementation of the
` protocol:
`
` 1) The protocol must have the ability to exchange protocol version
` information and some protocol capability information. (4.4.1)
`
` 2) The protocol must be completely extensible without ever having to
` force all other servers to upgrade. The intention is that, in
` most cases, new types of data packets or request packets can be
` added, and older servers can simply ignore the data or request
` types that they don’t understand. (4.4.2)
`
` 3) The protocol should include a means for either side to close the
` connection in an orderly fashion and have the other side know that
` the connection has been closed. (4.4.3)
`
` 4) The protocol should include some sort of redirection mechanism so
` that the other end of an existing connection can be told to
` reconnect on another IP address. (4.4.4)
`
` This would be useful for:
`
` - Taking an existing, active server out of service in an orderly
` fashion
` - Smarter load balancing beyond the capabilities of a DNS rotor.
`
` 5) The protocol needs the ability to retrieve named user
` Attributes (e.g. the user’s alias, UA capabilities, maximum
` message length, etc...).
` (4.4.5)
`
` 6) The protocol also needs the ability to retrieve named
` domain-specific Attributes. For example, the timeout for a
` connection or a presence subscription to expire may be a
` domain-specific configuration. (4.4.6)
`
`Aoki & Wick [Page 9]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` 7) The protocol is completely asynchronous. The connection is simply
` a pipe through which requests and tagged responses flow. More
` than one connection may be open between a set of servers, and more
` than one request may be in process on a given connection. In
` some cases, a response may not flow back on the same connection on
` which it was initiated. (4.4.7)
`
` 8) The protocol should allow for responses to at least some requests
` (particularly those requesting Attributes), to return on the
` same connection as the request. The protocol should additionally
` provide enough information in the request so that a reply can be
` routed to the same Server that made the request. (4.4.8)
`
` 9) The protocol should be binary, not text. The binary format will
` be records with length and type. (4.4.9)
`
` 10) Where not already specified by a chosen, existing standard, data
` will be represented in UTF-8. (4.4.10)
`
`4.5 Additional Protocol Considerations for Presence Information
`
` When used for Subscription or Presence Information, the following
` additional requirements should be considered:
`
` 1) Presence Subscription should expire in some pre-determined amount
` of time (e.g. 30 minutes) if they aren’t renewed. This timeout
` may be different per vendor and should be published as a
` domain attribute. (4.5.1)
`
` 2) Presence Notifications may be delivered over any active connection
` that exists between the two domains. They are not necessarily
` delivered over the same connection on which the subscription was
` requested (that connection may not even exist anymore). (4.5.2)
`
`4.6 Additional Protocol Considerations for Attributes
`
` When used to retrieve Attributes for a user or domain, the following
` additional requirements should be considered:
`
` 1) Attribute information may be sent unsolicited with Instant
` Message or Presence Information so that it need not be
` explicitly requested. (4.6.1)
`
`4.7 Additional Protocol Considerations for Instant Message Information
`
` When used for Instant Messages, the following additional requirements
` should be considered:
`
` 1) As with the SMTP envelope, the To and From address flows with the
` message as part of the protocol and does not need to be parsed by
` Servers, Gateways, or Aggregators. (4.7.1)
`
`Aoki & Wick [Page 10]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
`5. Instant Message Format Considerations
`
` In order to achieve maximum flexibility, a subset of MIME [RFC 2045]
` should be used for the message transfer format. Messages will consist
` of headers and a body.
`
` 1) The message From and To headers are also included in the MIME
` message and are required. All other headers are optional. Any
` number of headers may exist. Headers such as "Content-type" and
` "Content-transfer-encoding" are used if present. "Subject" is not
` used. Vendors that specify additional vendor-specific headers
` are strongly encouraged to use the "X-" header format.
`
` 2) Initial implementations of the architecture should support at
` least two MIME types: text/plain and text/html-lite.
`
` Text/html-lite is a strict subset of HTML with support for only
` a few basic formatting tags supported (such as <B>...</B>,
` <I>...</I>, etc...).
`
` No additional attempt is made to describe text/html-lite in this
` document.
`
` 3) Very long lines are permitted. Text/plain messages are not
` prewrapped to any particular column width. A paragraph is sent
` as one long line. It is the receiving Client’s responsibility
` to wrap the message for proper display. It is important that all
` servers support this correctly because Instant Messaging user
` interfaces are often used in a small screen form factor where
` appropriate wrapping substantially increases the usability.
` The small screen requirement comes about either because the
` Client runs on a small screen device or because the user wishes
` to devote only a small piece of screen real estate to the Client
` user interface.
`
`6. Security Considerations
`
`6.1 Objectives
`
` [RFC 2779] specifies in detail a series of requirements for security
` in an Instant Messaging protocol. In developing this architecture,
` the authors also considered the following objectives in order to
` ensure practicality of implementation:
`
` 1) The architecture should be straightforward to implement and
` administer and be freely exportable.
`
` 2) The system, including the relationship between arbitrary
` Instant Messaging Services, should be self-managed, with no
` centralized authority required to administer the security scheme.
`
`Aoki & Wick [Page 11]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` 3) The security scheme should account for a basic level of
` security but be easily extensible so that some Services may
` implement a higher degree of security.
`
` 4) In order to address these objectives (1-3), the intent is
` to authenticate connections between Servers, not individual
` exchanges of Data.
`
` 5) In keeping with the objectives of (3), it should be possible,
` but not required, to support end-to-end encryption and/or
` signing. (End-to-end encryption refers to data encrypted
` by the sending Client and decrypted at the recipient’s Client).
`
` 6) In keeping with the objectives of (3), it should be possible,
` but not required, to support the use of advanced security
` measures such as SSL or certificate exchange between Servers.
`
` 7) User passwords should never be exchanged in a Server to
` Server communication.
`
` The overarching intent behind these objectives is to provide a
` system which would offer substantially higher security than
` Internet email, yet offer a basic level of security that could
` be easily and rapidly implemented. At the same time, the model
` would be extensible enough to allow for increased security should
` users, vendors, or other entities demand it.
`
`6.2 Assumptions
`
`6.2.1 Client Authentication
`
` Because this architecture specifies a Server to Server protocol, it
` does not specify or recommend any mechanism for authenticating
` Clients to a Server. Each Instant Messaging Service is held
` responsible for security between Clients and Servers, including
` preventing one End User from impersonating another.
`
` In all discussions in this section, this document assumes that a
` given Server can be trusted when it represents that Data originates
` from a given End User.
`
`6.2.2 Scope
`
` Each individual Instant Messaging Service is responsible for making
` sure that a given End User is not an impersonator. Therefore, the
` principal problem this document tries to solve is to ensure that
` Data sent and received on behalf of an End User in a given domain
` is actually originating from and/or being sent to Servers in that
` domain.
`
`Aoki & Wick [Page 12]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
` Additionally, the architecture seeks to protect against a spoofing
` attack where one Server pretends to issue Data on behalf of users
` in a domain that it does not represent.
`
`6.2.2.1 Types of Attacks Within the Scope
`
` The following types of attacks are explicitly covered by
` the proposed architecture.
`
` 1) Breach of Presence Privacy - Spoofing an End User who is
` requesting Presence Information (or Attributes). This form
` of security becomes especially important if a service supports
` restrictions on who can and can not retrieve Presence Information
` (or Attributes) for a given End User. This is essentially the
` requirement 5.1.1 in [RFC 2779], where A and B are SERVERS
` instead of non-ADMINISTRATOR PRINCIPALs.
`
` 2) False Presence - Spoofing state about a given End User (e.g.
` if User A in a given domain is subscribed to receive Presence
`
` Information for User B in another domain, it is not possible
` for a User C to send Notifications with User B’s Presence
` Information to User A). This is essentially the requirement
` 5.2.4 in [RFC 2779], where users A and B are authenticated
` ENTITIES in separate DOMAINS.
`
` 3) Spoofing Sender - Spoofing the From address for a given Instant
` Message (e.g. User C in a given domain sends an Instant Message
` to User B purporting to be User A). This is essentially the
` requirement 5.4.3 in [RFC 2779], where A and B are authenticated
` ENTITIES in separate DOMAINS.
`
` 4) Stealing Data - Hijacking Data intended for a given End User and
` redirecting it somewhere else. (e.g. User A sends an Instant
` Message to User B, but it instead is directed to User C). This
` is essentially requirements 5.3.3 and 5.4.6 in [RFC 2779], where
` A and B are authenticated ENTITIES in separate DOMAINS.
`
`6.2.2.2 Types of Attacks Outside of Scope
`
` For practical reasons (see Objectives, 6.1), a "standard"
` implementation of security as defined in this document does not
` protect against the following types of attacks:
`
` - DNS Hijacking
` - Man-in-the-middle attacks
` - Eavesdropping or packet snooping
`
` However, an advanced implementation of security may protect against
` these within the specified architecture (see section 6.3.2).
`
`Aoki & Wick [Page 13]
`
`

`
`INTERNET-DRAFT IMX Architecture June 15, 2000
`
`6.3 A Trust Model for Server to Server communications
`
` This document therefore proposes the following architecture for
` establishing trust between Servers:
`
` 1) Servers will trust DNS for all outgoing connections. If a Server
` establishes a connection from Domain A to Domain B, it should be
` relatively certain that data sent over that connection is actually
` going to Domain B. The only situations where that assumption
` would not be true would be if the entirety of Domain B were
` hijacked, and that is explicitly not covered by this model (see
` 6.2.2.2).
`
` 2) Incoming connections to a Server are not trusted (since they could
` originate anywhere). Incoming connections are authenticated by
` using a mechanism referred to as "dial-back