DEFENSE INFORMATION SYSTEMS AGENCY P. O. BOX 549 FORT MEADE, MARYLAND Joint Interoperability Test Command (JTE) 18 Jun 14

Transcription

1 DEFENSE INFOMAION SYSEMS AGENCY P. O. BOX 549 FO MEADE, MAYLAND IN EPLY EFE O: Joint Interoperability est Command (JE) 18 Jun 14 MEMOANDUM FO DISIBUION SUBJEC: Joint Interoperability Certification of the Cisco Unified Presence Server (CUPS) with Cisco Jabber eferences: (a) Department of Defense Instruction , "DoD Unified Capabilities (UC)," 9 December 2010 (b) DoD CIO, Memorandum, "Interim Guidance for Interoperability of Information echnology (I) and National Security Systems (NSS)," 27 March 2012 (c) through (f), see Enclosure 1 1. Certification Authority. eferences (a) and (b) establish the Joint Interoperability est Command (JIC) as the Joint Interoperability Certification Authority for the UC products. 2. Conditions of Certification. he CUPS with Cisco Jabber 9.2.6; hereinafter referred to as the System Under est (SU), meets the critical requirements of the Unified Capabilities Extensible Messaging and Presence Protocol () equirements and the Unified Capabilities equirements (UC), eferences (c) and (d), and is certified for joint use as a Client/Server with the conditions described in able 1. his certification expires upon changes that affect interoperability, but no later than three years from the date of the UC Approved Products List (APL) memorandum. able 1. Conditions Condition UC Waivers he SU does not support IPv6. he Office of the Secretary of Defense (OSD) granted a waiver for IPv6 on 16 May None. Conditions of Fielding Open est Discrepancies he SU does not correctly respond to stream errors. Instead of responding with a stream error immediately and closing the stream, the SU terminates the connection non-gracefully. he SU does not generate a new Client-to-Server stream. he SU reuses the old stream instead. Operational Impact Minor emarks Minor See note 1. Minor See note 1. he SU does not include empty <required/> element in its advertisement of the SASL. Minor See note 1. he SU does not fully comply with SASL failure requirements. he SU meets SASL error conditions outlined in FC 3920 and not FC he SU does not allow a configurable number of retries. Minor See note 1.

2 JIC Memo, JE, Joint Interoperability Certification of the Cisco Unified Presence Server (CUPS) with Cisco Jabber able 1. Conditions (continued) Condition he SU does not fully meet the Deleting a oster Item requirement. Presence stanza of type unsubscribe is not sent to contact. Instead, the stanza is silently dropped. he SU partially complies with ules for Server Processing of Outbound Subscription equests. he SU partially complies to ules for Server Processing of Outbound Subscription Cancellation. Upon receiving the outbound subscription cancellation, the contact's server does not send a presence stanza of type unavailable from all of the contacts online resources to the user. he SU partially complies with ules for Server Processing of Inbound Unsubscribe. he SU doesn t check if the user is in the contact s roster with subscription= from or subscription= both. Operational Impact emarks Minor See note 1. Minor See note 1. Minor See note 2. Minor See note 2. he SU does not comply with Server Generation of Outbound Presence Probe. Minor See note 1. he SU establishes SASL external authentication with incorrect domain. Minor See note 2. he SU does not comply with the requirements in Extension XEP-0045: Multi-User Chat. Minor See note 1. NOES: 1. DISA has accepted and approved the vendor s POA&M and adjudicated this discrepancy as having a minor operational impact. 2. DISA adjudicated this discrepancy as minor and stated the intent to change this requirement. LEGEND: DISA Defense Information Systems Agency IPv6 Internet Protocol version 6 FC equest for Comments POA&M Plan of Action & Milestones SASL SU UC Simple Authentication and Security Layer System Under est Unified Capabilities equirements Extensible Messaging and Presence Protocol 3. Interoperability Status. able 2 provides the SU interface interoperability status and able 3 provides the Capability equirements (C) and Functional equirements (F) status. able 4 provides the UC APL product summary. able 2. SU Interface Status Interface (See note 1.) hreshold C/F equirements (See note 2.) Status emarks Network Management Interfaces IEEE 802.3i (10Base UP) (C) 1 Met See note 3. IEEE 802.3u (100Base UP) (C) 1 Met See note 3. IEEE 802.3ab (1000BaseX) (C) 1 Met See note 3. Server Network Interfaces IEEE 802.3i (10Base UP) (C) 1, 2, 3 Partially Met See note 3. IEEE 802.3u (100Base UP) (C) 1, 2, 3 Partially Met See note 3. IEEE 802.3ab (1000BaseX) (C) 1, 2, 3 Partially Met See note 3. Client Interfaces IEEE 802.3i (10Base UP) (C) 1, 2, 3 Partially Met See note 3. IEEE 802.3u (100Base UP) (C) 1, 2, 3 Partially Met See note 3. IEEE 802.3ab (1000BaseX) (C) 1, 2, 3 Partially Met See note 3. NOES: 1. eferences (c) and (d) do not specify a minimum required Ethernet interface, therefore, any one of the listed interfaces can be supported. 2. he SU high-level C and F ID numbers depicted in the hreshold Cs/Fs column can be cross-referenced in able 3. hese highlevel C/F requirements refer to a detailed list of requirements provided in Enclosure he SU does not support IPv6. he Office of the Secretary of Defense (OSD) granted a waiver for IPv6 on 16 May

