CONCEPT OF OPERATIONS for the CommPower NT-Mail List Agent (NT-MLA) 23 August 2000 Prepared By: Communications & Power Engineering, Inc. 1040 Flynn Road Camarillo, CA 93012 1. INTRODUCTION 1 1.1. Purpose 1 1.2. Background 1 2. MLA PRODUCT DESCRIPTION 2 2.1. Product Overview 2 2.2. Product Description 3 2.2.1. Product Architecture 3 2.2.2. Relationship to Other Network Elements 4 2.2.3. Security 4 2.2.4. Functional Description 5 3. LIFE CYCLE SUPPORT 8 1. INTRODUCTION In response to the rapidly increasing need of the Government to apply cost- effective NT platforms for use in Defense Message System (DMS) applications, CommPower has ported its DMS certified HPUX MLA to the NT platform and is offering it for use within the DMS program. This document presents the Concept of Operations (CONOPS) for this CommPower NT-based Mail List Agent (MLA) product. 1.1. Purpose Presented herein are the general requirements and overall operations of the CommPower NT-based MLA product. Since this product is a complete port of the HPUX-based DMS MLA, all functionality provided by the HPUX version is also supported within the NT version. Further, since the bulk of the source code is common among the two platforms, enhancements made to either are carried over to the other. For the reasons cited above, all DMS baseline MLA documentation is directly applicable to the CommPower NT-based MLA. Differences between the HPUX and NT product versions are limited to installation and performance. 1.2. Background Within the X.400 standard, a distribution list function is provided that allows single addresses (Distribution Lists) to be expanded within the Message Transfer Agents (MTAs) resulting in delivery to potentially hundreds/thousands of individual recipients. Within DMS, however, this capability is not feasible without extensive customization of the MTAs due to the use of the Message Security Protocol (MSP). As such, a specialty product, known as the Mail List Agent (MLA) was introduced into the DMS suite of components, the purpose of which is to perform list expansion functions within the MSP environment. For the DMS core program, CommPower provides this MLA component on the required HPUX platform. This product has successfully undergone all DMS required certification testing and has been successfully fielded to over 600 installations. 2. MLA PRODUCT DESCRIPTION 2.1. Product Overview CommPower¼s Mail List Agent (MLA) is a software application responsible for the expansion of mail lists stored in the X.500 directory or the internal routing cache of the MLA. Its primary objective is to offload the per recipient token generation from the User Agent (UA) to a more powerful and dedicated process. The MLA also ensures that only authorized users send mail to a given Mail List (ML). To achieve this goal, the MLA only accepts delivery of „secured¾ messages with signatures (signed only, or signed and encrypted), which allows the MLA to verify the originator identity by checking his/her signature. For encrypted messages, the MLA generates the per recipient tokens. The MLA consults the X.500 Directory to learn the Originator/Recipient (O/R) Addresses of all the members of the ML being expanded. This directory is also used to support the Message Security Protocol (MSP) component during signature and token generation activities, including certificate information and key material validity verification against positive lists such as the certificate revocation list (CRL) and the compromised key list (CKL). The MLA¼s conceptual architecture is depicted in the figure below. (A detailed discussion of the architecture can be found in the following section.) The general architecture follows the US Supplement to ACP123 definition of a „specialized P3 user agent¾, incorporating a P1 stack offering a P1 interface to the associated Message Transfer Agent (MTA). The MLA utilizes an Integrated Directory User Agent (IDUA) to support the MSP/CSP and ML expansion operations, a Message Transfer (MT) access function that allows for the submission/delivery of messages to the Message Transfer System (MTS), an ML process that prepares the multiple-addressed outgoing message(s), and an optional management agent responsible for remote component management and bulk transfer of the event log files. Mail List Agent High-Level Architecture 2.2. Product Description 2.2.1. Product Architecture The MLA employs the same security architecture as its sister product, i.e. the Multi- Function Interpreter (MFI), allowing it to process sensitive data without compromise. It consists of a P1 stack for connectivity into the X.400 ACP123 Message Handling System (MHS), an Integrated DUA (XDS) for connectivity to the Directory System Agents (DSAs), an MSP package for the security, a Mail List Processor for the processing of the mail list (i.e. token generation and message creation), and an optional Simple Network Management Protocol (SNMP) proxy agent for management by the Service Management Station (SMS). The MLA is designed using a highly modular and layered architecture which is managed by a Secure Network Queue Manager (SNQM). The SNQM performs independent object label checking of all data objects (i.e. messages) as message information is transferred between the various MLA application software modules. 2.2.2. Relationship to Other Network Elements CommPower implements the MLA using a P1 stack to communicate with the X.400 world. The P1 stack is used to maximize the processing resources of the messaging system. By using P1 instead of P3, the MLA provides a much faster and efficient implementation of the required functions. The MLA 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. Another reason for choosing P1 is the X.400 standard allows for generation of Non-Delivery Notices (NDNs) at the P1 protocol level and not at the P3 level. If an MLA is implemented using P3, a non-standard method must be derived to handle NDNs. In the system level architecture the MLA is normally connected to a primary and secondary MTA. All X.400 traffic to/from the MLA will use the primary MTA. If the primary MTA fails, the MLA will route messages to an alternate MTA. The MLA product currently uses the X/Open Directory Service API (XDS-API) to interface to a resident Directory Access Protocol (DAP) which in turn accesses the remote Directory System Agent (DSA). The integrated XDS has the capability to perform 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 utilizes the message priority for the directory priority. The integrated XDS supports alternate DSA bind upon failure of the primary DSA. The MLA also comes with an optional SNMP proxy agent to allow for remote management for the Service Management Station (SMS). The agent will allow for configuration, fault, performance, and security management. The log files on the MLA are also available to the SMS. For Mail Lists that are stored in the directory, the SMS will use the Administrative Directory User Agent (ADUA) feature to modify them. 2.2.3. Security The MLA supports all applicable sender authentication requirements. The MSP used by the MLA makes two types of originator authentication: data origin authentication and non-repudiation with proof of message origin. _ Data Origin Authentication The Signed Contents Identifier (SCI) consists of the originator¼s Key Material ID (KMID), a Universal Time Code, a random number, and the associated signature value. When viewed together, the SCI provides a message tag with a non-reputable link to the originator of the SCI. This tag can be viewed as a unique identification number used to identify all data objects (messages) generated by a given message originator. _ Non-Repudiation with Proof of Message Origin The Signature Value (SV) is generated by the message originator on the basis of the message Hash Value (msgHash) which has previously been calculated like a sum of the original message contents. Due to the one-way nature of the Hash function, the identity of the message contents as well as the integrity of the message is verified as intact if the msgHash value compares after it has been received. If the signature value also compares, the recipient will have non-reputable proof that the claimed originator (originator identified in the Signature Block) is indeed the originator (i.e. signing identity) of a given message. These two types of authentication are implemented in accordance with the MSP specifications as published in SDN.701 Revision 3.1 and ACP120 US Supp-1. In support of the required security policy, the MLA supports up to 40 FORTEZZA interfaces (cards), all of which operate in parallel to provide optimum performance. This greatly increases the performance/throughput of the MLA over MLAs that support only one FORTEZZA interface (card) per single identity. The 40 cards allow the MLA to do the MSP processing on 40 different messages at once. The FORTEZZA card performs the decryption, encryption, and token generation and therefore is the key factor in performance/throughput of a MLA when processing MLs. User certificates are obtained from the DSA, cached into the internal MLA tables, utilized, and at a specified time interval (configurable) are discarded. The MLA uses the authorized user¼s attribute obtained from the DSA to verify that the originator has authorization to use the ML. The MLA product will process messages for MLs only if originated by authorized users as specified in the X.500 directory and verified with the digital signature. The MLA utilizes the MSP security functions to generate and verify originator signature, providing a non- reputable identification of the originator (i.e. key material) who signs a given data object. 2.2.4. Functional Description A DMS user sends a message to a mail list by addressing the message to a particular ML. If the message is encrypted, the ML¼s certificate is used for the encryption; not the MLA¼s certificate which supports that ML. The MLA receives messages from its P1 interfaces. Following reception, messages are processed to validate authentication of the originator¼s signature. For each applicable Mail List, the MLA verifies that the message originator is qualified to use the Mail List, and then expands the Mail List into its individual members. Resolution of the message Mail Lists is accomplished by using an Integrated DUA to access the X.500 Directory to expand MLs and obtain certificates of members. The MLA completes processing of the Mail List by generating a token for each member using the MSP security policy. The original token is used to generate the new tokens. For members whose address represents another Mail List, the MLA determines if it is responsible for that Mail List, and if so the Mail List is expanded. Otherwise, the Mail List remains unexpanded and is transmitted to the appropriate MLA for expansion. MLs that are processed by the MLA can be stored within the X.500 directory as well as the MLA. For Mail Lists that are stored within the MLA, the MLA allows the administrator to search, add, delete, and modify Mail Lists entries and members of MLs. For Mail Lists that are stored in the directory, an ADUA is used to modify them. Thus, the MLA supports the capability to have a Mail List whose composition is not in the directory. There is no artificial limit on the size of Mail Lists that can be handled by the MLA. However, an ML size of no more than 100 members is preferable for higher throughput. If a bigger ML is required, the use of nested mail lists is recommended. One MLA can support the number of ML identities that can be held on 40 FORTEZZA cards. The current estimates are 30 different identities per FORTEZZA card. To maximize the processing resources of the messaging system, the MLA provides submission to the MTS using the P1 protocol. By using P1 instead of P3, the MLA provides a much faster and efficient implementation of the required functions. To maximize message throughput and minimize operator intervention, the MLA provides management capabilities that include three levels of precedence. Each level is managed in a FIFO manner to permit messages of high importance to be delivered as fast as possible. The MLA uses the grade of delivery Element of Service in the P1 envelope, to obtain the priority of the message that would be carried in the P3 envelope. This precedence policy is carried out using a set of multi-precedence queues owned and managed by the MLA SNQM. This multi-precedence queuing/dequeuing scheme ensures that messages of the highest priority are processed as quickly as possible. An event log database is maintained within the MLA. 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 MLA 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 MLA since the last sampling time. The audit log that is maintained by the MLA relies upon the operating system for protection from unauthorized access, modification, or deletion. If an error encountered by the MLA is due to Mail List integrity or configuration errors, such as ML loop errors, the system administrator is notified. Detection and prevention of message looping is handled through the use of expansion history data. All other message processing errors result in the rejection of the message back to the originator. When a message addressed to an ML cannot be delivered to the MLA, the originator will receive a non-delivery notice (NDN). If a message cannot be delivered to a specific ML member, an NDN is sent back to the message originator for that erred member while still performing normal delivery processing for the other non-erred members. Received non- delivery notifications from the MTS for ML member delivery attempts result in non- delivery notification being passed to the designated MLA X.400 postmaster. NDNs for embedded MLs will be sent back to the originating ML¼s MLA, where the NDN will be passed to the designated postmaster. The MLA conforms with DSP AMH21(D), DSP AMHx1(D), DSP AMH22(D), DSP AMHx2(D), and P3 functionality. The MLA complies with the address list procedures contained in ACP123, Chapter 2, Section II, paragraph 207(k) and ACP123 Chapter 4, Section III, paragraph 437; and MLA procedures in ACP123 US Supplement. Mail List Agent Functional Data Flow 3. LIFE CYCLE SUPPORT All platforms supported by CommPower for a given product offer identical functionality. Thus, if DMS sponsors an enhancement to the HPUX version, the same enhancement will also be supported within the NT version. This functionality cross-over is further guaranteed by the fact that the core source code is common among all platforms. Further, all code development within CommPower has recently been converted to the NT platform (from UNIX platforms). Thus all product enhancements, whether desired for HPUX or NT, are performed and tested on the NT platform first and then ported to the HPUX platform. Hence, for all CommPower products, the NT versions exhibit the latest in functionality and are released before their HPUX counterparts. For the facts stated above, the NT MLA will be carried along by the DMS program whether or not DMS chooses to utilize them. This includes support for DMS R3.0, which is fully functional on both HPUX and NT platforms. Regarding software maintenance and help desk support, CommPower can work through Lockheed Martin or provide such services directly to the interested S/A. Installations within NATO-Europe will be supported by CommPower¼s technical support office in Dublin, Ireland. A non-secure, P772 version of the MLA does exist that bypasses all security functions. TABLE OF CONTENTS _______________________________________________________________________ CommPower NT-MLA i August 2000 CommPower NT-MLA CONOPS CommPower NT-MLA 3 August 2000