Product Overview CommPower¼s Multi-Function Interpreter (MFI) is responsible for connecting various military grade X.400 message handling systems to other military legacy and commercial e-mail domains (i.e. JANAP/ACP128, ACP127, Simple Mail Transfer Protocol/Multi-purpose Internet Mail Extensions: SMTP/MIME, P2, P22, and P772). The U.S. Defense Message System (DMS) is one such program that has chosen CommPower¼s MFI to carry out its messaging gateway needs. The following table summarizes the translations that the MFI supports: Message Security Protocol (MSP) Version 3.0: This is the baseline security policy for Phase 1 of the U.S. DMS program. This security protocol is based on a U.S. pair-wise key scheme implemented using a PCMCIA based encryption engine and corresponding token known as the FORTEZZA card. Common Security Protocol (CSP), ACP120: This is the next generation security policy for Phase 2 of the U.S. DMS program, scheduled for release in late 2000. Whereas MSP 3.0 was geared toward U.S. operations, ACP120 is an approved international standard that is envisioned to be supported worldwide. For DMS operations, ACP120 within the MFI will be carried out using the FORTEZZA PCMCIA card. Generic „V3¾ Security API: This enhancement to the MFI will allow third party „V3¾ security mod- ules to be bolted onto the MFI thereby customizing the product to support a local security policy of choice. This API has been designed to accomodate the „V3¾ security toolkits offered by Van Dyke & Associates, Baltimore Technologies, RSA, and Entrust. The MFI is completely configurable as to the message formats and translations it supports. Addressing information within the MFI¼s local routing cache and optionally information derived from an ACP133 X.500 directory are used by the MFI to determine the translation/routing processing to be performed on each message. Upon receipt of an ACP123 X.400 message, the MFI performs the processing necessary to validate/remove any existing security envelope revealing the underlying P772 message content. All security processing performed is fully conformant to the standards/policies of the supported security protocol (i.e. MSP 3.0; ACP120: A detailed security description is provided later in this document). Once the security envelope has been validated and removed, the MFI performs address analysis to determine the final destination(s) of the message. Addressing of X.400 messages to other domains is accomplished primarily via the Domain Defined Attribute (DDA) in the MHS O/R Address. If this attribute is absent, the local routing cache (supplemented by an external X.500 directory) is used to locate the recipient address and obtain the „preferred mode of delivery¾ and associated destination address. Once a destination has been derived, the appropriate message format translation is performed. For traffic destined to the ACP123 network, native addressing schemes are used whereby addresses are translated to their X.400 counterpart using the MFI¼s internal routing cache supplemented by an optional X.500 directory. Following translation processing, the security policy of the receiving domain is applied before the message is transmitted. The security policies currently supported by the MFI allow for message signature, encryption, and signed receipts, each of which is handled in accordance with the authentication, non-repudiation, and privacy constraints of the underlying security policy. In addition to message gatewaying, the MFI supports legacy backside message switching for the JANAP/ACP128 and ACP127 communities. Individual, discrete I/O connections can be configured, each of which represents a single user or another legacy network. Routing Indicators (RIs), Plain Language Addresses (PLAs), and Address Indicator Groups (AIGs) defined within the MFI and/or the ACP133 X.500 directory are then used to determine if the received legacy messages are to be translated to another format or simply routed to another JANAP/ACP128/ACP127 legacy channel. The MFI¼s conceptual architecture is depicted in the figure below. (A detailed discussion of the architecture can be found in the following section.) The MFI incorporates an Integrated Directory User Agent (IDUA) to support the security policy, protocol/service mapping, and address resolution operations, an MTS access function that allows for the submission/delivery of messages to the MTS, a protocol/service conversion process that prepares the outgoing message(s), and a management agent responsible for remote component management and bulk transfer of the event log files. The MFI allows for multiple binds to different MTAs, each of which can support one or more X.400 MHS content types (e.g. P42/ACP120, P772, P2, P22). Product Description Product Architecture The MFI is designed using a highly modular and layered architecture, which is managed by a Secure Network Queue Manager (SNQM). The MFI consists of a P1 stack for connectivity into the X.400 MHS, an Integrated DUA (XDS) for connectivity to the Directory System Agents (DSAs), an MSP (or similar) package for the security, a Conversion Processor for the message format conversions, and an SNMP proxy agent for management by the Service Management Station (SMS). A detailed breakdown of the modular components of the MFI is provided in the following figure: The message flow inside the MFI is controlled by the SNQM. The SNQM manages inter-module communications and performs independent (mandatory enforced) object label checking of all data objects (i.e. messages) as the SNQM transfers the message information between the various MFI application software modules. The SNQM applies mandatory access control checking on all data objects. Since the SNQM manages all interfaces, it is not explicitly shown in the figure. The MFI provides for security label conversion and checks in the MSP (or other security policy) and JANAP/ACP128/ACP127. Relationship to Other Messaging Elements The MFI provides connectivity between ACP123 and AUTODIN, TARE, SMTP, and other ACP123 X.400 domains. In addition, the MFI also interfaces to the DMS X.500 Global Directory Services and the Service Management Station. This section describes these interfaces, which are also illustrated in the following figure. The MFI connection to legacy AUTODIN or TARE networks is done in one of three ways: Synchronous Mode I or Litsync protocol using an external communications interface device: The MFI sends message and control data to the external interface device using an RS232 connection. The interface accepts this data and transforms it into the appropriate synchronous line protocol. Mode II RS232 Asynchronous protocol: The MFI sends the ASCII message data to the receiving station using an RS232 connection. No protocol „handshaking¾ is performed. Message sequence numbers are used to ensure that traffic is not lost. External MFI API: The MFI supports an Application Programming Interface (API) whereby proprietary protocol modules can be written to exchange message data with the MFI. This interface has been used to interface the MFI with X.25, FTP, NFS, and non-standard networks/systems. The MFI connects to the SMTP mail environment using the sendmail daemon for UNIX systems and a POP3 server for NT systems. For efficient use of SMTP messaging, it is assumed that the MFI has access to the Domain Name Server (DNS). The MFI connects to both ACP123 and the other X.400 domains using a P1 stack for communications. The P1 stack is used to maximize the processing resources of the messaging system. By using P1 instead of P3, the MFI provides a much faster and efficient implementation. The MFI uses the grade of delivery element of service in the P1 envelope to obtain the priority specification of the message that would be carried in the P3 envelope. In an ACP123 system level architecture, the MFI is normally connected to a primary and secondary MTA. All X.400 traffic to/from the MFI will use the primary MTA. If the primary MTA fails, the MFI will route messages to the secondary MTA. The MFI accesses the ACP133 X.500 Directory Services Agent for querying directory information needed for the translations using the Directory Access Protocol (DAP). The MFI product uses the X/Open Directory Service API (XDS-API) to interface to the resident DAP, which in turn accesses the Directory System Agent (DSA). The DAP is based upon Remote Operations Service Element (ROSE) procedures executed over the upper layer OSI protocol stack. The XDS-API has the capability to support a pre-defined search/read/compare in the directory for any attribute(s) and any combination of attributes within an object class. The integrated XDS also has the capability to support an alternate DSA bind upon failure of the primary DSA. The integrated XDS uses the message priority for the directory priority. The MFI obtains the appropriate certificates from the DSA for each message address translated to/from the P42 message format. The MFI also comes with an SNMP proxy agent to allow for remote management from the Service Management Station (SMS). The agent will allow for configuration, fault, performance, and security management. The MFI creates log files, which are available to the SMS. Security The MFI interoperates with the Message Security Protocol (MSP) and Common Security Protocol (CSP) security functions to generate and verify originator signatures which, due to the nature of the pair-wise key architecture (i.e. Public Key Encryption technology), provide non-reputable identification of the originator (i.e. key material) which signs a given data object. The MSP/CSP used by the MFI makes two types of originator authentication: Data Origin Authentication and Non-Repudiation with Proof of Message Origin. Authentication is implemented in accordance with the Message Security Protocol specification as published in SDN.701 Revision 3.1 and ACP120 US Supp-1. In support of the required MSP/CSP security policy, the MFI supports up to 40 FORTEZZA interfaces (cards), all of which operate in parallel to provide optimum performance. The 40 cards allow the MFI to do the MSP/CSP processing on 40 different messages at once. The FORTEZZA card performs the decryption, encryption, and token generation and therefore is a key factor in performance/throughput of an MFI. The message security (sensitivity) label is carried inside the P42/ACP120 message header (i.e. part of Per Recipient Token) and is used by the encryption and decryption functions to prevent access to, or decryption of, message information when a given user or system does not hold sufficient credentials to see the message contents. Once the message is decrypted by the MFI, the security label, if present, is copied to the header of the internal MFI data object created to carry the message data. Functional Description MFI processing includes validation, authentication, and format/address conversion of an extensive set of message formats (see table on page 1). Interoperability is supported between the message domain of X.400 P42/ACP120 (P772 with MSP/CSP) and the following message domains: X.400 P2(1984), X.400 P22(1988), X.400 P772, SMTP with MIME, AUTODIN JANAP/ACP128, and TARE ACP127. The message format lines and the address types subject to address translation processing are as follows: JANAP/ACP128 & ACP127: Address Indicator Groups (AIGs) and Plain Language Addresses (PLAs) found in the header line, TO/INFO lines, TEAR Instructions, and Routing Indicators X.400: O/R addresses of the originator and intended recipients specified within the transfer envelope and the message content SMTP: All addresses contained within the From:, To:, CC:, and BCC: fields of the RFC822 message Constraints imposed by the recipients¼ domain such as message length for JANAP/ACP128 will be handled without loss of message data. Lengthy messages will be split into several messages and sent to the destination address. If recipient domain constraints exist such that a message cannot be converted, a non-delivery notification will be sent to the originator. For domains that do not specify message size constraints the MFI does not impose nor has a limit to the message size that it can process. Connectivity to the MFI is by individually configurable channels, each of which represents a single network association. The MFI is completely configurable with regard to outside connections. The MFI accepts the native message formats for each of the networks it interfaces with and stores the messages locally in a common object presentation format. Based upon the destination network(s), derived through message address translation processing, the MFI performs automatic format conversion thus permitting users of one message type to communicate with users of different message types. For each message type, a primary and alternate channel can be configured for maximum availability and throughput. The internal MFI routing files can be updated without interruption to the current message flow. Channel configuration and traffic controls such as traffic intercept and hold are available via the MFI operator interface. To ensure that messages are delivered in a timely manner, the MFI utilizes message precedence levels together with a FIFO servicing policy. This policy is carried out via a set of multi-precedence queues owned and managed by the SNQM. When a process (A) needs to send a message to another process (B), the sending process (A) instructs the SNQM to queue the message to a particular level of a specified queue. When process (B) is ready to process the next message of the highest precedence level, it dequeues the highest priority message in the queue. This multi- precedence queuing/dequeuing scheme ensures that messages of the highest priority are processed as quickly as possible. In addition, the JANAP/ACP128/ACP127 channels support message preemption to allow immediate transmission of flash/emergency messages. Error handling within the MFI is configurable and is based on the error type of the originating message network. Erred JANAP/ACP128/ACP127 messages can be rejected to the originator or placed on the MFI error queue for servicing at the MFI. Erred SMTP and X.400 messages can be rejected to the originator or passed to a designated SMTP/X.400 Postmaster. Message loop detection is the responsibility of the P1 stack; however, the MFI provides source/destination checking for detection and prevention of message looping (i.e. messages received from AUTODIN and routed back to AUTODIN). Upon receipt of a probe, the MFI will log the probe as an event and will not respond. An event log database is maintained within the MFI. This database contains audit trail data for faults, message processing, and operator actions. From this database, a variety of reports can be requested that give a tailored view of system activities. Currently supported reports are system activity, channel activity, chronological processing log, and message journal. The MFI supports report generation including a message transaction log, message journal log, and traffic statistics. These logs collectively record the messages that have been processed within a given time frame, and document the total number of message transactions that have been processed by the MFI since the last sampling time. The audit log that is maintained by the MFI relies upon the operating system for protection from unauthorized access, modification, or deletion. In support of legacy backside switching, the MFI includes capabilities for automatic service message handling for open sequence numbers and FLASH message receipt, local editing of erred messages, channel load balancing, message intercept for overload conditions, alarms/warnings for encountered situations, and 30-40 day long-term message storage. The MFI conforms to the protocols and formats defined in DSP AMHx1(D), AMHx2(D), AMH21(D), and AMH22(D); ISP¼s AMH11 and AMH21; MIL-STD-2045-17503; JANAP/ACP128; ACP127(G); ACP123 US Supplement; and Defense Communications Agency (DCA) DCS AUTODIN Interface and Control Criteria DCA Circular 370-D175-1; the Simple Mail Transfer Protocol Message Format Specification; and STANAG 4406 (with omissions).