CIDF Working Group Clifford Kahn, The Open Group DRAFT Specification Don Bolinger, The Open Group 8 June 1998 Dan Schnackenberg, Boeing Corp. Communication in the Common Intrusion Detection Framework v 0.7 1. Introduction When complete, this document will specify how components in the Common Intrusion Detection Framework communicate over the wire. This specification is about interoperation, mainly, and not about reuse of code. In more detail, this document will specify the following: * How components in the Common Intrusion Detection Framework (CIDF) can securely contact the proper other CIDF components; this includes: - Locating the proper components - Verifying each partner's authenticity and authority * How CIDF components, having made contact and verified each others' authenticity and authority, can communicate securely and efficiently This document is not self-contained, but depends on other documents in a series defining the Common Intrusion Detection Framework (CIDF). The other documents include: * An architectural framework that describes the environment in which intrusion detection and response components interact. All CIDF components must comply with this. READ THE FRAMEWORK DOCUMENT FIRST. * The Common Intrusion Specification Language specification, which defines the notation in which CIDF components communicate about intrusions and responses. To comply with CIDF interoperability standards, components must comply with the CISL specification and the present specification. * An API specification, which permits reuse of CIDF components. The present specification alludes to APIs, but the API spec will (eventually) spell them out. Kahn, Bolinger, Schnackenberg [Page 1] DRAFT Communication in CIDF 8 June 1998 2. The Matchmaking Service The CIDF Matchmaking Service, or matchmaker, provides a standard, unified mechanism for CIDF components to make themselves known to other components, and for components to locate communication "partners" with which they can share information. The use of a single infrastructure for this purpose should greatly promote component interoperation and ease development of multi-component intrusion detection and response systems. This section provides both background information about the matchmaker and a specification of how components establish communications with one another using the matchmaker. In particular, the section provides: * A functional description of the matchmaker. * An overview of the matchmaker architecture. * An explanation of abstractions used in describing the matchmaker that extend or augment normal CIDF abstractions. * A summary of the components of the matchmaker architecture. * A description of the format of the data communicated between components during matchmaking. * A description of the protocol for non-feature-based component lookup. * A description of the protocol for feature-based component lookup. 2.1 Functional Description The matchmaker is meant to support different levels of directory service, according to what a given component requests. The matchmaker will provide clear advantages to its clients in ease and flexibility of configuration, and the matchmaker MUST be used to provide any of the forms of lookup described in this document. Using the matchmaker, clients MAY establish communications with one another based either on *feature-based lookup* or on conventional lookup using component identity information. The use of feature-based lookup is optional, so that components that do not want to use it (e.g., due to resource constraints) are not obliged to do so. 2.1.1 Assumptions Our thinking about what the matchmaker must do is based on some fundamental assumptions about ID&R systems and the hosts and networks on Kahn, Bolinger, Schnackenberg [Page 2] DRAFT Communication in CIDF 8 June 1998 which they run: * Components are dynamic: they come on-line and go off-line frequently. They need to change communication partners frequently. * Networks get reconfigured: not as often as components do, but frequently enough that one does not want to adjust endpoint information manually. * Categories of related targets are important: - Matter for both analysis and response. - Contents are dynamic. - Hierarchy is dynamic. - Categories have multiple consumers. - Categories overlap. - Categories nest. Note that the assumption about categories is more debatable than the other two: Our analysis of ID & R systems and how CIDF can ease their use strongly suggests that it's true, but its truth has not been demonstrated. 2.1.2 Functional Goals Given the assumptions above, we believe that the matchmaker should pursue the following high-level functional goals: * Matchmaking: MUST allow the lookup of communications partners either based on some feature of the communication desired (i.e., gido classes), or based on explicit addressing. * Scalability: the matchmaker MUST scale easily to at least the level of a large corporation. At least a few projects would like it to allow inter-organizational use. * Ease of administration: The matchmaker SHOULD permit CIDF components to be configured easily and their features and addresses to be to be recorded and updated easily. Also, setting up the matchmaking infrastructure itself SHOULD be easy. * Security: the matchmaker MUST allow authenticated communications at the option of each component, and allow firewalls to force the use Kahn, Bolinger, Schnackenberg [Page 3] DRAFT Communication in CIDF 8 June 1998 of authentication. MUST enable intruders to be kept out, and limit component powers so as to reduce damage if intruders do get in. * Availability: short of positing high-availability infrastructure (which does not exist), the matchmaker approach SHOULD minimize single points of failure, as by using directory replication, and by permitting component-local caching. * Survivability: even if an adversary takes directory servers out of service, matchmaking SHOULD still work somewhat, and even if an adversary compromises directory servers, s/he MUST NOT be able to spoof authentication or authorization between CIDF components. * Performance: matchmaking SHOULD be reasonably fast, even when there are many components. 2.1.3 Functional Objectives Given a set of goals like those above, we find it extremely helpful to reduce them to measurable objectives. These are the objectives we have come up with. * Component addition to or deletion from a category SHOULD be one step (from the administrator's perspective). * Changes to the category hierarchy SHOULD involve just one step for the administrator. * Updating a component IP address for CIDF SHOULD involve just one step. * Components not authorized to belong to a category MUST NOT be allowed to claim to be members. If a component wishes to communicate with another component, mentioned by name, the latter component's identity MUST be authenticable. * Components not properly authorized MUST NOT be allowed to access a category, or a component, if direct lookup of components is in use. * Setup costs for a CIDF host SHOULD NOT exceed the following: - Manual establishment of a private and public key for the host -- ideally this will be the same private key used for other purposes, though that is not required. But it SHOULD be only one CIDF key per host, even if the host hosts multiple components. Kahn, Bolinger, Schnackenberg [Page 4] DRAFT Communication in CIDF 8 June 1998 - Granting appropriate authority to the host according to the site's policy. - Adding components resident on the host to appropriate categories. 2.2 Architectural Overview A central piece of the matchmaker architecture is the matchmaking broker, which provides lookup services to some set of CIDF components. These components are referred to as the broker's clients. In the normal case, a broker maps 1-to-1 with a client, and is in fact linked into the client executable. However, the matchmaker architecture also allows for a broker to be separate from the client it serves, either as a separate process on the same host, or as a process on another host entirely. In these cases, a single broker may serve more than one client. The other components of the matchmaker always reside in the client image. The first of these is an authentication and authorization module. The second is a communications module, which has a null implementation in the case where the broker is collocated with a single client. The third is a persistent cache for information recently looked up in the directory. This architecture supports the two configurations shown below. In both of these figures, labels in all upper case indicate distinct components of the matchmaker architecture. Labels in all lower case indicate interfaces within a component. Figure 1 depicts a client having a local broker, i.e., one resident in the client image. Lookup requests from the matchmaker API invoke the communications module, which in turn directly calls the broker. Kahn, Bolinger, Schnackenberg [Page 5] DRAFT Communication in CIDF 8 June 1998 +-----------------+ | AUTH'N + AUTH'Z | | MODULE | +-----------------+ ^ \ associate contact \ +---------------------+ +---------------------+ | . B . | initial | . | | ldap . R . null | lookup | match- . CLIENT | | client . O . comms | <-------------- | maker . (CIDF | | api . K . module | | api . COMPONENT) | | . E . | | . | | . R . | +---------------------+ +---------------------+ / \ / lookup target updates \ / failover v v +--------------+ | CLIENT-SIDE | | CACHE | +--------------+ Figure 1. Matchmaker Client with Local Broker Figure 2 shows what happens when client and broker are on different hosts. Here, lookup requests pass through the authentication/authorization module, which then invokes the communications module. In this case, the communications module contacts the broker over the network. Kahn, Bolinger, Schnackenberg [Page 6] DRAFT Communication in CIDF 8 June 1998 .................. ................................................ : : : associate : : : : +--------+ contact +---------------------+ : : : : | AUTH'N | <-------- | . | : : : : | + | | match- . CLIENT | : : : : | AUTH'Z | initial | maker . (CIDF | : : : : | MODULE | lookup | api . COMPONENT) | : : : : +--------+ <-------- | . | : : : : | +---------------------+ : : : : | authenticated | : : +------------+ : : | initial lookup | : : | . B | : : v | : : | ldap . R | : : +--------+ | : : | client . O | : : | | | : : | api . K | <=====> | COMMS | | : : | . E | : : | MODULE | | : : | . R | : : | | | : : +------------+ : : +--------+ | : : : : \ / : : : : target \ / lookup : : : : updates \ / failover : : : : v v : : : : +--------------+ : : : : | CLIENT-SIDE | : : broker : : | CACHE | client : : process : : +--------------+ process : .................. ................................................ Figure 2. Matchmaker Client with Broker on Remote Host To support feature-based lookup, the matchmaker groups components into categories, and defines a partial ordering on categories that allows hierarchical relationships to be formed between them. To support categories, the matchmaker uses a general-purpose directory service accessed via LDAP, the Lightweight Directory Access Protocol (described in RFC's 1777 and 2253). Matchmaker data stored in the directory are described in section 2.5, while matchmaker interactions with the directory are described in section 2.7. Note that the use of feature-based lookup and hence the use of a directory are architected as optional. The matchmaker will fully support lookup using only component identity information, in which case the directory will not be needed. Hence any CIDF-compliant component can reasonably use matchmaking as architected here without having to interact with a directory. Kahn, Bolinger, Schnackenberg [Page 7] DRAFT Communication in CIDF 8 June 1998 2.3 Key Abstractions 2.3.1 Lightweight Components We assume the following of lightweight components: * They cannot speak TCP * They have limited memory * They have limited non-volatile storage Hence they are unable to accommodate directly the functionality of a broker, with consequences we examine below. One way in which lightweight and normal-weight components are alike is that neither have their own entries in the directory. Instead, an entry exists for the host on which components (or their broker) run. (See the description of host identity in subsubsection 2.3.2.1.) Note that a resource-limited host may not be able to support public-key cryptography either. In that extreme case, the CIDF component may need to be distributed over two (or more) hosts, one richer in resources than the other. The resource-limited host will collect the raw data. The richer host can perform cryptography, encoding, and other functions of a CIDF component. The CIDF architecture permits such a distributed implementation. The two symbiotes will need to establish a secure channel between themselves somehow, but that is outside the scope of CIDF. Still another possibility is that the resource-limited host communicates without any cryptographic protection at all. 2.3.2 Authentication Conventions The matchmaker normally requires that components be authenticated. Brokers also mutually authenticate themselves with the directory service, if one is in use. To allow the needed authentication, the matchmaker defines two types of identity, for hosts and individual components. When a directory is used, the matchmaker also defines category identity, as specified below. 2.3.2.1 Host Identity Each host on which a broker runs MUST possess its own certificate or certificate chain, which associates a public key with the host's DNS name. Such certificates SHOULD be signed by a certification authority Kahn, Bolinger, Schnackenberg [Page 8] DRAFT Communication in CIDF 8 June 1998 that the relevant CIDF components trust sufficiently. The generation and distribution of these initial certificates are outside the domain of the matchmaker. As a practical matter, these certificates SHALL be in X.509v3 format, though using DSA instead of RSA to generate signatures. 2.3.2.2 Component Identity 2.3.2.2.1 Stable Component Identifiers The matchmaker records a *stable component identifier* as part of the information needed to look up a component in the directory. A stable identifier MUST be either a component instance identifier or a component program identifier, as specified in section 1.5 of the CIDF framework document. ### Need to update cross-document reference To be listed in the directory, a given component MUST specify a stable identifier for itself according to these rules: * If at most one instance of the component can be active concurrently on a given host, then the component MAY specify as its stable identity EITHER its program identifier OR its instance identifier, with the latter used as specified in the next paragraph. * If more than one instance of the component can be active concurrently on a given host, then the component SHALL specify its instance identifier as its stable identity, and the component SHALL specify the same instance identifier on restart, as outlined in section 1.5 of the CIDF framework document. ### Need to update cross-document reference 2.3.2.3 Unstable Component Identifiers A component that does not specify a stable component identifier SHALL NOT be listed in the directory. The identifier for such a component could be considered an *unstable component identifier*. 2.3.2.3.1 Broker Client Identifiers A *broker client identifier* comprises all of the information needed to look up a given instance of a given component in the directory, specifically the directory entry of the broker for the component plus a stable component identifier. Kahn, Bolinger, Schnackenberg [Page 9] DRAFT Communication in CIDF 8 June 1998 2.3.2.3.2 Authenticating Components As explained in section 2.5, a client component is contacted via multiple steps, starting with looking up a directory entry for its broker. The client component itself is located using an attribute of this entry. Each such attribute identifies the host on which the client component runs, and provides a stable component identifier for it. When authenticated communication is required, it is a host principal (as represented by its public-key certificate) that conducts key negotiation on behalf of each party to the communication, whether the party is a broker, a broker's client component, or a directory server. Authentication SHOULD be performed at these points in the lookup process: If broker and client component run on different hosts, then the client SHOULD authenticate the broker on initial contact. On initial contact with a directory server, the broker SHOULD authenticate the server, and MUST be prepared to authenticate itself to the server if so requested. On initial contact with a remote component, a local client component SHOULD authenticate the remote component, and SHOULD be prepared to authenticate itself to the remote component if so requested. Thus, when a broker's client component is on a host different from that of the broker, it is the client's host principal that interacts with the broker. And in all cases, it is the client's host principal that interacts with other clients. See section 2.7 for further details. If component and broker are running on different hosts, then the component MUST be running on a "certifiable" host, that is, a host possessing a certificate as described in subsubsection 2.3.2.1. If component and broker are on the same host, then being able to invoke the broker at all MUST be an operation sufficiently restricted to suit local authorization policy, and the communications channel between the two MUST be secure. The broker MUST be able to ascertain accurately the identity of the invoker, whoever provides that information. 2.4 Matchmaker Components The architecture of matchmaking was designed to meet these major goals: Kahn, Bolinger, Schnackenberg [Page 10] DRAFT Communication in CIDF 8 June 1998 * It allows expensive directory functionality needed mainly at component initialization time to be offloaded from the component itself, both promoting modularity and allowing lightweight components to participate in matchmaking just like any others. * It allows lookup of other components to proceed either with or without directory support, by providing separate API's to look up components either by "feature" (i.e., using categories) or via identifying information (e.g., address). * It does not degrade the ongoing operation of components that use it. That is, the broker is not a gateway. It does not handle gido's, or interpose itself in any way between components it has matched to each other. * It provides a failover capability in the event of directory failure or compromise. Endpoint information recently looked up using a given broker remains available for component use, even if lookup operations would not currently succeed. This section explores the architectural components of the matchmaker: the communications module, the broker, the authentication/authorization module, and the client-side cache. 2.4.1 Communications Module The nature and location of the broker for a given component will be hidden beneath configuration-neutral API's. For the cases in which the broker is not in the same process as the client, this implies the definition of a protocol (albeit a simple one) by which stub code in the client will contact and use a broker, and recover from errors in the process. The role of the communications module is to implement this protocol. When the broker is collocated with its client, a null implementation of the module is provided. Regardless of the location of the broker, it must be contacted via the interfaces exported by this module. However, these interfaces are not visible to the client. Rather, they are used by other modules of the matchmaker, as shown in the figures in section 2.2. If the broker runs on a different host than the client, the two must authenticate one another, and must be able to negotiate integrity and/or confidentiality checks on their communications. 2.4.2 Matchmaking Broker The broker architecture is meant to go as far as possible toward meeting the goals listed in section 2.4 without requiring additional complexity Kahn, Bolinger, Schnackenberg [Page 11] DRAFT Communication in CIDF 8 June 1998 in the component itself. The broker plays two roles in matchmaking: handling incoming requests from remote components that target its client, and processing outgoing requests from its client that target other components. The protocols used in each form of processing are described in section 2.7. 2.4.2.1 Client Operations on Broker Here we describe an encouraged approach for clients to interact with a matchmaking broker. These descriptions deliberately omit any details of what interfaces might be used to request the operations, and are intended only as guidelines for potential implementations. Once initialized, a client uses its broker to look up other components. A lookup initiated by a broker's client is termed an *outbound lookup*. One initiated by some remote component is termed an *inbound lookup*. For any form of outbound lookup, the broker should update its caller cache to contain information about the current client (potentially used later for local matchmaking). Matchmaking depends upon two roles in establishing communication, an *initiator* role and an *acceptor* role. Any client performing an outbound lookup first assumes the initiator role in seeking contact with any associates already active. In addition, such a client has the option of assuming the acceptor role, by asking to wait for future inbound lookups. This action is called a *persistent lookup*. The normal procedure for establishing an association would then be that one would-be associate issues a persistent lookup, which is satisfied by a later lookup (either persistent or not) by a second associate. Note that, when a directory is in use, the host for the client MUST have been added already to each category implied by the lookup request. These operations form part of "host certification", as described in subsection 2.7.2. 2.4.2.2 Local Matchmaking At least when a directory is used, a broker will need to track the gido classes in use by any of its clients, so that the broker can register itself as a producer or consumer in the appropriate categories. It seems worthwhile to generalize this capability sufficiently to allow a broker to match components itself (i.e., with no external lookup) when it is the broker for all components involved. 2.4.3 Authentication/Authorization Module Conceptually, at least, this module contains the authentication Kahn, Bolinger, Schnackenberg [Page 12] DRAFT Communication in CIDF 8 June 1998 component of the standard CIDF library. The module SHALL be used by components that wish to authenticate to one another. It also SHALL be used by a client to achieve mutual authentication with a broker running on a remote host. ### The following general description must be fleshed out ### with specifics for the authentication and authorization ### mechanisms chosen. This module also must support whatever mechanism is used to provide category membership authorization, as described in subsection 2.7.3. 2.4.4 Client-Side Cache A client will cache information about some number of recently- established associations. This cache will be persistent (on-disk). The goal of this cache is survivability, not performance. The cache will be used in these contexts: 1. If conventional directory lookup fails due to server unavailability, lookup in the cache will be attempted instead. This approach counters attacks on directory availability. 2. Even when conventional directory lookup succeeds, the results of lookup in the cache will be used to augment the results of directory lookup. This approach counters attacks on directory content. 2.5 Directory Data Formats and Organization This section describes how the matchmaker will use LDAP to store data. The section presents object type definitions, detailed attribute definitions, and the rationale behind the definitions made. 2.5.1 Category Entries The LDAP directory SHALL contain an entry for each CIDF category. Category names structure the directory hierarchy. Each category defines a branch point in the directory. Each category used by the matchmaker has a name that specifies the "path" to the category from the root of the directory tree. This we call a *fully-qualified category name*. Though each category may have multiple supercategories, it has only one fully-qualified name. A *relative category name* represents the "lowest" link in the directory Kahn, Bolinger, Schnackenberg [Page 13] DRAFT Communication in CIDF 8 June 1998 hierarchy of the fully-qualified name of a category. (In LDAP terms, this is the RDN of the category.) A category is represented in LDAP as an auxiliary object class. The class definition must contain: * a superCategoryList attribute -- the names of the supercategories * a subCategoryList attribute -- the names of the subcategories * a registeredProducerList attribute -- the names of the components that are registered as producers of this category * a registeredConsumerList attribute -- the names of the components that are registered as consumers of this category The first element of the superCategoryList of a given category SHALL be the category's *primary supercategory*. The fully-qualified name of the category SHALL be identical to that of its primary supercategory, except that the relative name of the category (i.e., its categoryName attribute) SHALL be appended to it. 2.5.2 Broker Entries Each CIDF component accessible using the directory has a *broker entry*, that is, a distinguished name with which lookup of the component begins. This broker entry identifies the broker associated with the component. For normal-weight components, this is simply the host on which the component runs. For lightweight components, this is the host on which the broker runs. A broker entry is a directory entry describing a network device or host on which a broker resides. The broker entry contains a list of clients that the broker serves. For each client the entry contains, among other things, (a) the host name and (b) a stable component identifier. The precise content is described below. A broker entry MUST be a leaf entry in the directory tree. It MAY have EITHER a structural object class OR an auxiliary object class. For convenience, we define both: (a) a structural object class (cidfMatchmakingBroker) to be used for a "broker-bearing" host that has no better representation among the pre-defined object classes, and (b) an auxiliary object class (cidfMatchmakingHost) to be "mixed in" to an entry best expressed as a pre-defined object class. Kahn, Bolinger, Schnackenberg [Page 14] DRAFT Communication in CIDF 8 June 1998 Regardless of the object class of the directory entry, the lookup of a component has these steps: 1. The directory client looks up the category desired, asking for the registeredProducerList or registeredConsumerList of the category directory entry. 2. The directory client looks up each component broker entry that it finds in the list, asking for the cidfComponentList attribute of the broker. 3. The directory client parses the value returned. This means examining the category membership lists and any filter expression stored for each component, and contacting the component if it seems to be of interest. 2.5.2.1 cidfMatchmakingBroker This structural object class defines a directory entry corresponding to a network host on which a broker may run, and records information about the CIDF components that are clients of the broker. This class must contain a cidfComponentList attribute for that purpose. 2.5.2.2 cidfMatchmakingHost This auxiliary object class allows the directory entry corresponding to a network host on which a broker may run to record information about the CIDF components that are clients of the broker. That is, the class allows the directory entry to contain a cidfComponentList. The definition must be applied to some existing structural class in order to be instantiated. 2.5.3 CIDF Component Information To be findable with feature-based lookup, a CIDF component instance must have information present in the LDAP directory tree. This information is not in the form of an LDAP object, but rather is a portion of the broker's LDAP object. The component information MUST include: * a cidfInboundAbsoluteRoute attribute * a cidfStableComponentID attribute * a cidfInterfaceType attribute Kahn, Bolinger, Schnackenberg [Page 15] DRAFT Communication in CIDF 8 June 1998 This information MUST include at least one of the following two attributes, and may contain both: * a cidfProducerMemberList attribute * a cidfConsumerMemberList attribute This information also MAY include: * a cidfFilterExprList attribute 2.5.4 Attribute Definitions A directory entry relevant to the matchmaker must contain some subset of the following attributes. The exact required contents of a given entry appears as part of its object class definition, as described in subsection 2.5.1, subsection 2.5.2, or subsection 2.5.3. 2.5.4.1 Category Attributes The following attributes are part of the definition of the category object class. 2.5.4.1.1 organizationalUnit (ou) To avoid defining a new "name form" (i.e., a new attribute usable in forming distinguished names), we plan to use the existing "ou" attribute to name categories. To clarify which "ou" attributes refer to categories (as opposed to true "organizational units"), a category name MUST begin with the prefix "cidf". For example, the category grouping all fileservers in the Phoenix office of a hypothetical corporation might be: ou=cidfFileservers, ou=phoenix, o=Netlife Associates, c=us or: ou=cidfFileservers, ou=phoenix, dc=netlife, dc=com 2.5.4.1.2 superCategoryList This attribute is a group containing fully-qualified category names, each of which specifies one supercategory of the current directory entry, which must represent a category. The category's primary supercategory is included in the group. Kahn, Bolinger, Schnackenberg [Page 16] DRAFT Communication in CIDF 8 June 1998 2.5.4.1.3 subCategoryList This attribute is a group containing fully-qualified category names, each of which specifies one subcategory of the current directory entry, which must represent a category. 2.5.4.1.4 registeredProducerList This attribute is a group containing component broker entries, each of which serves to look up one or more alleged producers of gidos in the current category. Each element is the DN of a broker entry for a component claiming to be a producer of information for the current category. 2.5.4.1.5 registeredConsumerList This attribute is a group containing a sequence of component broker entries, each of which serves to look up one or more alleged consumers of gidos in the current category. Each element is the DN of a broker entry for a component claiming to be a consumer of information for the current category. 2.5.4.1.6 memberCertificate This attribute is an X.509-derived certificate specifying what principals are authorized to produce into and consume from the category. The certificate will be signed by the principal whose LDAP name is the category's name. See subsection 2.7.3 for further details. ### The general description above must be fleshed out ### with specifics for the authentication and authorization ### mechanisms chosen. 2.5.4.2 Broker Attributes The following attribute is part of broker-related object classes. 2.5.4.2.1 cidfComponentList This attribute records the components that are currently registered as running on a given network host. (The use of cidfComponentList is described in subsection 2.5.2; the client-only object class cidfComponent is described in subsection 2.5.3). Note that the value of this attribute is not interpreted by the LDAP server. It is passed as a "blob" to the LDAP client (and received from the client in the same way). Kahn, Bolinger, Schnackenberg [Page 17] DRAFT Communication in CIDF 8 June 1998 2.5.4.3 Component Attributes The following attributes are part of a CIDF component descriptor. The values of these attributes are not interpreted by the LDAP server. They are passed as opaque blobs to the LDAP client. 2.5.4.3.1 cidfInboundAbsoluteRoute This value represents an inbound absolute route to the component of whose description it is a part, as described in section 3.2. 2.5.4.3.2 cidfStableComponentID This attribute contains a stable component identifier, as described in subsubsection 2.3.2.2. 2.5.4.3.3 cidfProducerMemberList This attribute contains a sequence of fully-qualified category names, in each of which the current component is registered as a producer. 2.5.4.3.4 cidfConsumerMemberList This attribute contains a sequence of fully-qualified category names, in each of which the current component is registered as a consumer. 2.5.4.3.5 cidfFilterExprList This attribute specifies a sequence of CIDF-style *S-expression* values, each of which provides details about the information (gidos) produced or consumed by a CIDF component. The current directory entry must represent that component. 2.5.4.3.6 cidfInterfaceType This attribute specifies the interface(s) presented by the component as a four-bit mask, where the bits represent: * push-style producer * push-style consumer * pull-style producer * pull-style consumer Kahn, Bolinger, Schnackenberg [Page 18] DRAFT Communication in CIDF 8 June 1998 2.5.5 Rationale for LDAP Definitions 2.5.5.1 Directory Entry Creation We choose to create directory entries only for brokers, and not for individual components. The motivation for this is twofold: 1. First, it follows existing convention for the use of LDAP, in which "leaf" entries (roughly speaking, entries that contain a common name attribute) are commonly associated with network-addressable entities like printers or computers. 2. Second, it avoids the need to consider an entry specifying a network host as being a directory branch point. That is, it avoids the need to create further directory entries describing individual components beneath the entry describing the host on which they run. This, too, hews to existing convention. 2.5.5.2 Category Object Class We wish categories to play a structural role in the directory tree, but we wish to avoid extending the directory schema to allow them to do so. In LDAP terms, we wish to avoid defining a new name form or DIT structure rule. This implies that category should be defined as an auxiliary object class, not as a structural object class. In this role, the class definition merely allows category-related members to be present in a given object. The definition must be applied to some existing structural class in order to be instantiated. 2.5.5.3 Broker-Related Object Classes Since the directory entry relating to a broker plays no structural role in the directory, we can define a new structural object class for it without any repercussions on the directory schema. Hence we define both a structural and an auxiliary object class, and leave the choice between them to the discretion of the directory maintainer. 2.6 Component Lookup Protocol In the absence of a matchmaker-specific directory, lookup calls MUST provide identifying information about desired associates that is independent of what the matchmaker uses. The exact nature of the information provided depends on the matchmaking implementation and the Kahn, Bolinger, Schnackenberg [Page 19] DRAFT Communication in CIDF 8 June 1998 API's it presents. If a component does not use a matchmaker-specific directory, then the component MUST itself provide information about other CIDF components it communicates with. For each one, the component MUST provide a DNS hostname and MAY provide an inbound absolute route, as described in section 3.2. This information MAY be in persistent storage local to the component's host, or MAY be derived by other means outside the scope of this specification. This style of lookup does not involve matchmaking per se, nor does it involve a broker. Rather, the local component uses the authentication/ authorization module to negotiate the desired style of communication with the remote component, as described in subsection 2.6.1. In the descriptions that follow, we cover separately the operations that occur on the outbound path (i.e., on behalf of the component requesting an association) and those on the inbound path (i.e., on behalf of the component contacted by the requester). Association establishment involves both sets of operations, so the two sets need to be considered in parallel. NOTE: for simplicity, we assume here that each lookup operation yields only one matching remote component. In fact, the API's provided will doubtless deal in terms of sets of matching components, but this has no architectural implications so is not further alluded to here. 2.6.1 Outbound Lookups To establish communication with a remote component, the authentication/ authorization module SHALL perform the following steps: * Lock out concurrent association formation. * Check for a duplicate association (i.e., one already existing between the client and the remote component) made or in progress. Handling of dups will be specifiable by application, with a default of rejecting the more recent duplicate. * Register pending association. * Negotiate the desired set of transport options for communicating with the remote component, as described in section 4.6. * If the component is reachable: Kahn, Bolinger, Schnackenberg [Page 20] DRAFT Communication in CIDF 8 June 1998 - Return to the local component a session handle identifying the key generator identity and security parameters index that apply to this negotiated transport, as described in section 4.4. * If the component is not reachable: - If the lookup is non-persistent, FAIL. - If the lookup is persistent, block to await inbound lookups targeting the client. * Allow new association formation for this client. "Reachable" means that the remote component has initialized, and has performed a persistent lookup operation for which the client is a match. Obviously the remote component may refuse the requested association, or the broker may be unable to authenticate the component. The nature of the session handle returned to the client is an API issue internal to a specific implementation, and is not further specified here. 2.6.2 Inbound Lookups To enable itself to be contacted by a remote component, as when performing a persistent lookup, a given component SHALL use a facility provided by the matchmaker to await contact, so that its local broker can be notified when contact occurs. This facility SHALL employ the authentication/authorization module as specified below: * Lock out concurrent association formation for this component. * Check for a duplicate association (i.e., one already existing between the local component and the remote component) made or in progress. Handling of dups will be specifiable by application, with a default of rejecting the more recent duplicate. * If the component has not performed any persistent lookup operations, FAIL. * If the component has performed a persistent lookup that does not match the active remote component, FAIL. * Register pending association. Kahn, Bolinger, Schnackenberg [Page 21] DRAFT Communication in CIDF 8 June 1998 * Negotiate the desired set of transport options for communicating with the remote component, as described in section 4.6. * Return to the local component a session handle identifying the key generator identity and security parameters index that apply to this negotiated transport, as described in section 4.4. * Allow new association formation for this component. Obviously the client may refuse the requested association, or the broker may be unable to authenticate the remote component. The nature of the session handle returned to the client is an API issue internal to a specific implementation, and is not further specified here. 2.7 Matchmaking Protocol When a matchmaker-specific directory is provided, lookup calls SHOULD specify associates in one of two ways: 1. by CIDF-independent identifying information (such as an IP address) 2. by a gido class (to employ feature-based lookup) The first form of lookup uses the protocols described in section 2.6. The last style of lookup involves using the category hierarchy stored in the directory, as described in this section. Note that it is also possible for a client to specify an associate using a broker client identifier, but this is discouraged. The availability of such identifiers is merely an artifact of the supported directory organization. In any case, lookup calls MUST use either one of the encouraged forms of lookup or lookup by broker client identifier. 2.7.1 Category Identity Category identity is represented by the fully-qualified name of the category in the overall hierarchy. To provide non-repudiation of assertions about authorization, each category has its own public/private key pair, generated when the category is created. 2.7.2 Host Certification vs. Component Registration Every category records what hosts are eligible to participate in it (i.e., read or write data belonging to it). Eligible hosts are said to Kahn, Bolinger, Schnackenberg [Page 22] DRAFT Communication in CIDF 8 June 1998 be certified in the category. Certification is an operation performed by some agent outside the matchmaker, and is unrelated to whether components on the host are actually active at any particular time. Certification SHALL involve creating a "broker entry" for the host in the directory, if none exists, then adding the name of the broker entry to the producer or consumer group of the category. The structure of the broker entry, and of category groups, are described in section 2.5. Every broker entry, in turn, SHALL record hints as to which components that rely on a given broker are actually currently active. These hints are updated as associations are established and terminated, as via client lookup requests. These, too, are described in section 2.5. 2.7.3 Category Membership Authorization ### The general description below must be fleshed out ### with specifics for the authentication and authorization ### mechanisms chosen. To avoid trusting the directory service as a source of associates, the matchmaker will use some form of public-key authorization system. Candidates are X.509-based approaches and SDSI. In any case, the role of the system is to prove that a given host is certified in a given category as producer, consumer or both. A plausible approach is to generate an appropriate certificate as part of the process of adding an eligible host to a category, and will be signed by the key of the category itself. 2.7.4 Outbound Lookups 2.7.4.1 Lookup by Gido Class When contacted by a client that has specified a gido class, the broker SHALL perform the following steps to locate contact information for remote components: * Establish connection to directory server. * Mutually authenticate with directory server. * Verify that the client host is certified in each category specified by any gido class in the client request. ### The general description above must be fleshed out Kahn, Bolinger, Schnackenberg [Page 23] DRAFT Communication in CIDF 8 June 1998 ### with specifics for the authentication and authorization ### mechanisms chosen. * If the client is not currently registered in the directory, and if it presented a gido class, prepare a cidfComponent object to represent the client and add the object to the cidfComponentList of the directory entry for the client's broker. * For each category in the gido class: - Look up the category desired, asking for either the registeredProducerList or the registeredConsumerList of the category. - For each component broker entry in the list returned: = Look up the cidfComponentList attribute of the entry. = For each component in the list, derive the following attributes: o its cidfInboundAbsoluteRoute o its cidfProducerMemberList, if any o its cidfConsumerMemberList, if any o its cidfFilterExprList, if any = Match the gido class specified by the client against the categories of which the component is a member. ### Need specifics for matching algorithm. = If client specified a filter expression, match it against the one given. ### Need specifics for matching algorithm. = If remote component matches, add it to the set of components to be contacted. * End connection to directory server. When all categories specified have been processed as specified above, the broker SHALL look up individual remote components using the protocol described in subsection 2.6.1. Kahn, Bolinger, Schnackenberg [Page 24] DRAFT Communication in CIDF 8 June 1998 # The description here must be augmented to reflect the # use of the client-side cache, both when directory lookup # fails and to augment (apparently) successful directory lookup. 2.7.4.2 Lookup by Broker Client Identifier Since component lookup by gido class is essentially a two-step process (look up the directory entries for the brokers associated with relevant components, then look up components in the component list for each broker), it is possible to look up components using the output of the first step of the process, that is, by broker client identifier. The possibility of this form of look up is mostly incidental, and its use is discouraged. Nonetheless we specify it here. When contacted by a client that has specified a broker client identifier, the broker SHALL perform the following steps to locate contact information for the associated remote component: * Establish connection to directory server. * Mutually authenticate with directory server. * Look up the broker entry from the identifier, asking for the cidfComponentList attribute of the entry. * For each component in the list returned: - Derive a cidfStableComponentID attribute. - Match the attribute against the stable component identifier specified by the local client. - If the identifier matches, record it for later contact. * If no matching component is found, FAIL. * End connection to directory server. If a matching remote component was found, the broker SHALL look it up using the protocol described in subsection 2.6.1. 2.7.5 Inbound Lookups The use of matchmaking proper (that is, the specification of a GIDO class by the component initiating matchmaking) has no effect on the behavior of the remote component (that is, the one accepting an incoming lookup). That component SHALL have performed an outbound lookup as specified in subsection 2.6.1 or subsection 2.7.4. Kahn, Bolinger, Schnackenberg [Page 25] DRAFT Communication in CIDF 8 June 1998 3. Routes CIDF components need to communicate across firewalls, some of which are nontransparent. To communicate across a nontransparent firewall, you address packets to a proxy associated with the firewall, and the proxy forwards the packets to the real (or next) destination. Some firewalls are transparent in the outbound direction and nontransparent in the inbound direction. 3.1 Source Routes To reach a host in this environment, you supply a *source route*. This route consists of zero or more addresses of proxies, followed by the address of the destination host. CIDF source routes differ from IP source routes [RFC 1812], because CIDF source routes specify proxies rather than IP routers. CIDF source routes are similar to e-mail source routes [RFC 822]. The correct route to use depends on the starting point. This is a problem; the directory needs to hold fixed addressing information for a given host, independent of the starting point. 3.2 Absolute Routes So, what goes into the directory for a CIDF host is an *inbound absolute route*. If the host is reachable from the general Internet, then the inbound absolute route is a source route that would get a packet from *ietf.org* to the host. If the host is on a private network not reachable from the general Internet, then the network administrators must choose a different anchor point. If the route from the anchor point to the host crosses n firewalls then the inbound absolute route is a string of n+1 addresses. Each CIDF host MUST know its own inbound absolute route and its own outbound absolute route. The outbound route SHOULD have the property that the host can use it, with the anchor point's address appended, as a source route to reach the anchor point. The outbound absolute route MUST be shorter by one address than the inbound absolute route. It SHOULD consist of addresses of proxies and, optionally null values (zero for IPv4) to indicate that the corresponding firewall is transparent in the outbound direction. The outbound route MAY be formed by: (a) reversing the host's inbound absolute route (b) deleting the first entry (the host's own address) Kahn, Bolinger, Schnackenberg [Page 26] DRAFT Communication in CIDF 8 June 1998 (c) optionally replacing one or more addresses with a fill value (zero for IPv4), to indicate that the corresponding hop is transparent in the outbound direction To compute the source route for reaching a CIDF host, you MAY: 1. take the target host's inbound absolute route (obtained, for example, from the directory) 2. compute the common prefix of its inbound absolute route with your host's own inbound absolute route 3. strip that prefix off its inbound absolute route 4. strip the same number of elements from the end of your outbound absolute route 5. append the absolute route from step 3 to the outbound absolute route from step 4 6. if the resulting route is empty, you are there already 7. otherwise, the resulting route is the source route to use The foregoing procedure applies even in the degenerate case where the target host is your host. The format of an absolute route for IPv4 addresses is: octets contents ------ -------- 0 1 -- indicates IPv4 1 Number of addresses -- unsigned octet 2 - 3 Reserved, must be zero 4 - (3+4*n) Addresses All of the foregoing is IP-specific. However, it is not our intention to limit CIDF to IP environments. Other address types can be added. 4. Message Layer 4.1 Rationale for Message Layer The CIDF message layer was developed to solve problems of synchronization (i.e., blocking vs. non-blocking processes) and problems of different data formats for different operating systems. It also solves the problem that different groups will use different Kahn, Bolinger, Schnackenberg [Page 27] DRAFT Communication in CIDF 8 June 1998 programming languages. In other words, the use of a messaging format achieves the following goals: * Independent of blocking/non-blocking processes * Data format independent * Operating system independent * Programming language independent 4.2 Objectives of the CIDF Message Layer The top-level objectives for the CIDF message layer are to * Provide an open architecture. * Avoid imposing architectural constraints or assumptions on the systems or modules. * Allow messaging independent of language, operating system, and network protocol. * Support easy addition of new components to the CIDF. * Support security requirements for authentication and privacy. * Support devices that don't want to fully support CIDF. 4.3 Message Format This message structure resides on top of the negotiated transport layer service. Note that all reserved fields are set to 0 on transmission and ignored on receipt. Kahn, Bolinger, Schnackenberg [Page 28] DRAFT Communication in CIDF 8 June 1998 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Control Byte | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Privacy Trailer* (variable) | +-+-+-+-+-+-+-+-+ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * if privacy option is used Options all have a common type-length-value format described below. * Version - 1 octet. CIDF message-layer version (1 for this initial version). * Control Byte - 1 octet. Used by the message layer to support reliable transmission, flow control, and security association management. - Acknowledgement of a delivered message (1). - Message received, but not delivered because of lack of resources (2). - Message received, but the supplied security association was not available to all processing (4). Kahn, Bolinger, Schnackenberg [Page 29] DRAFT Communication in CIDF 8 June 1998 * Checksum - 2 octets. A checksum across the entire CIDF message, prior to application of cryptographic mechanisms (i.e., privacy and authentication transforms). The checksum is computed as specified in the TCP standard (RFC 793). * Next Header - 1 octet. Defines the type of either the next message layer option or application. The following are the currently defined types. - Application Header (1) - Route List (4) - Privacy Header (50) - Authentication Header (51) * Length - 4 octets. Length of the CIDF message, including message header. * Sequence Number - 4 octets. Message layer sequence number used for message reliability (acknowledgement and duplicate removal) and to support protection against message replay. * Time Stamp - 4 octets. Used to provide loose time synchronization between CIDF communicating parties and to support tardy delivery detection (from denial of service). * Destination Address - 4 octets. IP address of the target of this message. This field identifies the eventual recipient of the CIDF message and is used to route CIDF messages through intermediate CIDF nodes that cannot be traversed by normal network routing (e.g., firewalls). 4.4 Message Layer Protocol Options Except for the CIDF privacy option, CIDF message options use the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Data (variable) | ~ ~ | | Kahn, Bolinger, Schnackenberg [Page 30] DRAFT Communication in CIDF 8 June 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next Header - 1 octet. Defines the type of either the next message layer option or application, with the same permitted values as defined above. * Length - 1 octet. Specifies the number of 32-bit words for this option, including the next type and length fields. * Option Data - variable length. The option data field is always padded to a 32-bit aligned size. 4.4.1 Route List Option Route List is a variable length field that specifies the CIDF nodes through which the message is to be routed for source routing, and through which the message has been routed for recorded routing. The Subtype field indicates whether this is a source or record route. The Route List has the following format. The route list option is used when the message destination and source are separated by CIDF nodes that cannot be traversed by normal network routing (e.g., firewalls). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Length | Subtype | Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next Header and Length are defined above. * Subtype - 1 octet. Specifies whether this is a recorded route or a source route. - Recorded Route (1) - Source Route (2) * Index - 1 octet. Index into the array of addresses specifying the current address to be processed. For source routing, this is the address of the next CIDF hop. For recorded routes, this is the address of the last transmitting CIDF node. * Route Data - variable length. This field is an array of Internet addresses. Each internet address is 32 bits or 4 octets. For a Kahn, Bolinger, Schnackenberg [Page 31] DRAFT Communication in CIDF 8 June 1998 source route, if the index is greater than the length, the source route is empty and the routing is to be based on the destination address field. For a recorded route, if the index is greater than the length, the recorded route list is full. 4.4.2 Privacy Option The CIDF privacy option supports both unicast or multicast privacy. For multicast privacy, one node of the multicast group is selected to generate the keys. The keys are then distributed to each multicast group member. For unicast privacy, each node generates its own privacy keys which are distributed to the remote party. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Generator Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data* (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Key Generator Identity - 4 octets. This value identifies the CIDF entity that generated the key. The initial use of this field is to specify either the key generator's IP address or for multicast applications the multicast address for the multicast group using this security association. * Security Parameters Index (SPI) - 4 octets. The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this message, relative to the key generator identity. * Padding - variable length. The transmitter may add up to 255 bytes of padding if required to support the block size of the cryptographic algorithm. Padding is required to ensure that after the privacy option is applied, the message ends on a 4-byte boundary. * Pad Length - 1 octet. The number of padding bytes immediately preceding it. The range of valid values is 0-255, where a value of Kahn, Bolinger, Schnackenberg [Page 32] DRAFT Communication in CIDF 8 June 1998 zero indicates that no Padding bytes are present. * Next Header is defined above. If the cryptographic algorithm requires use of an initialization vector, then that vector is placed as clear text between the SPI and Payload Data. 4.4.3 Authentication Header Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Generator Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next Header and Length are defined above. * Key Generator Identity - 4 octets. This value identifies the CIDF entity that generated the key. The initial use of this field is to specify either the key generator's IP address or for multicast applications the multicast address for the multicast group using this security association. * Security Parameters Index (SPI) - 4 octets. The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this message, relative to the key generator identity. * Authentication Data - variable number of 32-bit words. The data (e.g., digital signature or keyed hash) used to provide cryptographic authentication. 4.5 Cryptographic Mechanisms The CIDF message layer protocol provides data integrity and source authentication services for the negotiation phase of CIDF communication. This enables components to reliably establish communications with minimal security overhead. During the negotiation phase, the client and server determine the specific cryptographic services to be provided for Kahn, Bolinger, Schnackenberg [Page 33] DRAFT Communication in CIDF 8 June 1998 further communication. The message layer provides the cryptographic mechanisms as options, enabling use of lower-level services (e.g., IPSEC), CIDF-specific mechanisms, or no cryptographic services, depending on application requirements. The mechanisms used are determined by the client based on the mechanisms supported by the server. The message layer mechanisms provide the fields necessary to (1) determine the cryptographic services applied (if any), (2) determine the cryptographic context, and (3) provide timeliness and replay protection. 4.6 Negotiation Mechanism 4.6.1 Introduction Our approach is to use the simplest reliable transport mechanism available (i.e., reliable CIDF messaging over UDP) as the default CIDF transport protocol. This simple protocol can then be used to negotiate a more or less complex protocol for those components requiring additional transport-layer services. This allows simple devices to participate easily, while allowing complex devices to take full advantage of other transport-layer mechanisms. The message layer provides optional services to compensate for weaknesses in the transport layer. The combination of the CIDF message layer with transport-layer options provides a range of communication capabilities that can be used to support different application requirements. The following types of transport/messaging are initially envisioned: * No assured delivery over a connection-less transport. That is, the CIDF message layer without acknowledgement and retransmission directly over UDP. * Assured delivery over a connection-less transport. That is, the CIDF message layer with reliable delivery (acknowledgement, retransmission, and duplicate removal) over UDP. * Assured delivery over a connection-oriented transport. That is, the CIDF message layer directly over TCP. * Object-oriented transport. That is, the CIDF operations over CORBA. To enable support for components that must use minimal communication infrastructure, the default transport mechanism is based on UDP. The following sections define the default transport layer protocol, CIDF security services, and the transport negotiation mechanisms. Kahn, Bolinger, Schnackenberg [Page 34] DRAFT Communication in CIDF 8 June 1998 4.6.1.1 Rationale for negotiated transport layer The simplest approach would be to mandate the use of a single transport protocol. But there is no one protocol that can adapt to the varying requirements of all anticipated CIDF applications. Depending on whether an application is concerned with real-time traffic or simple accrual of a database of events, different transport mechanisms are appropriate. Specifically, some CIDF applications require a very light-weight communication channel that does not have the resource usage required by current TCP implementations, while other applications require a flexible and robust communication channel such as TCP. Other requirements include application-specific support for multicast, which is not supported by TCP. Therefore, we have requirements for connectionless communication, reliable connectionless communication, and reliable connection-oriented communication. Additionally, we have varying requirements for security services. In some applications and environments, the infrastructure provides adequate security services. In other applications, we require CIDF-layer security services for authentication, privacy, or both. Nevertheless, communications clearly cannot begin between two specific components until a channel is agreed upon. At the very least, this implies that if we don't agree on a single channel for all transport, we need to agree on a single channel for transport negotiation. This channel needs to be widely supported and freely available. Components are allowed to share data on whatever channel they wish, but they MUST support channel negotiation on the common mechanism. To support this range of requirements we provide a protocol based on the reliable UDP variant of CIDF that enables applications to agree upon the desired transport protocol, plus the desired CIDF message-layer security services. This exchange is only necessary if the participants have not previously agreed upon a transport mechanism through external mechanisms (e.g., local configuration settings or through the CIDF directory service). 4.6.2 Default Transport Layer The default transport layer protocol for CIDF messages is reliable CIDF messaging over UDP. Other transport layer protocols may be used following a negotiation using the default of protocols and services required and supported by the CIDF client and server. Until we acquire a well-known CIDF port number, we will use 0x0CDF as the CIDF port. The CIDF message layer will listen on the CIDF well-known port for incoming CIDF messages. Kahn, Bolinger, Schnackenberg [Page 35] DRAFT Communication in CIDF 8 June 1998 4.6.3 Conformant transport options * CIDF message layer without acknowledgement and retransmission directly over UDP. * CIDF message layer with acknowledgement and retransmission over UDP. * CIDF message layer directly over TCP. 4.6.4 Option Negotiation Message Formats The negotiation for more advanced communication services occurs over a UDP channel using only the CIDF message layer with authentication mechanisms enabled. This enables components that do not support TCP to participate in CIDF. Negotiation occurs by the client querying the server's capabilities. In response, the server specifies the class of CIDF operations supported, message services supported, and whether extensions are supported. The client then selects the services and message mechanisms. This information can also be provided by the directory server. The CIDF transport negotiation protocol resides directly over the CIDF message layer. The query-response data format is shown below. We assume that for cryptographic services, the negotiation of the specific algorithms and modes is handled by the key distribution mechanism. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Request (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Type - 1 octet. Specifies the type of request. For option negotiation messages, this value is 1. * Length - 1 octet. Specifies the number of 32-bit words for this message, including the type and length fields. Option Requests are formatted as follows. Kahn, Bolinger, Schnackenberg [Page 36] DRAFT Communication in CIDF 8 June 1998 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | Length | Option | Selection | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Parameters (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Request - 1 octet. Specifies the type of request. The following request types are currently supported. - Want (1) - Preferred service. - Can (2) - Sender is capable of using this service. * Length - 1 octet. Specifies the number of 32-bit words for this option request, including the request and length fields. * Option - 1 octet. The option being negotiated. The following option types are currently supported. - Transport (1) - Privacy (2) - Authentication (3) * Selection - 1 octet. The option value being negotiated. The meaning of this fields depends on the option being negotiated. The following selection values are currently supported. * For Transport negotiation. - None (0). Used to reject communication with another CIDF node when no acceptable options are received. - UDP (1) - Reliable UDP (2) - TCP (3) * For Privacy negotiation. - None (0) Kahn, Bolinger, Schnackenberg [Page 37] DRAFT Communication in CIDF 8 June 1998 - IPSEC (1) - SSL (2) - CIDF (3) * For Authentication negotiation. - None (0) - IPSEC (1) - SSL (2) - CIDF (3) Currently, the only option parameter specified is the selection of TCP/UDP port number for transport negotiation, which is formatted as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Transport Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Type - 1 octet. Specifies the type of option parameter. For port numbers, this value is 1. * Length - 1 octet. Specifies the number of 32-bit words for this message, including the type and length fields. * Transport Port Number - 2 octets. This specifies on which port number the sender of the message will listen following completion of negotiation. Both ends of the channel select their own respective ports. 4.6.5 Protocol Description Identification of the remote CIDF component's IP address is handled either through manual configuration or through the CIDF directory service. Note that this service may also indicate the CIDF component's capabilities (can) and preferences (want) for transport and security services. When Sender S wishes to communicate with Receiver R, and the two components have not yet agreed on a transport mechanism, then S MUST initiate transport mechanism negotiation. Kahn, Bolinger, Schnackenberg [Page 38] DRAFT Communication in CIDF 8 June 1998 S sends a negotiation message to R on the CIDF well-known port indicating the services preferred (if any) and permitted. S includes a separate option request for each supported option, indicating the preferred option (if any). When R receives an option negotiation, R selects the desired value using local preferences if supported by S, S's preferences if supported locally, or the intersection of local and S's capabilities if the preferences are not specified or supported. If the local and remote capabilities do not permit communication, the R selects a transport option of None, indicating that communication is not feasible. R responds with only the selected options for transport, privacy, and authentication identified as preferred options. 5. Message Layer Processing 5.1 Introduction This section describes the processing of CIDF message layer messages. The standard procedures are used for CIDF messages independent of the transport layer. The reliable transmission procedures describe additional procedures to be used when the transport mechanisms is reliable UDP. CIDF privacy and authentication procedures describe the procedures used in providing CIDF layer privacy and authentication mechanisms, respectively. 5.2 Standard Procedures Each CIDF message uses the standard CIDF header. 5.2.1 Outbound Message Processing On request by the application layer to transmit a CIDF message, the CIDF message layer SHALL build the message header and append the message. If the application indicates that this message requires source routing, then the CIDF message layer SHALL use the supplied source route list. If the application indicates that this message requires recorded routing, then the CIDF message layer SHALL initialize the record route list, placing the outgoing IP address as the first entry on the route list. The CIDF message layer SHALL insert the current CIDF version number, the Kahn, Bolinger, Schnackenberg [Page 39] DRAFT Communication in CIDF 8 June 1998 application-provided destination, and the current time as the CIDF header time-stamp. The CIDF message layer SHALL insert a new sequence number. The sequence number is initialize to 0, and incremented for each message sent by the CIDF message layer. The CIDF message layer SHALL compute the total message length and insert that length into the Length field. The CIDF message layer should compute and insert the checksum prior to message transmission. The checksum is inserted prior to applying CIDF privacy or authentication mechanisms. If CIDF privacy or authentication is being used, the CIDF message layer SHALL encrypt and generate the authentication data for the message based on the current security association in use with the recipient. If CIDF privacy or authentication is being used and no security association exists, then the message transmission request should be rejected. 5.2.2 Inbound Message Processing If the Version field is not a valid CIDF version number (currently 1), the CIDF message layer SHALL discard the message. If CIDF privacy or authentication is being used, the CIDF message layer SHALL decrypt and authenticate the message, and discard the message on failure. On failure, due to lack of a valid security association, the CIDF message layer should send a response to the source. The response is the CIDF message layer header, with the Control Byte set to 4. If the Checksum field is not 0, the CIDF message layer SHALL compute the message checksum (using the method described in RFC 793 and discard the message if the Checksum check fails. If the Time Stamp field indicates an unexpected delay, the CIDF message layer should notify the application. If the Destination Address is not the local CIDF node (i.e., the destination does not match the local node's address or any multicast address that the local node is using), the CIDF message layer SHALL determine the next CIDF hop (using the source route, if provided) and forward the message after adjusting the Sequence Number and Time Stamp. If the message includes a record route option, then the CIDF message layer SHALL enter its outgoing IP address if there is sufficient room in the record route structure and increment the route index. After processing, the CIDF node should compute the checksum as specified in RFC 793, and place the checksum in the Checksum field. Finally, the Kahn, Bolinger, Schnackenberg [Page 40] DRAFT Communication in CIDF 8 June 1998 message layer SHALL apply the privacy and authentication transforms for the next CIDF hop and transmit the message. 5.3 Reliable Transmission Procedures 5.3.1 Outbound Message Processing For reliable message transmission, the CIDF message layer SHALL maintain the round-trip latency and mean deviation values for each node with which the local component communicates. These values are used in determining the timeout values for message transmission. The CIDF message layer SHALL use the standard TCP algorithm for computing message layer timeouts. On reliable message transmission, the CIDF message layer SHALL retain a copy of the message for retransmission purposes and set a timer for the message. If the timer expires before the message is acknowledged, the message layer SHALL retransmit the message up to an maximum of 5 retries. On reception of an acknowledgement for the CIDF message, the CIDF message layer SHALL remove the message from the retransmission queue. 5.3.2 Inbound Message Processing On message reception, the CIDF message layer SHALL send a CIDF acknowledgement to the source. If the message layer can deliver the message to the application layer, then the Control Byte SHALL be 1. Otherwise, the Control Byte SHALL be 2. The acknowledgement message is identical to the original message header except for the Control Byte. The CIDF message layer SHALL use the source IP address and the sequence number to ensure that duplicate messages are not delivered to the application layer. 5.4 CIDF Privacy Procedures 5.4.1 Outbound Message Processing The CIDF message layer encapsulates the CIDF Application Data with an CIDF privacy header and Trailer, encrypts the CIDF Application Data and CIDF privacy trailer. The original CIDF Header is retained, except the CIDF Next Type, which is modified to indicate that this is an CIDF encrypted message. On message transmission, if the CIDF message layer is applying CIDF privacy mechanisms for the message, the CIDF message layer SHALL determine the security association (which determines the algorithm) for Kahn, Bolinger, Schnackenberg [Page 41] DRAFT Communication in CIDF 8 June 1998 the message target, add any required padding, compute and insert the padding length in the trailer, insert the next header in the trailer, perform the cryptographic transform over the resulting plain-text message, and SHALL insert the security association identity (Key Generator Identity and SPI) before the resulting ciphertext. If an initialization vector is required for the cryptographic transform, it SHALL be inserted between the resulting ciphertext and the privacy header. The next header in the CIDF message layer is then set to 50. 5.4.1.1 Message Encryption The CIDF message layer encapsulates the original CIDF application data into the CIDF Application Data field, that includes any necessary padding, and encrypts the result (Application Data, Padding, Pad Length, and Next Header) using the Message Encryption Key, encryption algorithm, and algorithm mode indicated by the security association. 5.4.1.2 Encryption Algorithms The security association specifies the encryption algorithm to be used. The CIDF privacy option is designed for use with symmetric encryption algorithms. Because the messages may arrive out of order, each message MUST carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the Application Data field (e.g., as an IV as described above) or the data may be derived from the message header. Since the CIDF privacy option makes provision for padding of the plain-text, encryption algorithms employed with the CIDF privacy option may exhibit either block or stream mode characteristics. 5.4.2 Inbound Message Processing Upon receipt of an CIDF message containing an CIDF privacy header, the CIDF message layer looks up the security association, and regenerates the CIDF application data. 5.4.2.1 Security Association Lookup The Security Association information is included in the CIDF privacy header. The CIDF message layer looks up the appropriate algorithm and Message Encryption Key for decryption, based on the SPI and Key Generator's identity from the CIDF privacy header. If no valid algorithm and key exists for this message, the receiver MUST Kahn, Bolinger, Schnackenberg [Page 42] DRAFT Communication in CIDF 8 June 1998 discard the message. 5.4.2.2 Message Decryption The receiver decrypts the CIDF Application Data, Padding, Pad Length, and Next Header using the neighborhood Message Encryption Key that has been established for this neighborhood traffic. If an explicit IV is present in the payload field, it is input to the decryption algorithm per the algorithm specification. If an implicit IV is employed, a local version of the IV is constructed and input to the decryption algorithm per the algorithm specification. After decryption, the original CIDF message is reconstructed and processed per the normal CIDF protocol specification. At a minimum, the Next Header field in the CIDF privacy trailer should be moved to the Next Header field in the CIDF header. Note that there are two ways in which the decryption can "fail". The selected security association may not be correct or the encrypted CIDF message could be corrupted. (The latter case would be detected if authentication is selected for the security association, as would tampering with the SPI.) 5.5 CIDF Authentication Procedures 5.5.1 Outbound Message Processing On message transmission, if the CIDF message layer is applying CIDF authentication mechanisms for the message, the CIDF message layer SHALL determine the security association (which determines the algorithm) for the message target, insert the length of the authentication header, insert the next header in the authentication header, insert the security association identity (Key Generator Identity and SPI) before the resulting ciphertext, and perform the cryptographic transform over the resulting message. The next header in the CIDF message layer is then set to 51. 5.5.1.1 Integrity Check Value Calculation The transmitter computes the Integrity Check Value (ICV) over the entire message using the ICV key, hashing algorithm, and algorithm mode indicated by the security association. Since the Authentication Data is not protected by encryption, a keyed authentication algorithm MUST be employed to compute the ICV. If privacy is selected in conjunction with CIDF authentication, encryption is performed first, before the authentication. The Kahn, Bolinger, Schnackenberg [Page 43] DRAFT Communication in CIDF 8 June 1998 encryption does not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus messages by the receiver, prior to decrypting the message, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of messages at the receiver (i.e., decryption can take place in parallel) with authentication. 5.5.1.2 Padding No padding is required if the default 96-bit truncated Hashed Message Authentication Codes (HMAC) algorithm is used. However, if another authentication algorithm is used, padding MAY be required. If an authentication algorithm creates an ICV with length less than an integral multiple of 32 bits, padding may be appended to the Authentication Data field to ensure a 32-bit multiple AH. Alternatively, the ICV may be truncated to a 32-bit multiple length. In addition, if the authentication algorithm requires a multiple of a block size and the CIDF message with CIDF authentication header does not meet the block size requirements, zero-valued padding MUST be appended to the end of the CIDF message prior to ICV computation. This padding is not transmitted with the CIDF message. 5.5.1.3 Authentication Algorithms The security association specifies the authentication algorithm used for the ICV computation. At the time of writing, one mandatory-to-implement algorithm and mode has been defined for CIDF authentication header. It is based on the Hashed Message Authentication Codes using a SHA-1 hash value. The output of the HMAC computation is truncated to the leftmost 96 bits. 5.5.2 Inbound Message Processing Upon receipt of an CIDF message containing an CIDF authentication header, the CIDF message layer looks up the Security Association and verifies the Integrity Check Value. 5.5.2.1 Security Association Lookup The Security Association information is included in the CIDF authentication header. The CIDF message layer looks up the appropriate algorithm and key for ICV computation, based on the SPI and Key Generator's identity from the CIDF authentication header. If no valid algorithm and key exists for this message, the receiver MUST Kahn, Bolinger, Schnackenberg [Page 44] DRAFT Communication in CIDF 8 June 1998 discard the message. 5.5.2.2 Integrity Check Value Verification The receiver computes the ICV of the entire CIDF message using the specified authentication algorithm and the security association ICV key that has been established for this security association. If the computed ICV matches the ICV included in the Authentication Data field of the message, the CIDF message is valid and accepted. If the values do not match, the CIDF message layer MUST discard the CIDF message as invalid. To validate the CIDF message, the CIDF message layer saves the ICV value in the CIDF authentication header and replaces it with zeros. Then the CIDF message layer performs the ICV computation over the entire message and compares the saved ICV value with the computed ICV value. Kahn, Bolinger, Schnackenberg [Page 45]