3 JIC Memo, JE, Joint Interoperability Certification of the Cisco Unified Presence Server (CUPS) with Cisco Jabber able 2. SU Interface Status (continued) LEGEND: 802.3ab 1000Base Gbps Ethernet over twisted pair at 1 Gbps (125 Mbps) 802.3i 10Base Mbps over twisted pair 802.3u Standard for 100 Mbps Ethernet C Conditional C Capability equirement F Functional equirement ID Identification IEEE Institute of Electrical and Electronics Engineers IPv6 Internet Protocol version 6 SU System Under est UP Unshielded wisted Pair C/F ID able 3. SU Capability equirements and Functional equirements Status and UC equirements (High-Level) (See note 1.) UC eference (See note 2.) Status 1 XML Streams 2.6 Partially Met (See note 3.) 2 LS and SALS Negotiation 2.7 Met (See note 4.) 3 Authentication and SASL Negotiation 2.8 Partially Met (See note 3.) 4 esource Binding 2.9 Met 5 XML Stanzas 2.10 Met 6 oster Management 2.11 Met 7 Presence Subscription Management 2.12 Partially Met 8 Exchanging Presence Information 2.13 Partially Met 9 Exchanging Messaging 2.14 Met 10 Conformance equirements in FC 6120 and FC Partially Met (See note 3.) 11 Extensions 2.16 Not Met. (See note 3.) 12 XML Usage 2.17 Met 13 DIFFSEV Code Point (DSCP) equirements 2.18 Met 14 IPv6 UC 2013, Section 5 Not Met. (See note 3.) NOES: 1. he annotation of required refers to a high-level requirement category. he applicability of each sub-requirement is provided in Enclosure All requirements are derived from eference (c) except for IPv6, which is derived from eference (d). 3. he SU met the requirements for an Client/Server with the exceptions noted in able 1. DISA adjudicated these exceptions as minor. 4. Security testing is accomplished by DISA-led Information Assurance test teams and the results are published in a separate report, eference (f). LEGEND: C Conditional OSD Office of the Secretary of Defense C Capability equirement POAM Plan of Action & Milestones DIFFSEV Differentiated Server SASL Simple Authentication and Security Layer DISA Defense Information Systems Agency SU System Under est F Functional equirement LS ransport Layer Security ID Identification UC Unified Capabilities equirements IM Instant Messaging VVoIP Voice and Video over Internet Protocol IPv6 Internet Protocol version 6 Extensible Messaging and Presence Protocol XML Extensible Markup Language 3

4 JIC Memo, JE, Joint Interoperability Certification of the Cisco Unified Presence Server (CUPS) with Cisco Jabber able 4. UC APL Product Summary Product Identification Product Name Cisco Unified Presence Server (CUPS) with Cisco Jabber Software elease Cisco Unified Presence Server (CUPS) with Cisco Jabber UC Product ype(s) Product Description Cisco Unified Presence Server and Cisco Jabber is an Server and Client solution. Product Components (See note 1.) Component Name (See note 2.) Version emarks Cisco Unified Presence Server (Presence/IM/Chat) Client Unified Communications Manager Cisco Unified Computing Systems with ESXi 5.1 UCS-B200-M1, UCS-B200-M2. (See note 3.) Cisco Jabber for Windows UCS C210-M2 (with VMware), UCS-C210-M1, and UCS-C2000M2. (See note 3.) Cisco Unified Presence Server (CUPS) Jabber Windows IM/P Server to facilitate exchange of Instant Messages (IM). IM/P and VVoIP IM Compliancy Server External database for PostgreSQL (site provided) compliancy logging. Common Access Card/Single signon solution OpenAM NOES: 1. he detailed component and subcomponent list is provided in Enclosure Components bolded and underlined were tested by JIC. he other components in the family series were not tested but are also certified for joint use. JIC certifies those additional components because they utilize the same software and similar hardware and JIC analysis determined them to be functionally identical for interoperability certification purposes. 3. A comprehensive list of supported hardware configurations can be found by selecting the "Cisco Unified Communications on the Cisco Unified Computing System" link at the following UL: LEGEND: APL IM/P JIC Approved Products List Instant Messaging/Presence Joint Interoperability est Command UC VVoIP Unified Capabilities Voice and Video over Internet Protocol Extensible Messaging and Presence Protocol 4. est Details. his finding is based on interoperability testing, review of the vendor's Letters of Compliance (LoC), DISA adjudication of open test discrepancy reports (Ds), and DISA Certifying Authority (CA) ecommendation for inclusion on the UC APL. esting was conducted at JIC's Global Information Grid Network est Facility at Fort Huachuca, Arizona, from 26 August 2013 through 6 September 2013 using equirements derived from reference (c) test procedures derived from eference (e). Patches were applied and regression testing was conducted on 19 and 20 November eview of the vendor's LoC was completed on 5 September DISA adjudication of outstanding Ds was completed on 10 December Information Assurance (IA) testing was conducted by DISA-led IA test teams and the results are published in a separate report, eference (f). Enclosure 2 documents the test results and describes the tested network and system configurations. Enclosure 3 provides a detailed list of the interface, capability, and functional requirements. 5. Additional Information. JIC distributes interoperability information via the JIC Electronic eport Distribution (ED) system, which uses Sensitive but Unclassified IP Data (formerly known as NIPNet) . Interoperability status information is available via the JIC System racking Program (SP). SP is accessible by.mil/.gov users at est reports, lessons learned, and related testing documents and references are on the JIC Joint Interoperability ool (JI) at Due to the sensitivity of the information, the Information Assurance Accreditation Package (IAAP) that contains the approved configuration and deployment guide must be requested directly from the Unified Capabilities Certification Office (UCCO), disa.meade.ns.list.unified- 4

