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 off load 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 using the external encryption engine associated with the security policy being used.1





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) or Common 


Security Protocol (CSP) 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 a management agent responsible for remote component management and bulk transfer of the event log files.


Product Description





Product Architecture





The MLA employs the same architecture as its sister product, i.e. the Multi-Function Interpreter (MFI).  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/CSP package for the security, a Mail List 


Processor for the processing of the mail list (i.e. token generation and message creation), and a Simple Network 


Management Protocol (SNMP) proxy agent for management by the Service Management Station (SMS). A detailed 


breakdown of the MLA components is provided in the following figure:


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.  The MLA interfaces 


to the MTA(s) through individually configurable/controllable channels, each of which represents a single P1 network 


association.  The MLA can be configured to support redundant channels to ensure maximum availability.





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





Security





The MLA supports all applicable sender authentication requirements.  The optional MSP/CSP 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/CSP specifications as published in 


SDN.701 Revision 3.1 and ACP120 US Supp-1.  In an effort to brung the MLA into other non-DMS markets, a 


generic "V3" security API is being added to the product.  This enhancement will allow third party "V3" security 


modules to be bolted onto the MLA 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 & Entrust.





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





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 non-exempted member using the MSP/CSP security policy.  The original token is used to generate the new 


tokens.  If exempt addressing is not applied, the MLA does not have to decrypt the message; rather, it just adds the 


new tokens to the message.  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 20-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 the error concerned 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 originating MLA.  Delivery 


errors or received non-delivery notifications from 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.   A non-secure, P772 version of the MLA does exist that bypasses all security functions.