5 JIC Memo, JE, Joint Interoperability Certification of the Cisco Unified Presence Server (CUPS) with Cisco Jabber All associated information is available on the DISA UCCO website located at 6. Point of Contact (POC). he JIC point of contact is Mr. Edward Mellon, commercial telephone (520) , DSN telephone , FAX DSN ; address mailing address Joint Interoperability est Command, AN: JE (Mr. Edward Mellon) P.O. Box 12798, Fort Huachuca, AZ he UCCO tracking number for the SU is FO HE COMMANDE: 3 Enclosures a/s for IC HAISON Chief Networks/Communications and UC Portfolio Distribution (electronic mail): DoD CIO Joint Staff J-6, JCS USD(A&L) ISG Secretariat, DISA, JA U.S. Strategic Command, J665 US Navy, OPNAV N2/N6FP12 US Army, DA-OSA, CIO/G-6 ASA(AL), SAIS-IOQ US Air Force, A3CNN/A6CNN US Marine Corps, MACOSYSCOM, SIA, A&CE Division US Coast Guard, CG-64 DISA/EMC DIA, Office of the Acquisition Executive NSG Interoperability Assessment eam DO&E, Netcentric Systems and Naval Warfare Medical Health Systems, JMIS IV&V HQUSAISEC, AMSEL-IE-IS UCCO 5

6 ADDIIONAL EFEENCES (c) Office of the Department of Defense Chief Information Officer, Department of Defense Unified Capabilities (UC) Extensible Messaging and Presence Protocol () 2013 (UC 2013), January 2013 (d) Office of the Department of Defense Chief Information Officer, Department of Defense Unified Capabilities equirements 2013, 1 March 2013 (e) Joint Interoperability est Command, Extensible Messaging and Presence Protocol () est Procedures for Unified Capabilities equirements (UC) 2013, Draft (f) Joint Interoperability est Command, "Information Assurance (IA) Findings Summary for Cisco Unified Presence Server (CUPS)/Jabber for Windows CUPS 8.6.5/Jabber racking Number , Draft Enclosure 1

7 CEIFICAION SUMMAY 1. SYSEM AND EQUIEMENS IDENIFICAION. he Cisco Unified Presence Server (CUPS) with Cisco Jabber able 2-1 depicts the SU identifying information and requirements source. able 2-1. System and equirements Identification System Identification Sponsor Sponsor Point of Contact Vendor Point of Contact Headquarters United States Army Information Systems Engineering Command (HQUSAISEC) Mr. obert H. Adkins, USAISEC ELIE-ISE-ES, Building 53301, Fort Huachuca, Arizona 85613, Cisco Systems Global Certification eam (GC), Kit Creek oad, esearch riangle Park, North Carolina 27709, System Name Cisco Unified Presence Server with Cisco Jabber Increment and/or Version 8.6.5/9.2.6 Product Category System Background racking Previous certifications UCCO ID System racking Program ID 4756 equirements Source Client/Server No previous certifications Unified Capabilities equirements Unified Capabilities 2013, UC 2013 emarks est Organization(s) LEGEND: ID Identification UCCO Unified Capabilities Connection Office Joint Interoperability est Command, Fort Huachuca, Arizona Extensible Messaging and Presence Protocol 2. SYSEM DESCIPION. he SU is an Extensible Messaging and Presence Protocol () Server and Client solution. he SU is a distributed solution that connects to an Assured Services Local Area Network (ASLAN). CUPS is a highly redundant solution, which can consist of multiple sub-clusters each with up to six nodes. Cisco Jabber 9.2 provides the user with an Instant Messaging (IM) client. As an optional site add-on, a PostgreSQL 9.1 server running on HEL 5 is deployed as equired Ancillary Equipment (AE) to meet the IM compliancy logging and persistent chat requirements. CUPS requires Cisco Unified Communications Manager (UCM) as part of the solution. he SU includes the following components. Cisco Unified Presence Server (CUPS). CUPS provides the server to facilitate the exchange of Instant Messages. CUPS is installed as a virtual appliance on the Cisco Unified Computing System (UCS) running ESXi 5.1. Cisco Jabber. Cisco Jabber provides the client. Cisco Jabber is installed on a Security echnical Implementation Guideline (SIG)-compliant Windows based workstation and provides the ability to send and receive IMs. Enclosure 2

8 Cisco Unified Communications Manager (UCM). he SU includes one UCM server for the CUPS/Jabber client to register. PostgreSQL. PostgreSQL provides the external database for compliancy logging and persistent chat. Access to the database is done via PostgreSQL Admin tool installed on the management workstation. OpenAM. OpenAM provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security component in a network infrastructure. OpenAM provides the foundation for integrating diverse web applications that might typically operate against a disparate set of identity repositories and are hosted on a variety of platforms such as web and application servers. Management Description: Cisco Unified Presence Server primary management interface is a web-based administrative console; additionally it can also be accessed via Command Line Interface (CLI). o access it, an auditor or administrative user will connect via Common Access Card (CAC) for authentication from a SIG compliant management workstation. Once connected, they would establish a management session to the Cisco Unified Presence Server management interfaces. he Cisco Unified eal-ime Monitoring ool (M), which runs as a client-side application, connects over Hypertext ransfer Protocol Secure (HPS) to the CUPS appliance and is used for monitoring performance, and access to the system logs. his tool does not provide a means to modify the configuration or security of the appliance. 3. OPEAIONAL ACHIECUE. he Unified Capabilities (UC) architecture is a twolevel network hierarchy consisting of Defense Information Systems Network (DISN) backbone switches and Service/Agency installation switches. he Department of Defense (DoD) Chief Information Officer (CIO) and Joint Staff policy and subscriber mission requirements determine which type of switch can be used at a particular location. he UC architecture, therefore, consists of several categories of switches. Figure 2-1 depicts the notional operational UC architecture in which the SU may be used. 4. ES CONFIGUAION. he test team tested the SU at JIC, Fort Huachuca, Arizona in a manner and configuration similar to that of a notional operational environment. esting of the system s required functions and features was conducted using the test configuration depicted in Figure 2-2. Information Assurance (IA) testing used the same configuration. 5. MEHODOLOGY. esting was conducted using requirements derived from the Unified Capabilities equirements and the Unified Capabilities equirements (UC), eferences (c) and (d), and test procedures, eference (e). Any discrepancies noted were written up in est Discrepancy eports (Ds). he vendor submitted Plan of Action and Milestones (POA&M) as required. he remaining open Ds were adjudicated by DISA as Minor. Any new discrepancy noted in the operational environment will be evaluated for impact on the existing certification. hese discrepancies will be adjudicated to the satisfaction of DISA via a vendor POA&M, which will address all new critical Ds within 120 days of identification. 2-2

9 LEGEND: DCO Defense Connection Online DISA Defense Information Systems Agency DISN Defense Information Systems Network DoD Department of Defense EI End Instrument IAP Integrated Access Point IM Instant Messaging IP Internet Protocol ISP Internet Service Provider LAN Local Area Network MCEP Multi-Carrier Entry Point NEOPS PKI PSN QoS SBC SC SS UC VVoIP Network Operations Public Key Infrastructure Public Switched elephone Network Quality of Service Session Border Controller Session Controller Softswitch Unified Capabilities Voice and Video over IP Extensible Messaging and Presence Protocol Figure 2-1. Notional UC Network Architecture 2-3

10 LEGEND: ASLAN CUPS Mbps SU Assured Services Local Area Network Cisco Unified Presence Server Megabits per second System Under est UC UCM WAN Unified Capabilities Unified Communications Manager Wide Area Network Figure 2-2. SU est Configuration 6. INEOPEABILIY EQUIEMENS, ESULS, AND ANALYSIS. he Capability equirements (C), Functional equirements (F), and other requirements for UC are established by DoD UC 2013, sections 2.6 through a. Interfaces. able 3-1 provides the SU interfaces and their testing status. here are no minimum interface requirements for an client/server system, which traverses an established Local Area Network (LAN). he SU client and server were tested and met the requirements over a 10/100/1000 Megabits per second (Mbps) LAN. he UC specification also does not define minimum network management requirements for an Client/Server product. he SU management requirements were successfully tested over a 10/100/1000 Mbps LAN. b. Capability and Functional equirements and Status (1) he DoD UC 2013, section 2.6, states that an Extensible Markup Language (XML) stream provides the fundamental transport needed for all client-to-server and server-toserver communications. he ability to establish and maintain an XML stream is an essential capability of. he high-level XML stream requirements are included in the subparagraphs below. 2-4

11 (a) ransport Control Protocol (CP) Binding. An initiating entity SHALL open a CP connection to the receiving entity before it negotiates XML streams with the receiving entity. he parties then maintain that CP connection for as long as the XML streams are in use. he SU met this requirement with the vendor s Letter of Compliance (LoC). (b) Stream Features 1. he initiating entity SHALL initiate an XML stream by sending an initial stream header to the receiving entity. he SU met this requirement with the vendor s LoC. 2. In response, the receiving entity SHALL send a response stream header to the initiating entity. he SU met this requirement with the vendor s LoC. 3. After the receiving entity has sent a response stream header to the initiating entity, the receiving entity SHALL send a <features/> child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any conditions for continuation of the stream negotiation process. Each condition takes the form of a child element of the <features/> element, qualified by a namespace that is different from the streams namespace and the content namespace. he <features/> element can contain one child, contain multiple children, or be empty. he initiating entity SHALL be capable of handling a <features/> element that contains one child or contains multiple children or that is empty. he SU met this requirement with the vendor s LoC. 4. For stream features that are mandatory-to-negotiate, the definition of that feature SHALL declare that the feature is always mandatory-to-negotiate (e.g., this is true of resource binding for clients) or the receiving entity SHALL explicitly flag the feature as mandatory-tonegotiate (e.g., this is done for ransport Layer Security (LS) by including an empty <required/> element in the advertisement for the SALS feature). he SU met this requirement with the vendor s LoC. 5. If the <features/> element contains at least one mandatory feature, then the initiating entity SHALL continue with the stream negotiation process. An empty <features/> element indicates that the stream negotiation is complete and that the initiating entity is cleared to send XML stanzas. he SU met this requirement with the vendor s LoC. (c) Stream estarts. On successful negotiation of a feature that necessitates a stream restart, both the initiating entity and the receiving entity SHALL consider the previous stream to be replaced, but SHALL NO terminate the underlying CP connection; instead, the initiating entity and the receiving entity SHALL reuse the existing connection. he initiating entity then SHALL send a new initial stream header to the receiving entity. When the receiving entity receives the new initial stream header, it SHALL generate a new stream ID (instead of reusing the old stream ID) and SHALL then send a new response stream header to the initiating entity. he SU met these requirements with the vendor s LoC. (d) Continuation and Completion of Stream Negotiation. he receiving entity SHALL send an updated list of stream features to the initiating entity after a stream restart. he 2-5

12 receiving entity SHALL indicate completion of the stream negotiation process by sending to the initiating entity either an empty <features/> element or a <features/> element that contains only voluntary features. Once stream negotiation is complete, the initiating entity is cleared to send XML stanzas over the stream for as long as the stream is maintained by both parties. he SU met these requirements with the vendor s LoC. (e) Directionality. For client-to-server sessions, a server SHALL allow a client to use "two streams over a single CP connection. For server-to-server sessions, the two server peers SHALL use two streams over two CP connections, where one CP connection is used for the stream in which stanzas are sent from the initiating entity to the receiving entity and the other CP connection is used for the stream in which stanzas are sent from the receiving entity to the initiating entity. he SU met these requirements with the vendor s LoC. (f) Closing a Stream. Client and server implementations SHALL be capable of closing an XML stream by sending a closing </stream> tag. After the entity that sent the first closing stream tag receives a reciprocal closing stream tag from the other party, it SHALL terminate the underlying CP connection or connections. he SU met these requirements with the vendor s LoC. (g) Stream Attributes 1. Initial Streams. For client-to-server connections, it is assumed that the client knows the associated account name of the form <localpart@domain>. he client SHALL include the from attribute in the initial stream header it sends to the server and SHALL set the value to the associated account name of the form <localpart@domain>. For server-to-server connections, the initiating entity SHALL include the from attribute in the initial stream header it sends to the receiving entity and SHALL set its value to a hostname serviced by the initiating entity. For both client-to-server and server-to-server connections, the initiating entity SHALL include the to attribute in the initial stream header that it sends to the receiving entity and SHALL set its value to a hostname that the initiating entity knows or expects the receiving entity to service. For both client-to-server and server-to-server connections, the initiating entity SHALL include a version attribute whose value is 1.0 (or higher) in the initial stream headers it generates. he SU met these requirements with the vendor s LoC. 2. esponse Streams. For both client-to-server and server-to-server connections, the receiving entity SHALL include the "from" attribute in the response stream header that it sends to the initiating entity and SHALL set its value to a hostname serviced by the receiving entity. For response stream headers in client-to-server communication, if the client included a "from" attribute in the initial stream header then the server SHALL include a "to" attribute in the response stream header and SHALL set its value to the bare JID specified in the "from" attribute of the initial stream header. If the client did not include a "from" attribute in the initial stream header then the server SHALL NO include a "to" attribute in the response stream header. For server-to-server connections, the receiving entity SHALL include the "to" attribute in the response stream header that it sends to the initiating entity and SHALL set its value to the hostname specified in the "from" attribute of the initial stream header. For both client-to-server and server-to-server connections, the receiving entity SHALL include an "id" attribute in the response stream header that it sends to the initiating entity. he "id" attribute communicates a unique 2-6

13 identifier for the stream, called a SEAM ID. he stream "id" shall have the property of randomness. For both client-to-server and server-to-server connections, the receiving entity SHALL include a "version" attribute where the value is 1.0 (or higher) in the response stream headers it sends to the initiating entity. he SU met these requirements with the vendor s LoC. (h) Namespaces 1. Streams Namespace. Client and server implementations SHALL qualify the root <stream/> element ("stream header") by the namespace " (the "streams namespace"). If this rule is violated, the entity that receives the offending stream header SHALL return a stream error to the sending entity, which SHALL be either <invalid-namespace/> or <bad-format/>. he SU met this requirement with the vendor s LoC. 2. Content Namespace. An entity (client or server) SHALL declare a content namespace for data sent over the stream. he content namespace SHALL be the same for the initial stream and the response stream so that both streams are qualified consistently. he content namespace applies to all first-level child elements sent over the stream unless explicitly qualified by another namespace. he defines two content namespaces: "jabber:client" and "jabber:server." Client implementations SHALL support the jabber:client content namespace. Server implementations SHALL support both the jabber: client content namespace (when the stream is used for communication between a client and a server) and the jabber:server content namespace (when the stream is used for communication between two servers). If an entity receives a first-level child element qualified by a content namespace it does not support, it SHALL return an <invalid-namespace/> stream error. (i) Stream Errors. he error child SHALL be sent by an entity (client or server) if it perceives that a stream-level error has occurred. Stream-level errors are unrecoverable. herefore, if an error occurs at the level of the stream, the entity (client or server) that detects the error SHALL send an <error/> element with an appropriate child element that specifies the error condition and at the same time send a closing </stream> tag. he entity that generates the stream error then SHALL close the stream as explained under Section 4.4 of equest for Comments (FC) If the error is triggered by the initial stream header, the receiving entity SHALL still send the opening <stream> tag, include the <error/> element as a child of the stream element, and then send the closing </stream> tag (preferably all at the same time). he SU met this requirement with the vendor s LoC with the following minor exception. he SU does not correctly respond to stream errors. Instead of responding with a stream error immediately and closing the stream, the SU terminates the connection non-gracefully. DISA has accepted and approved the vendor s POA&M and adjudicated this discrepancy as having a minor operational impact. (2) he DoD UC 2013, section 2.7, states that all XML streams (i.e., including both client-to-server and server-to-server connections) SHALL be secure with the use of the LS protocol. he SU met this requirement with the vendor s LoC. he high-level LS and SALS Negotiation requirements are included in the subparagraphs below. 2-7

14 (a) SALS Process. he use of the SALS command to initiate LS negotiation is mandated. All client and server implementations SHALL support and use the SALS extension. Immediately after the opening of the response stream, the receiving entity SHALL initiate the process of stream negotiation. In the stream feature announcement provided by the receiving entity during the initial stage of the stream negotiation process, the receiving entity SHALL advertize ONLY the SALS feature (qualified by the XML namespace: urn:ietf:params:xml:ns:xmpp-tls ) and SHALL also include an empty <required/> child element. he SU met these requirements with the vendor s LoC. (b) Initiation of SALS Negotiation. In order to begin the SALS negotiation, the initiating entity SHALL issue the SALS command (i.e., a <starttls/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the receiving entity that it wishes to begin a SALS negotiation to secure the stream. he receiving entity SHALL reply with a <proceed/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. he SU met these requirements with the vendor s LoC. (c) SALS Negotiation Fails. If there is a failure of SALS negotiations, the receiving entity SHALL return a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace and SHALL close the XML stream. he SU met this requirement with the vendor s LoC. (d) LS Negotiation. After the receiving entity has sent and the initiating entity has received the <proceed/> element, the initiating and receiving entities SHALL proceed to LS negotiation. he LS negotiation and implementation SHALL be in accordance with all applicable DoD Security echnical Implementation Guideline (SIG) requirements [including DoD Public Key Infrastructure (PKI) compliance] and LS/PKI implementation/interoperability requirements as defined in Unified Capabilities equirements (UC) 2013, Section 4, Information Assurance. he SU met this requirement with testing and the vendor s LoC. In addition, security testing is accomplished via DISA-led Information Assurance test teams and the results published in a separate report, eference (f). (e) LS Success. If the LS negotiation is successful, then the initiating and receiving entities SHALL proceed as in the following subparagraphs. he SU met these requirements with testing. 1. he initiating entity SHALL send a new initial stream header to the receiving entity over the encrypted connection. he initiating entity SHALL NO send a closing </stream> tag before sending the new initial stream header, since the receiving entity and initiating entity MUS consider the original stream to be replaced upon success of the LS negotiation. 2. he receiving entity SHALL respond with a new response stream header over the encrypted connection. In this new response stream header, the receiving entity SHALL generate a new stream ID instead of reusing the old stream ID. 2-8

15 3. he receiving entity also SHALL send stream features to the initiating entity, which SHALL NO include the SALS feature, but which SHALL advertise support of Simple Authentication and Security Layer (SASL) negotiation as described in Section 2.8, Authentication and SASL Negotiation. (f) LS Failure. If the LS negotiation results in failure, the receiving entity SHALL terminate the CP connection. he SU met this requirement with testing. (g) Order of LS and SASL Negotiation. Client and server implementations SHALL complete SALS negotiation before proceeding to SASL protocol negotiation; this order of negotiation is necessary to help safeguard authentication information sent during SASL negotiation, as well as to make it possible to base the use of the SASL EXENAL mechanism on a certificate provided during prior LS negotiation (for entities who authenticate using a DoD PKI certificate). he SU met this requirement with the vendor s LoC. (h) SALS Failure Case. If the SALS negotiation fails, the receiving entity SHALL return a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace, terminate the XML stream, and terminate the underlying CP connection. he SU met this requirement with the vendor s LoC. (3) he DoD UC 2013, section 2.8, states that all client and server implementations SHALL support SASL negotiations. he entities involved in an XML stream SHALL consider SASL as mandatory-to-negotiate. Anonymous login capability is prohibited. he high-level Authentication and SASL Negotiation requirements are included in the subparagraphs below. he SU met these requirements with the vendor s LoC with any exceptions noted. (a) Client-to-Server Streams 1. During the prior LS negotiation, the server SHALL authenticate using a DoD PKI certificate. he client SHALL validate the certificate presented by the server. 2. he client SHALL authenticate using name and password using the SASL PLAIN mechanism (FC 4616) as defined in the following text. As defined by this specification, the SASL PLAIN mechanism SHALL only be used when the underlying XML stream is protected using LS. Client authentication using name and password is a minimum requirement. Client authentication using a Department of Defense (DoD) Public Key Infrastructure (PKI) certificate is preferred. he client in this scenario would comply with the behavior defined for the initiating entity in Section 2.8.2, Server-to-Server Streams. 3. After successful SALS negotiation, the server SHALL offer the SASL PLAIN mechanism to the client during SASL negotiation. he <mechanisms/> element SHALL be qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. he <mechanisms/> element SHALL contain one <mechanism/> child element including the appropriate value for the PLAIN mechanism. 2-9

16 4. he client SHALL select the PLAIN authentication mechanism by sending an <auth/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and which SHALL include the appropriate value for the PLAIN mechanism attribute. 5. Upon receipt of the message, the server will verify the presented authentication identity and password by performing a directory lookup to a directory service linked to the server for authenticating the user. 6. All users SHALL be linked to a directory service, which is linked to the user s home server. 7. he server SHALL report the success of the handshake by sending a <success/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. 8. After successful SASL negotiation, the client and server SHALL restart the stream. Upon receiving the <success/> element, the client SHALL initiate a new stream over the existing LS connection by sending a new initial stream header to the server. he client SHALL NO send a closing </stream> tag before sending the new initial stream header, since the server and client MUS consider the original stream to be replaced upon sending or receiving the <success/> element. 9. Upon receiving the new initial stream header from the client, the server SHALL respond by sending a new response stream header to the client (for which it SHALL generate a new stream ID instead of re-using the old stream ID). he SU does not generate a new Client-to-Server stream. he SU reuses the old stream instead. DISA has accepted and approved the vendor s POA&M and adjudicated this discrepancy as having a minor operational impact. 10. he server SHALL also send stream features, containing any further available features or containing no features (via an empty <features/> element). (b) Server-to-Server Streams 1. During the prior LS negotiation, the initiating entity and the receiving entity SHALL mutually authenticate using DoD PKI certificates. Server-to-server mutual authentication SHALL be in accordance with all applicable DoD SIG requirements (including DoD PKI compliance) and LS/PKI implementation/interoperability requirements as defined in UC 2013, Section 4, Information Assurance. 2. After the successful mutual authentication of the receiving entity and the initiating entity during the prior LS negotiation, the receiving entity SHALL offer the SASL EXENAL mechanism (as defined in Appendix A of FC 4422) to the initiating entity during SASL negotiation. 3. he receiving entity SHALL include an empty <required/> element in its advertisement of the SASL feature. he SU does not include empty <required/> element in its 2-10

17 advertisement of the SASL. he SU does not comply with Server Generation of Outbound Presence Probe. DISA has accepted and approved the vendor s POA&Ms and adjudicated these discrepancies as having a minor operational impact. 4. In response to the receiving entity offering the SASL EXENAL mechanism, the initiating entity SHALL select the EXENAL authentication mechanism by sending an <auth/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and which SHALL include the appropriate value for the EXENAL mechanism attribute and which also includes an empty response of =. 5. he receiving entity SHALL report the success of the handshake by sending a <success/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. 6. After successful SASL negotiation, the initiating entity and the receiving entity SHALL restart the stream. Upon receiving the <success/> element, the initiating entity SHALL initiate a new stream over the existing LS connection by sending a new initial stream header to the receiving entity. he initiating entity SHALL NO send a closing </stream> tag before sending the new initial stream header, since the receiving entity and initiating entity MUS consider the original stream to be replaced upon sending or receiving the <success/> element. 7. Upon receiving the new initial stream header from the initiating entity, the receiving entity SHALL respond by sending a new response stream header to the initiating entity (for which it SHALL generate a new stream ID instead of reusing the old stream ID). 8. he receiving entity SHALL also send stream features, containing any further available features or containing no features (via an empty <features/> element). (c) Simple Authentication and Security Layer (SASL) Failure. he receiving entity SHALL report failure of the handshake by sending a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. he particular cause of failure SHALL be communicated in an appropriate child element of the <failure/> element as defined under Section 6.4 (SASL Errors) of FC he receiving entity SHALL allow a configurable number of retries (at least two and no more than three per IM SIG policy). If the initiating entity exceeds the maximum number of retries, the server SHALL return a stream error (which SHALL be either <policy-violation/> or <not-authorized/>). he SU does not fully comply with SASL Failure equirements. he SU meets SASL error conditions outlined in FC 3920 and not FC he SU does not allow a configurable number of retries. DISA has accepted and approved the vendor s POA&Ms and adjudicated these discrepancies as having a minor operational impact. (4) he DoD UC 2013, section 2.9, states that all client and server implementations SHALL support resource binding. For client-to-server connections, both the client and server SHALL consider resource binding as mandatory-to-negotiate. he SU met these requirements and the requirements in the following subparagraphs with the vendor s LoC. 2-11

18 (a) Advertising Support. Upon sending a new response stream header to the client after successful SASL negotiation, the server SHALL include a <bind/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream features it presents to the client. (b) Server-Generated esource Identifier. A server implementation SHALL be able to generate an resourcepart on behalf of a client. A resourcepart SHALL at a minimum, be unique among the connected resources for a specific local account in the form of <localpart@domain>. Enforcement of this policy is the responsibility of the server. A client SHALL request a server-generated resourcepart by sending an Info/Query (IQ) stanza of type set (see Section , oster-elated Methods) containing an empty <bind/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace. Once the server has generated an resourcepart for the client, it SHALL return an IQ stanza of type "result" to the client, which SHALL include a <jid/> child element that specifies the full JID for the connected resource as determined by the server. (5) he DoD UC 2013, section 2.9, states that client and server implementations SHALL support the syntax and semantics associated with the message, presence, and IQ stanzas. (a) All client and server implementations SHALL support resource binding. (b) For client-to-server connections, both the client and server SHALL consider resource binding as mandatory-to-negotiate. (c) Upon sending a new response stream header to the client after successful SASL negotiation, the server SHALL include a <bind/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream features it presents to the client. (d) A server implementation SHALL be able to generate an resourcepart on behalf of a client. (e) A resourcepart SHALL at a minimum, be unique among the connected resources for a specific local account in the form of <localpart@domain>. Enforcement of this policy is the responsibility of the server. (f) A client SHALL request a server-generated resourcepart by sending an Info/Query (IQ) stanza of type set containing an empty <bind/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace. (g) Once the server has generated an resourcepart for the client, it SHALL return an IQ stanza of type "result" to the client, which SHALL include a <jid/> child element that specifies the full JID for the connected resource as determined by the server. (6) he DoD UC 2013, section 2.10, states that client and server implementations SHALL support the syntax and semantics associated with the message, presence, and IQ stanzas. he SU met these requirements and the requirements in the following subparagraphs with testing and the vendor s LoC. 2-12

19 (a) Common Attributes 1. he following rules SHALL be followed regarding the use of the to attribute in the context of XML streams qualified by the jabber:client namespace. a. A stanza with a specific intended recipient SHALL possess a to attribute whose value is an address. b. A stanza sent from a client to a server for direct processing by the server on behalf of the client (e.g., presence sent to the server for broadcasting to other entities) SHALL NO possess a to attribute. 2. he following rules SHALL be followed regarding the use of the to attribute in the context of XML streams qualified by the jabber:server namespace (i.e., serverto-server streams) a. A stanza SHALL possess a to attribute whose value is an address; if a server receives a stanza that does not meet this restriction, it SHALL generate an <improper-addressing/> stream error. b. he domain identifier portion of the JID in the to attribute SHALL match a hostname serviced by the receiving server; if a server receives a stanza that does not meet this restriction, it SHALL generate a <host-unknown/> or <host-gone/> stream error. 3. he following rules SHALL be followed regarding the use of the from attribute in the context of XML streams qualified by the jabber:client namespace (i.e., client-toserver streams). a. When the server receives an XML stanza from a client, the server SHALL add a from attribute to the stanza or override the from attribute specified by the client, where the value of the from attribute is the full JID (<localpart@domainpart/resource>) determined by the server for the connected resource that generated the stanza or the bare JID (<localpart@domainpart>) in the case of subscription-related presence stanzas. b. When the server generates a stanza from the server itself for delivery to the client, the stanza SHALL include a from attribute whose value is the bare JID (i.e., <domain>) of the server as agreed upon during stream negotiation (e.g., based on the to attribute of the initial stream header). c. When the server generates a stanza from the server for delivery to the client on behalf of the account of the connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza SHALL either (a) not include a from attribute or (b) include a 'from' attribute whose value is the account's bare JID (<localpart@domainpart>). 2-13

20 d. A server SHALL NO send to the client a stanza without a from attribute if the stanza was not generated by the server (e.g., if it was generated by another client or another server). e. When a client receives a stanza that does not include a from attribute, it SHALL assume that the stanza is from the user s account on the server. 4. For <iq/> stanzas, the originating entity SHALL include an id attribute. 5. If the generated stanza includes an id attribute, then it is required for the associated response or error stanza to also include an id attribute, where the value of the id attribute SHALL match that of the generated stanza. 6. If an inbound stanza received by a client or server does not possess an xml:lang attribute, an implementation SHALL assume that the default language is that which is specified for the stream. 7. A server SHALL NO modify or delete the xml:lang attribute of stanzas it receives from other entities. (b) Basic Semantics. When a client or server implementation generates or processes an IQ stanza, the following rules apply. 1. An IQ stanza SHALL include the id attribute. 2. An IQ stanza SHALL include the type attribute. 3. he value of the type attribute for IQ stanzas SHALL be one of the following (if the value is other than one of the following strings, the recipient or an intermediate server SHALL return a stanza error of <bad-request/>). a. get he stanza requests information (e.g., the stanza inquires about data which is needed in order to complete further operations). b. set he stanza provides data that is needed for an operation to be completed (e.g., it sets new values, replaces existing values). c. result he stanza is a response to a successful get or set request. d. error he stanza reports an error that has occurred regarding the processing or delivery of a previously sent get or set request. 4. An entity that receives an IQ request of type get or set SHALL reply with an IQ response of type result or error. he response SHALL preserve the 'id' attribute of the request. 2-14

21 5. An entity that receives a stanza of type result or error SHALL NO respond to the stanza by sending a further IQ response of type result or error. 6. An IQ stanza of type get or set SHALL contain exactly one child element, which specifies the semantics of the particular request. 7. An IQ stanza of type result SHALL include zero or one child element. 8. An IQ stanza of type error SHALL include an <error/> child. (c) Stanza Errors. Client and server implementations SHALL comply with the mandatory requirements defined in Section 8.3 of FC (d) Server ules for Processing XML Stanzas. 1. If the domainpart of the JID contained in the to attribute does not match one of the configured hostnames of the server itself, the server SHALL attempt to route the stanza to the remote domain. 2. If a server-to-server stream already exists between the two domains, the sender s server SHALL attempt to route the stanza to the authoritative server for the remote domain over the existing stream. 3. If no server-to-server stream exists between the two domains, the sender s server SHALL proceed as follows: esolve the hostname of the remote domain, Negotiate a server-to-server stream between the two domains, oute the stanza to the authoritative server for the remote domain over the newly-established stream. 4. If the routing of a stanza to the intended recipient s server is unsuccessful, the sender s server SHALL return an error to the sender. If resolution of the remote domain is unsuccessful, the stanza error SHALL be <remote-server-not-found/>. If the resolution succeeds, but the XML streams cannot be negotiated, the stanza error SHALL be <remote-servertimeout/>. 5. If stream negotiation with the intended recipient s server is successful but the remote server cannot deliver the stanza to the recipient, the remote server SHALL return an appropriate error to the sender by way of the sender s server. 6. If the hostname of the domainpart of the JID contained in the to attribute matches one of the configured hostnames of the server, the server SHALL first determine if the hostname is serviced by the server itself or by a specialized local service. If the latter, the server SHALL route the stanza to that service. If the former, the server SHALL proceed as follows. 7. If there is no local account associated with the <localpart@domainpart>, how the stanza is processed depends on the stanza type. 2-15