Title
FMN Spiral 5 Standards Profile

Reference document

Org
FMN
Pubnum
Date
2022-12-02
Version
Title
Proposed FMN Spiral 5 Specification

Subprofiles

Status

URI

History

Flag Date RFC Version
added 2023-01-23 14-32 15
UUID
28311cab-df40-40a0-8f6e-77207647c423

FMN Spiral 5 Standards Profile

Business Support Standards Profiles

Geospatial Standards Profiles

Service Standard Implementation Guidance

Geospatial Data Exchange Profile

The Geospatial Data Exchange Profile provides standards and guidance in support of Geospatial Web Services to produce and exchange geospatial data between different participants using standardized exchange formats. These datasets will be loaded into specialized geospatial information systems (GIS) and published via standardized Geospatial Web Services.

Communication and Collaboration Applications,

File System Storage Services,

Geospatial Services,

Technical Services,

Text-based Communication Services

Candidate

Exchange of Digital Vector Data

Candidate

This ESRI Technical Paper describes XML schemas for the Geodatabase in order to enable exchange of digital geospatial data. In contrary to the ESRI Arc Geodatabase (File-based), this document is freely available to the public and does not require vendor-specific licenses.

Candidate

Exchange of Digital Raster Data

Candidate

Exchange of Digital Elevation Data

Vector data has to be accompanied with a clear description (UML model or text file) of the data schema and fields which are to be based on AGeoP-11.

Geospatial Web Feeds Profile

The Geospatial Web Feeds Profile provides standards and guidance for in support of Geospatial Web Services to deliver geospatial content to web sites and to user agents, including the encoding of location as part of web feeds.

Web Hosting Services

Candidate

GeoRSS Simple encoding for "georss:point", "georss:line", "georss:polygon", "georss:box".

Candidate

GML subset for point "gml:Point", line "gml:LineString", polygon "gml:Polygon", and box "gml:Envelope". In Atom feeds, location shall be specified using Atom 1.0's official extension mechanism in combination with the GeoRSS GML Profile 1.0 whereby a "georss:where" element is added as a child of the <entry> element.

Geography Markup Language (GML) allows to specify a coordinate reference system (CRS) other than WGS84 decimal degrees (lat/long). If there is a need to express geography in a CRS other than WGS84, it is recommended to specify the geographic object multiple times, one in WGS84 and the others in your other desired CRSs.

Web Feature Service Profile

The Web Feature Service Profile provides standards and guidance for in support of Geospatial Web Services to provide a standardized interface for geodata provision in a defined format over a network connection.

Geospatial Web Feature Services

Candidate

Implementation guidance can be found in DGIWG 122, Defence Profile of OGC’s Web Feature Service 2.0 v.2.0.1, 28 November 2017.

Web Map Service Profile

The Web Map Service Profile provides standards and guidance in support of Geospatial Web Services to provide a standardized interface for geodata provision in a defined format over a network connection.

Geospatial Web Map Services

Candidate

Service Providers can select which profile(s) to implement, and should put emphasis on DGIWG Profiles. Service Consumers that want to consume WMS/WMTS services provided by the NATO Command Structure must implement the NCIA SIP.

Web Map Tile Service Profile

The Web Map Tile Service Profile provides standards and guidance in support of Geospatial Web Services to provide a standardized protocol for serving pre-rendered georeferenced map tiles over the Internet.

Geospatial Web Map Tile Services

Candidate

Service Providers can select which profile(s) to implement, and should put emphasis on DGIWG Profiles. Service Consumers that want to consume WMS/WMTS services provided by the NATO Command Structure must implement the NCIA SIP.

GeoPackage Profile

A GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage standard describes a set of conventions for storing within a SQLite database vector features, tile matrix sets of imagery and raster maps at various scales and extensions. Please note that the spatial extent, vector and raster content, use of extensions, CRS, and metadata of a GeoPackage will generally be based on the intended use and the existing capabilities of system(s) that will use the GeoPackage.

C3 Taxonomy

Candidate

All geopackages are based on version 3 of the SQLite file format, and will have a file name of “.gpkg”. The only tables that are mandated are the gpkg_spatial_ref_sys table and the gpkg_contents table. The gpkg_spatial_ref_sys table contains the spatial (coordinate) reference system (SRS) definitions needed by the gpk_contents and the gpkg_geometry_columns table to relate the vector and tile data in user tables to locations on the earth. The gpkg_contents table provides a list of all the geospatial contents in a GeoPackage and provides identifying and descriptive information that an application can display to a user as a menu of geospatial data that is available for access and/or update.Further implementation guidance can be found in DGIWG 126, the (DRAFT) DGIWG GeoPackage Profile, DRAFT Rev 2.1 (STD-DP-19-005), June 10, 2021, expected ratification April 2022. Providers should put emphasis on DGIWG Profile requirements and recommendations.The DGIWG Profile of Geopackage provides the following advantages to the users of GeoPackage data

  • common tile matrix set zoom levels and tile size;
  • common map projections for global data exchange and exploitation;
  • metadata populated for discovery, awareness and source of GeoPackage content;
  • agreement on extensions used;
  • compliance definition with abstract test suite.

Information Management Standards Profiles

Formal Messaging Standards Profiles

Service Standard Implementation Guidance

Formatted Messages for MedEvac Profile

The Formatted Messages Profile for Medical Evacuation (MedEvac) provides standard for formatted messages that are typically used for C2 of Medical Evacuation missions. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (e-mail), text collaboration (chat) or in standardized voice procedures.

C3 Taxonomy

Candidate

C2 of MedEvac Missions requires the following messages: Situational Awareness:Incident Report (INCREP – A078)Incident Spot Report (INCSPOTREP – J006)Troops in Contact SALTA Format (SALTATIC A073)Requests:Medical Evacuation Request (MEDEVAC – A012)Mechanism Injury Symptoms Treatment (MIST‐AT, supplement to A012)Diving Accident (DIVEACC – N019)Evacuation Request (EVACREQ – N096)

Formatted Messages for Maritime Profile

The Formatted Messages Profile for Maritime provides the standard for formatted messages that are typically used in Maritime operations in support of Maritime Situational Awareness (MSA), tasking and reporting. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (e-mail), text collaboration (chat) or simply with ACP-127 headers.

C3 Taxonomy

Candidate

NATO Message Text Formats—Purpose and Method of Use NATO message text consists of standardized messages that are both man- and machine-readable. The formats of these messages are laid out in the NATO Message Catalogue (APP-11) and are generally referred to as MTF messages. Purpose. MTF messages may be used:To convey operational instructions or intentions.To pass operational information to tactical commanders at sea.To pass operational information between component commanders and subordinate units.To report operational information between commanders and from subordinate to higher formations.To notify organizations of impending and actual operations of units engaged in maritime warfare. Method of Use. MTF messages are to be used as shown in Table 2-15. Detailed instructions of the structures and method of completion are contained in APP-11. Some of these messages have not yet been incorporated into FORMETS and their structures are found in Chapter 6 of APP-11. Relevant Allied publications should be consulted for direction on content to be included.Ships and aircraft joining a force should be in receipt of all relevant messages pertaining to the operation in sufficient time before joining a force, to allow the commander and operational staff to make sufficient plans and provisions that they can join the force without further orders.

Affiliates should take implementation guidance of Maritime related MTFs from Table B-15, Chapter 2 of MTP-01(H)(1).

Formatted Messages for Air Profile

The Formatted Messages Profile for Air provides the standard for formatted messages that are typically used in Air operations in support of the air processesAir Operational Planning and ExecutionandAir Tactical Picture Management Process. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (e-mail), web hosting, text collaboration (chat) or simply the use of the ACP-127 protocol.

C3 Taxonomy

Candidate

NATO Message Text Formats—Purpose and Method of Use NATO message text consists of standardized messages that are both man- and machine-readable. The formats of these messages are laid out in the NATO Message Catalogue (APP-11) and are generally referred to as MTF messages. In some instances older versions of these MTFs are still used by Affiliates as is the case for the ATO and ACO during the Spiral 5 Preferred phase. Purpose. MTF messages may be used:To convey operational instructions or intentions.To pass operational information to tactical commanders at sea.To pass operational information between component commanders and subordinate units.To report operational information between commanders and from subordinate to higher formations.To notify organizations of impending and actual operations of units engaged in maritime warfare. Method of Use. MTF messages are to be used as shown in Table 2-15. Detailed instructions of the structures and method of completion are contained in APP-11. Some of these messages have not yet been incorporated into FORMETS and their structures are found in Chapter 6 of APP-11. Relevant Allied publications should be consulted for direction on content to be included.Ships and aircraft joining a force should be in receipt of all relevant messages pertaining to the operation in sufficient time before joining a force, to allow the commander and operational staff to make sufficient plans and provisions that they can join the force without further orders.

To conduct Air coalition operations, Joint and Air commanders utilize formal messages taken from the NATO Message Catalogue. It should be noted that these formatted MTFs are build on the rules and procedures contained in ADatP-3.To support the procedures of Air Tasking and Execution the following messages should be implemented Air Tasking Order to be implemented from BL-11F.

  • ATO - The ATO is used to task offensive, defensive and support missions including surveillance and control assets in order to conduct both joint and single service air operations.
Air Control Order to be implemented from BL-11C
  • ACO - The ACO is used to provide specific detailed orders for airspace management and control from a higher command to subordinate units.

Communication and Collaboration Standards Profiles

Informal Messaging Standards Profiles

Service Standard Implementation Guidance

Content Encapsulation Profile

The Content Encapsulation Profile provides standards and guidance for content encapsulation within bodies of internet messages, following the Multipurpose Internet Mail Extensions (MIME) specification.

Informal Messaging Services,

Text-based Communication Services

Candidate

MIME encapsulation.

Candidate

Media and content types.

Informal Messaging Profile

The Informal Messaging Profile provides standards and guidance for settings of Simple Mail Transfer Protocol (SMTP).

Informal Messaging Services

Candidate

These standards are mandated for interoperability of e-mail services within the mission network.

TLS with mutual authentication is mandatory for all SMTP communications. Detailed TLS protocol requirements are specified in the 'Service Interface Profile for Transport Layer Security'.

Calendaring and Scheduling Standards Profiles

Service Standard Implementation Guidance

Calendaring Exchange Profile

The Calendaring Exchange Profile provides standards and guidance for the exchange meeting requests, free/busy information as well as calendar sharing implemented by common user access (CUA) software. The focus of this profile is on the exchange of the aforementioned information items and does not cover other typical features found in collaboration software.

Calendaring and Scheduling Services

Candidate

RFC 5545 is required in order to allow a vendor independent representation and exchange of calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol.RFC 5546 defines the scheduling methods that permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling.RFC 6047 defines how calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped and transported over SMTP. Authentication, Authorization and Confidentiality with S/MIME (section 2.2 of RFC 6047) is not applicable for this profile.

Text-based Collaboration Standards Profiles

Service Standard Implementation Guidance

Text-based Collaboration Chatroom Profile

The Text-based Collaboration Managed Chatroom Profile provides standards and guidance to host moderated, password-protected and member-only chatrooms to support strongly controlled persistent near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations. In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc.

Text-based Communication Services

Candidate

XMPP Services hosting the shared chatrooms must comply with the following additional extensions.

Text-based Collaboration Core Profile

The Text-based Collaboration Core Profile provides standards and guidance to establish a basic near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations.

Communication and Collaboration Applications,

Metadata Repository Services,

Technical Services,

Text-based Communication Services

Candidate

The following standards are the base IETF protocols for interoperability of chat services.

Candidate

The following standards are required to achieve compliance for an XMPP Server and an XMPP Client dependent upon the categorisation of presenting a core or advanced instant messaging service interface.

Text-based Collaboration Data Forms Profile

The Text-based Collaboration Forms Profile provides standards and guidance to use (define, discover, fetch and submit) the data forms for use by XMPP entities.

Communication and Collaboration Applications,

Metadata Repository Services,

Text-based Communication Services

Candidate

Text-based Collaboration Tactical Profile

The Text-based Collaboration Tactical Profile provides guidance and standards to support the exchange of chat messages between mission participants at the tactical level.

Text-based Communication Services

Candidate

The current proposal (Sep 21) is to up-issue STANAG 4677 to include a Chat Extension message to support the exchange of Chat messages at the tactical level.

Text-based Collaboration Publish-Subscribe Profile

The Text-based Collaboration Publish-Subscribe Profile provide standards and guidance in support of Text-based Collaboration Publish-Subscribe Services.

Text-based Communication Services

Candidate

Text-based Collaboration Information Discovery Profile

The Text-based Collaboration Information Discovery Profile provides standards and guidance to support Information Discovery about XMPP entities.

Text-based Communication Services

Candidate

Video-based Collaboration Standards Profiles

Service Standard Implementation Guidance

Video-based Collaboration Profile

The Video-based Collaboration Profile provides standards and guidance for the implementation and configuration of video teleconferencing (VTC) systems and services in a federated mission network.

C3 Taxonomy

Candidate

The following standards are required for audio coding in VTC.

Candidate

Use of the BFCP is conditional to that VTC conferencing services are used with the shared content like presentations and/or screen sharing, whose control needs to be shared among participants.

Candidate

The following standards are required for video coding in VTC.

It Is recommended that dynamic port ranges are constrained to a limited and agreed number. This is an activity that needs to be performed at the mission planning stage. Different vendors have different limitations on fixed ports. However, common ground can always be found.As a minimum G.722.1 is to be used. Others are exceptions and need to be agreed by the mission network's administrative authority for video calls.

Audio-based Collaboration Standards Profiles

Service Standard Implementation Guidance

Audio-based Collaboration Profile

The Audio-based Collaboration Profile provides standards and guidance for the implementation of an interoperable voice system (telephony) on federated mission networks.

C3 Taxonomy

Candidate

The following standards are used for audio protocols.

Voice over IP (VoIP) refers to unprotected voice communication services running on unclassified IP networks e.g. conventional IP telephony. Voice over Secure IP (VoSIP) refers to non-protected voice service running on a classified IP networks. Depending on the security classification of a FMN instance, VoIP or VoSIP is mandatory.If a member choses to use network agnostic Secure Voice services in addition to VoSIP, then SCIP specifications as defined for audio-based collaboration services (end-to-end protected voice) shall be used.The voice sampling interval is 40ms.

IP voice to Half Duplex Radio

The Tactical All-informed Voice Information Exchange profile, provides standards in order to establish all-informed voice communications between tactical units (TACCIS) that are interconnected via coalition waveforms.

Audio-based Communication Services,

Voice Access Services

Candidate

This profile covers the part of STANAG 5634 that describes the voice client interface (MELPe/RTP/UDP/IP) as well as the access to a radio device.

This profile MUST use the RTP-HE specification for voice interfacing with the radio and MUST NOT use the VARC approach that is also described in STANAG5634.

Media-based Collaboration Standards Profiles

Call Media Encoding Profile

Service Standard Implementation Guidance

VTC Services Audio and Video Encoding Profile

Standards profile for encoding of video teleconferencing services.

Audio-based Communication Services,

Video-based Communication Services

Candidate

Voice Services Media Encoding Profile

Standards profile for encoding of voice services.

Audio-based Communication Services,

Video-based Communication Services

Candidate

Secure Voice Profile

Service Standard Implementation Guidance

SCIP PPK Profile

In the context of secure communications, PPK is the Pre-Placed Key, which is a symmetric encryption key, pre-positioned in a cryptographic unit. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network.

C3 Taxonomy

Candidate

When PPK is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.

SCIP X.509 Profile

The X.509 standard is used in cryptography to define the format of public key certificates, which are used in many Internet protocols. One example is the use in Transport Layer Security (TLS) / Secure Sockets Layer (SSL), which is the basis for HTTPS, the secure protocol for browsing the web. Public key certificates are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. Besides the format for certificates themselves, X.509 specifies certificate revocation lists as a means to distribute information about certificates that are no longer valid, and a certification path validation algorithm, which allows for certificates to be signed by intermediate Certificate Authority (CA) certificates, which are in turn signed by other certificates, eventually reaching a trust anchor. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network.

C3 Taxonomy

Candidate

When X.509 is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.

Secure Voice Profile

The Secure Voice Profile provides standards and guidance for the facilitation of secure telephony and other protected audio-based collaboration on federated mission networks.

Audio-based Communication Services,

Video-based Communication Services

Candidate

SCIP Signaling Plan and Negotiation.

Candidate

SCIP Network Standards for operation over VoIP Real-time Transport Protocol (RTP).

Candidate

SCIP Network Standards for operation over other network types.

Candidate

SCIP Secure Applications.

AComP-5068 Secure Communications Interoperability Protocol (SCIP) Edition A Version 1provides further guidance for the implementation of SCIP specifications.

Unified Audio and Video Profile

Service Standard Implementation Guidance

IPSec-based Media Infrastructure Security Profile

The IPSec-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Internet Protocol Security (IPSec).

Audio-based Communication Services,

Video-based Communication Services

Candidate

Securing the media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.

Media Streaming Profile

The Media Streaming Profile provides standards used to stream media across the mission network.

Audio-based Communication Services,

Video-based Communication Services

Candidate

Priority and Pre-emption Profile

The Priority and Pre-emption Profile provides standards are used to execute priority and pre-emption service with the Session Initiation protocol (SIP).

Audio-based Communication Services,

Video-based Communication Services

Candidate

SRTP-based Media Infrastructure Security Profile

The SRTP-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP).

Audio-based Communication Services,

Video-based Communication Services

Candidate

Securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.

Note that securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning.

Session Initiation and Control Profile

The Session Initiation and Control Profile provides standards used for session initiation and control.

Audio-based Communication Services,

Video-based Communication Services

Candidate

The following standards are used for regular Session Initiation Protocol (SIP) support..

Candidate

The following standards define the Session Initiation Protocol (SIP) and Real-time Transport Protocol (RTP) support for conferencing.

COI-Enabling Standards Profiles

Situational Awareness Standards Profiles

Service Standard Implementation Guidance

Ground-to-Air Information Exchange Profile

The Ground-to-Air Information Exchange Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16.

Mediation Services,

Track Management Services,

Wired Transmission Services,

Wireless LOS Mobile Transmission Services

Candidate

Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP).

Ground-to-Air Situational Awareness Profile

The Ground-to-Air (G2A) Situational Awareness Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16.

Mediation Services,

Track Management Services,

Wired Transmission Services,

Wireless LOS Mobile Transmission Services

Candidate

Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP).

Overlay Distribution Profile

The Overlay Distribution Profile covers the standards for overlays and (military) symbology that identify locations on the surface of the planet. These overlays are employed when disseminating recognized domain or functional pictures and related picture elements between different communities of interest in a federated mission network environment, as well as sharing with partners operating outside of the Operational Network.

Communication and Collaboration Applications,

Overlay Services,

Recognized Picture Services,

Situational Awareness Services,

Text-based Communication Services

Candidate

Applies to NVG only. Implementation Guidance is provided inNVG APP-6(D)(1) Bindings

Candidate

The minimum conformance level for Spiral 4 is defined as conformant with type B3R - as per the NVG 2.0.2 Specification summarized as: File-based and NVG Request/Response Protocol, all symbolized content, with timing information and operationally relevant extended data.

Candidate

Conditional for three use cases that typically involve cross-domain information exchange: sharing overlays outside of the Mission Network or,sharing overlays to exchange information in the form of Cross-security domain exchange. If an Affiliate has the requirement to share (export/import) with external (non-MN) organisations, then it is to support exchange via KMLexchanging of targeting and JISR products that are prepared on national networks. This particular COI have articulated a requirement to use KML for “Named Area of Interest”. In terms of conditionality, this use is to be defined by that COI. When exporting KML files that reference external resources, KML Zipped (KMZ) must be used and all relevant referenced external resources must be included in the KMZ structure as relative references. The references to these files can be found in the href attribute (or sometimes, the '"`UNIQ--nowiki-0000001F-QINU`"' element) of several KML elements. To enable cross domain exchange and long-term preservation relative references must be used for those resources that are included in the KMZ structure. As many Earth Viewers only work with legacy PKZIP 2.x format for KMZ, .zip folders shall be created in accordance withhttps://www.pkware.com/documents/APPNOTE/APPNOTE-2.0.txt.

All presentation services shall render tracks, tactical graphics, and battlespace objects using the defined symbology standards except in the case where the object being rendered is not covered in the standard. In these exceptional cases, additional symbols shall be defined as extensions of existing symbol standards and must be backwards compatible. These extensions shall be submitted as a request for change within the configuration management process to be considered for inclusion in the next version of the specification.

Operations Information Standards Profiles

Service Standard Implementation Guidance

Battlespace Event Federation Profile

The Battlespace Event Federation Profile provides standards and guidance to support the exchange of information on significant incidents, important events, trends and activities within a coalition network or a federation of networks.

C3 Taxonomy

Candidate

To support exploitation the following APP-11 message formats MUST be supported (MTF Identifier, MTF Index Ref Number): Incident Report (INCREP, A078)Incident Spot Report (INCSPOTREP, J006)Troops in Contact SALTA format (SALTATIC, A073)Events Report (EVENTREP, J092)Improvised Explosive Device Report (IEDREP, A075) The INCREP is used to report any significant incident caused by terrorism, civil unrest, natural disaster, or media activity. The INCSPOTREP is used to provide time critical information on important events that have an immediate impact on operations. The SALTATIC is used to report troops in contact, the report should be made as soon as possible by the unit that has come under some form of attack. It uses the following basic format: Size of enemy, Action of enemy, Location, Time and Action taken The EVENTREP is used to provide the chain of command information about important Events, trends and activities that do not have an element of extreme urgency, but do influence on-going operations The IEDREP is sent when an IED has been encountered. It identifies the hazard area, tactical situation, operational priorities and the unit affected. This initial report should be followed by normal EOD/Engineer reporting requirements.

Friendly Force Tracking Profile

The Friendly Force Tracking Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks.

Mediation Services,

Situational Awareness Services,

Track Distribution Services,

Track Management Services

Candidate

ADatP-36 Edition A Version 2Messages exchanged according to the exchange mechanisms described in ADatP-36(A)(2) shall comply with the Message Text Format (FFI MTF) schema incorporated in APP-11.IP1 is the preferred protocol for FMN Spiral 45. Where needed, the other ADatP-36(A)(2) protocols (IP2 or WSMP 1.3.2) may be used if the situation requires this. The version of WSMP to be used in FMN Spiral 54 is version 1.3.2. This version is explicitly stated as is it is recognized that ADatP-36(A)(2) does not unambiguously state a version of WSMP to be used.ADatP-36 Edition B Version 1Messages exchanged according to the exchange mechanisms described in ADatP-36(B)(1) shall comply with the Message Text Format (FFI MTF) schema incorporated in ADatP-36(B)(1) Standard Related Document (SRD)1.IP1 is the preferred protocol for FMN Spiral 5. Where needed, the other ADatP-36(B)(1) protocols (IP2 or WSMP 1.3.2) may be used if the situation requires this. The version of WSMP to be used in FMN Spiral 5 is version 1.3.2. This version is explicitly stated as is it is recognized that ADatP-36(B)(1) does not unambiguously state a version of WSMP to be used. Note that the IP1 of the ADatP-36(A)(2) and of the ADatP-36(B)(1) are not interoperable. In case both the version need to coexist it is needed the presence of an FFT proxy service as adapter.

Tactical Message Distribution Profile

The Tactical Message Distribution Profile provides standards and guidance to support the exchange of selected messages between Tactical Data Link networks and IP based federation of networks.

Tactical Messaging Access Services

Candidate

The "Minimum Link-16 Message Profile", as described in the FMN Spiral 3 Service Interface Profile for RAP Data, defines the minimum set of data elements that are required to be available for operational or technical reasons so that correctly formatted technical message can be generated to establish the COP in a federated environment. The implementation of the following message types of ATDLP-5.16 is MANDATORY and refers to Appendix A of the standard for the detailed requirement of receive or transmit support, also based on the role of the MNP: Precise Participant Location and Identification (PPLI) MessagesJ2.0 Indirect Interface Unit PPLIJ2.2 Air PPLIJ2.3 Surface (Maritime) PPLIJ2.4 Subsurface (Maritime) PPLIJ2.5 Land (Ground) Point PPLIJ2.6 Land (Ground) Track PPLISurveillance MessagesJ3.0 Reference PointJ3.1 Emergency PointJ3.2 Air Track messageJ3.3 Surface (Maritime) TrackJ3.4 Subsurface (Maritime) TrackJ3.5 Land (Ground) Point/TrackJ3.7 Electronic Warfare Product Information For MNPs that are contributing to Shared Situational Awareness production, the following messages should be supported to maximize the ability to share tactical data: J7 Information ManagementJ9 Weapons Coordination and ManagementJ10 Weapons Coordination and ManagementJ12 ControlJ13 Platform and System StatusJ15 Threat WarningJ17 Miscellaneous More recent editions of this standard may be implemented for operational use but ATDLP-5.16 is the minimum to guarantee Link 16 tactical message distribution.

Candidate

The JREAP Standard enables TDL data to be transmitted over digital media and networks not originally designed for tactical data exchange. JREAP consists of three different protocols: A, B and C. For implementation in FMN only JREAP-C 'Encapsulation over Internet Protocol (IP)' which enables TDL data to be transmitted over an IP network must be used. Refer to Appendix E of the standard for an overview of which messages are MANDATORY for implementation. Whenever there is a common reference clock in the JREAP network, one that is available to all nodes, it should be used. In instances when there is no reference clock available, then Round Trip Time (RTT) should be utilized. With a common time reference, all JREAP-C gateways have a simple way to synchronize and measure delays between JREAP-C nodes by looking at the time of transmission inside the incoming messages. In instances where nodes do not have a common time reference, JREAP-C offers RTT message to measure delays between gateways. These messages measure the RTT between nodes. Each node can state which time reference it will support, and which is its preferred protocol. Inherent within the standard is the ability to select either method

JREAP is designed to support operations using Link 16 over most communication media (JRE media) including forwarding TDL data over satellite communication links, however, for implementation in FMN only JREAP-C Encapsulation over IP is to be used. It supports UDP Unicast, UDP multicast, and TCP.

COI-Specific Standards Profiles

Command and Control Standards Profiles

Service Standard Implementation Guidance

MIP4 Profile

The Land C2 Information MIP4 Profile provides standards and guidance to support the exchange of Command and Control information within a coalition network or a federation of networks.

Land Domain Services,

Order of Battle Services,

Situational Awareness Services

Candidate

The MIP4 profile should be used primarily for the exchange of Battlespace Objects (BSOs); this profile is not intended to support high volume, high frequency updates such as Friendly Force Tracking (FFT). Nor is it intended to support the exchange of data over tactical bearers (with limited capacity and intermittent availability).The MIP interoperability specification comprises both a mandatory technical interface specification as well as implementation guidance documents, and is available on the MIP website (https //www.mip-interop.org). The minimum iteration for MIP4 implementation is MIP4.3 (and MIP4.3 is the basis for the capabilities covered by the Spiral 4 Specification). However, as the MIP4 specification supports inter-version compatibility, later iterations of MIP4 (i.e. MIP4.4+) are expected to remain interoperable with MIP4.3.The suite of guidance documents includes the MIP Operating Procedures (MOP), which provides technical procedures for configuration/operation of MIP 4.3 interfaces in a coalition environment.

Land Tactical C2 Information Exchange Profile

The Land Tactical C2 Information Exchange Profile provides standards and guidance with regard to a core set of Command and Control information and also on how to exchange XML messages within a coalition tactical environment with mobile units.

Situational Awareness Services

Candidate

AEP-76 is to be used for direct C2 Data Exchange between coalition units at the Mobile Tactical Edge, where a shared interoperability network is in place built upon the loaned radio concept. The data model of AEP-76 is based on variant of MIP 3.1 XML messages extended to support APP-6(D) symbology. The following messages of the messages defined in Volume II are mandatory for federating JDSS in coalition operations: JDSSDM 1.2 Presence Message ExtensionJDSSDM 1.2 Identification Message ExtensionJDSSDM 1.2 Contact/Sighting Message ExtensionJDSSDM 1.1 Sketch MessageJDSSDM 1.1 GenInfo MessageJDSSDM 1.1 Receipt MessageJDSSDM 1.2 Overlay Message ExtensionJDSSDM 1.1 Casualty Evacuation Request Message (Request Message Body only)JDSSDM 1.2 Chatrooms Message ExtensionJDSSDM 1.2 Chat Message Extension

Candidate

The JDSS Gateway shall use JDSSDM 1.2 exclusive mode configuration as defined by Business Rule BACK010.

Candidate

Developers may useAEP-76 Ed A V3 XML Schema Definitionsfor implementing JDSS.

Maritime C2 Information Exchange Profile

The Maritime C2 Information Exchange Profile provides standards and guidance to support the exchange of the Recognized Maritime Picture (RMP) information within a coalition network or a federation of networks.

Recognized Maritime Picture Services

Candidate

For conditional use, coupled with the AIS line from OTH-T GOLD Baseline 2007.

Candidate

The implementation of the following message types is mandatory

  • Enhanced Contact Report (XCTC);
  • Overlay Message (OVLY2, OVLY3);
The implementation of the following message types is mandatory for an RMP Manager, optional for Mission Network Participants
  • Area of Interest Filter (AOI);
  • FOTC Situation Report;
  • Group Track Message (GROUP);
  • Operator Note (OPNOTE);
  • PIM Track (PIMTRACK);
These messages can be used for other C2 functions.For interconnecting C2 Systems and their RMP Services, the implementation of the following transport protocol to share OTH-T GOLD messages is mandatory
  • TCP (connect, send, disconnect) - default port 2020
End-users that do not have RMP Applications MAY generate OTH-T GOLD messages manually and transmit them via eMail/SMTP.

Maritime C2 Processes Profile

Maritime Operations includes a set of military activities conducted by maritime air, surface, sub-surface and amphibious forces to attain and maintain a desired degree of control of the surface, sub-surface, and air above the sea, influence events ashore, and, as required, support land, air/space, and cyber operations

C3 Taxonomy

Candidate

The maritime conflict and operation themes are likely to cover the following types of operations in the maritime environment (AJP-3.1)

  • Major combat operations,
  • Peace support,
  • Peacetime military engagement.
Maritime forces have roles in the following activities
  • Warfare and combat,
  • Maritime security,
  • Security cooperation.

XMPP/JDSSDM Mediation Profile.

The XMPP/JDSSDM Mediation Profile provides standards and guidance on text based information exchange between TACCIS and OPCIS.

Mediation Services,

Situational Awareness Services,

Text-based Communication Services

Candidate

MIP 4/JDSSDM Mediation Profile.

The MIP 4/JDSSDM Mediation Profile provides standards and guidance on non-friendly observed reported Battlespace Objects information exchange between TACCIS and OPCIS.

Mediation Services,

Situational Awareness Services

Candidate

NVG/JDSSDM Mediation Profile.

The NVG/JDSSDM Mediation Profile provides standards and guidance on overlays exchange between TACCIS and OPCIS.

Mediation Services,

Situational Awareness Services

Candidate

ADatP-36/JDSSDM Mediation Profile.

The ADatP-36/JDSSDM Mediation Profile provides standards and guidance on self reporting FFT exchange between TACCIS and OPCIS.

Mediation Services,

Situational Awareness Services

Candidate

Intelligence and ISR Standards Profiles

Service Standard Implementation Guidance

ISR Library Interface Profile

The ISR Library Interface is the standard interface for querying and accessing heterogeneous product libraries maintained by various nations.

Intelligence and ISR Functional Services

Candidate

The following NATO standards provide the specification as well as business rules for interoperability of ISR libraries.

Candidate

The following NATO standards are mandated for interoperability of ISR library products.

Candidate

The Basic Image Interchange Format (BIIF) is mandated for interoperability of ISR libraries.

Candidate

The following international standards are mandated for interoperability of ISR libraries.

Candidate

Implementation of JC3IEDM (STANAG 5525) in the context of the ISR Library Interface Profile is limited to the definition of unique keys that could be used to unambiguously refer to an external information object that is modelled in accordance with JC3IEDM. Note that AEDP-17 refers to the metadata attribute “JC3IEDMIdentifier” on page G-15, but to “identifierJC3IEDM” on page G-79. The correct attribute to use is “identifierJC3IEDM”.

To ensure optimization of network resources the ISR Library Interface services work best with a unicast address space.AEDP-17 defines four interfaces

  • STANAG 4559CORBA'sinterface,
  • provider-consumer interface (seeISR Library Access Pattern) based on HTTP/HTTPS interface'
  • CSD-Publish services interface,
  • CSD-Query services interface.
The CORBA interface is required for server to server interaction (i.e., federation) as well as client to server interaction.The HTTP/HTTPS interface is for transferring files between server and clients as well as remote file access.The Publish and Query are web service interfaces supporting only client to server interaction. Although AEDP-17 allows for the use of partially qualified attribute name for the queries (see AEDP-17 section B-3.10.3 Query validation), the use of fully qualified attribute names are recommended since some AEDP-17 implementations require such fully qualified attribute name and this will ensure an adequate mapping to the right attribute. This is particular important considering the extension required to support all information products specified within the FMN Spiral 4 Procedural Instructions for Intelligence and JISR.AEDP-17 Annex K provides further details on the ISR Library synchronization.Service provider must identify which interfaces/patterns they support as a part of the federation process.

ISR Streaming Profile

The ISR streaming services architecture defined by AEDP-18 covers the ISR enterprise wide sharing and management of streaming data, i.e. data generated by sensors and which is periodically updated. The ISR Streaming Services Standard mandates support for streams of one or more of the data types: Ground Moving Target Indicator (GMTI),Motion imagery,Link 16. The supported datatype(s) of the ISR Streaming Services are required information in the Joining instructions.

ISR Exploitation Services,

Intelligence and ISR Functional Services

Candidate

Candidate

Implementation mandates that one or more of the following standards be implemented:

The operational processes facilitated by the ISR Streaming architecture are described in detail in the Procedural Instructions for JISR and Intelligence Products which is based on AIntP-16 (IRM&CM procedures) and AIntP-14 (JISR procedures).

CIS Support Standards Profiles

SMC Orchestration Profile

Service Standard Implementation Guidance

SMC Process Implementation Profile

SMC Process Implementation Profile for Enabling Processes

Service Standard Implementation Guidance

SMC Process Implementation Profile for Party Management

The Party Management, leveraging the TM Forum Party Management API, enables the exchange of federated Parties between Mission Network Participants.

C3 Taxonomy

Candidate

SMC Process Implementation Profile for Geographic Location Management

The Geographic Location Management, leveraging the - TM Forum Geographic Address Management API, - Tm Forum Geographic Site Management API, - Tm Forum Location Management enables the exchange of federated Locations between Mission Network Participants.

C3 Taxonomy

Candidate

SMC Process Implementation Profile for Activity Management

Description The Activity Management, leveraging the TM Forum Process Flow Management API, enables the exchange of federated Service Tasks between Mission Network Participants.

Business Support SMC Services

Candidate

Federated Fires profiles

Service Standard Implementation Guidance

Kinetic Indirect Fire Support Information Exchange profile

The Kinetic Indirect Fire Support Information Exchange profile provides standards and guidance to plan, prepare and execute kinetic fires missions, in support of Land maneuver forces, within a coalition network or a federation of networks.

C3 Taxonomy

Candidate

Contact NATO ICGIF IER Panel Chair about ASCA-012 CTIDP.========Digital Fire Control Systems must be qualified to guarantee a sufficient level of interoperability. Upon necessary Information Assurance objectives, Dependability of digital fire control systems (DFCS) is the most critical objective to reach, in order to ensure a fast, constant, reliable and safe Fire Support service to maneuver units.For now and the purpose of indirect kinetic fire support, and in accordance with STANAG-2245 and STANAG-2432 (AArtyP-03), be a Full or Associated ASCA Member is the stipulated way for an Affiliate to ensure such an aim.After be sponsored, nation implements ASCA-012 CTIDP, coached by its sponsoring nation, and demonstrates interoperability with at least two Full ASCA Members.

  • Full Members are committed to participate to all ASCA meetings and actively contribute to the Standard development;
  • Associated Members maintain their interoperability with Community DFCS and update their status and ASCA activities, participating at the main ASCA meeting once a year.
As of 2022, at least Belgium, Canada, Denmark, Estonia, Finland, France, Germany, Hungary, Italy, Netherland, Norway, Poland, Romania, Spain, Sweden, Turkey, United Kingdom, and United States of America are actively involved.

Communications Access Standards Profiles

Service Standard Implementation Guidance

Inter-Autonomous Systems Multicast Signaling Profile

The Inter-Autonomous Systems Multicast Signaling Profile provides standards and guidance for multicast group signaling between inter-autonomous systems.

C3 Taxonomy

Candidate

Service providers with their own multicast capability shall implement Rendezvous Point (RP) and provide signaling between their network segments supporting the following IP multicast signaling standards.

Inter-Autonomous Systems Routing Profile

The Inter-Autonomous Systems Routing Profile provides standards and guidance for routing between inter-autonomous systems. The best current practice for the Border Gateway Protocol (BGP) based network routing operations and security is described in RFC 7454 - "BGP Operations and Security". Deployment guidance with regards to the application of BGP in the Internet is described in IETF RFC 1772:1995.

Audio-based Communication Services,

Packet Routing Services,

Video-based Communication Services

Candidate

The following standards apply for all IP interconnections.

Candidate

Additionally, the following standards apply for use of communities, extended communities and 32-bit extended communities for traffic engineering purposes.

Candidate

The following standard is added to improve security of BGP peering

Candidate

The following standards are added to improve BGP resilience through faster detection of network failures

BGP sessions must be authenticated, through a TCP message authentication code (MAC) using a one-way hash function (MD5), as described in IETF RFC 4271.

Traffic Flow Confidentiality Protection Profile

The Traffic Flow Confidentiality Protection Profile provides standards and guidance for implementing IPSEC based protection for data traffic.

Authentication Services,

Communications Security Services,

Transport Cryptography Services

Candidate

These are standards to implement protection profiles needed for IPSec.

Generic Routing Encapsulation profile

The Routing Encapsulation Profile provides standards and guidance for generic routing encapsulation functions over network interfaces both in PCN and in Information Domain network interconnection points (NIPs).

Packet-based Broadcast Services,

Packet-based Transport Services

Candidate

Standards for GRE tunneling in IPv4

Candidate

Standards for GRE tunneling in IPv6

Candidate

Key and sequence number extension for GRE

Inter-Autonomous Systems Multicast Source Discovery Profile

The Inter-Autonomous Systems Multicast Source Discovery Profile provides standards and guidance for multicast group source active signaling between inter-autonomous systems.

C3 Taxonomy

Candidate

Service providers with their own multicast capability shall provide signaling between their Rendezvous Point (RP) supporting the following IP multicast source discovery standards.

Inter-Domain Multicast Planning Profile

Multicast management within inter-domain context requires careful planning and orchestration.

C3 Taxonomy

Candidate

The following standards shall apply to multicast routing.

NMCD Information Exchange Service Profile

The NMCD Information Exchange uses RESTCONF-like exchange semantics to distribute Protected Core Community PCSOP information throughout the community.

Web Hosting Services,

Web Platform Services

Candidate

NMCD IES uses a subset of the RESTCONF protocol to exchange information between peering NMCD IESes.

Candidate

NMCD IES client discovers the resource root endpoint of the RESTCONF protocol using the Web Host Metadata standard.

Candidate

Information published by the NMCD IES is labelled according to ADatP-4774 confidentiality information label schema.

Candidate

Confidentiality Information Labels used by the NMCD IES are bound to data objects using the ADatP-4778 Metadata Binding Mechanism.

Communications Transport Standards Profiles

Service Standard Implementation Guidance

IP Quality of Service Profile

The IP Quality of Service Profile provides standards and guidance to establish and control an agreed level of performance for Internet Protocol (IP) services in federated networks.

Packet-based Broadcast Services,

Packet-based Transport Services

Candidate

The following normative standard shall apply for IP Quality of Service (QoS).

Candidate

Following standards give more information on implementation of QoS within IP networks.

Inter-Autonomous Systems IP Communications Security Profile

The Inter-Autonomous Systems IP Communications Security Profile provides standards and guidance for communications security for transporting IP packets between federated mission network interconnections and in general over the whole Mission Network.

Communications Security Services

Candidate

In missions where no NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected with technical structures by mutual agreement made during the mission planning phase.

Candidate

In missions where NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected at minimum with Type-B crypto devices.

Inter-Autonomous Systems IP Transport Profile

The Inter-Autonomous Systems IP Transport Profile provides standards and guidance for Edge Transport Services between autonomous systems, using the Internet Protocol (IP) over point-to-point ethernet links on optical fibre.

Frame-based Access Services,

Packet-based Access Services,

Transport Services

Candidate

Section 3 - Clause 38 - 1000BASE-LX, nominal transmit wavelength 1310nm.

Candidate

The use of LC-connectors is required for network interconnections inside shelters (or inside other conditioned infrastructure).

Candidate

Physical connectors for harsh environments

Candidate

Use 1 Gb/s ethernet over single-mode optical fibre (SMF).

Interface Auto-Configuration Profile

The Interface Auto-Configuration Profile provides standards and guidance for support of the Routing Information Protocol (RIPv2 and RIPng) to expand the amount of useful information carried in RIP messages for the exploitation of auto-configurations over NIP-G and PCN-compliant interfaces, and for the inclusion of a measure of control.

C3 Taxonomy

Candidate

The auto-configuration is a highly recommended feature for the desired flexibility, maintainability and survivability in communications systems configuration. Nevertheless, there is always an option to follow a manual configuration process. This implies that auto-configuration in itself is not mandatory; when applied, the listed standards are mandatory.

Tactical Interoperability Network Interconnection Profile

The Tactical Interoperability Network Interconnection Profile provides standards and guidance for a shared interoperability network at the mobile tactical edge: when no common waveform for land tactical radios can be used to interconnect networks, a standard "bridging" solution with loaned radios can be used to mitigate the interoperability problem. In that situation, interoperability will be achieved with the exchange of assets. Information exchange for mobile users at the tactical edge is based onSTANAG 4677. The information exchange over the loaned radio interface shall be protected with similar mechanisms that are required to protect NATO RESTRICTED information or an equivalent mission classification level. The protection of information at the lower tactical level has a number of distinctive characteristics: The information is often transient and perishable – it is only relevant for a short period of time.The transmission of information is confined to a small geographic area.The information is held on portable devices which are often close to physical threats.The networks at the lower tactical level are often isolated from the wider network.

C3 Taxonomy

Candidate

Candidate

Implement the following standard in addition to RFC 1112.

This profile is to be used exclusively for operations at the tactical edge (TACCISMC 0640) and not in combination with any of the other profiles defined in the SP4 SI for Communications, which are targeted at OPCISMC 0640.

IPv4 Transport Services Profile

Implementation guidance for the implementation of standards for transport service based on Internet Protocol version 4 (IPv4).

Edge Services,

Packet-based Access Services,

Packet-based Broadcast Services,

Packet-based Transport Services,

Transport Services

Candidate

Standards for Internet Protocol version 4 (IPv4).

Candidate

Standards for Internet Protocol version 4 (IPv4) over Ethernet.

Candidate

For automatic detection of the maximum transmission unit (MTU) between end-points.

IPv6 Transport Services Profile

Implementation guidance for the implementation of standards for transport service based on Internet Protocol version 6 (IPv6).

Packet-based Access Services,

Packet-based Broadcast Services,

Packet-based Transport Services,

Transport Services

Candidate

These standard are used for point-to-point interconnections between network devices.

Candidate

Standards for IPv6 address allocation scheme utilizing reserved address space for Unique Local IPv6 Unicast Addresses. It should be noted that actual allocation policy is not following the RFC, but co-ordinated policy. Also prefix that is used is from the non-defined area of ULA addresses.

Candidate

Standards for IPv6 Anycast address assignment. These standards need to be taken account when assigning IPv6 addresses on systems.

Candidate

Standards for Internet Protocol version 6 (IPv6) and Internet Control Message Protocol for IPv6 (ICMPv6).

Candidate

For automatic detection of the maximum transmission unit (MTU) between end-points. It is strongly recommended that IPv6 nodes implement Path MTU Discovery, in order to discover and take advantage of path MTUs greater than 1280 octets.

Candidate

Standards for Internet Protocol version 6 (IPv6) neighbor discovery over link level network.

Candidate

Standard for understanding different options to generate IPv6 addresses.

IP Access to Tactical Radio

This profile described the standards for IP access to a tactical radio. It contains the IP requirements of STANAG 5634 and STANAG 4677. This includes at least the following standards: UDP, IPv4 unicast and multicast, including IP addressing standards, IGMPv3, ICMP, DSCP.

IPv4 Routed Access Services,

Packet-based Broadcast Services,

Packet-based Transport Services

Candidate

A Standard for the Transmission of IP Datagrams over Ethernet Networks (IPv4)

Candidate

Internet Standard Subnetting Procedure

Candidate

Host extensions for IP multicasting

Candidate

Path MTU discovery

Candidate

Address Allocation for Private Internets

Candidate

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

Candidate

Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

Candidate

IANA Guidelines for IPv4 Multicast Address Assignments

Candidate

Internet Group Management Protocol, Version 3

NINE ISPEC

NINE ISPEC - NETWORKING AND INFORMATION INFRASTRUCTURE (NII) INTERNET PROTOCOL (IP) NETWORK ENCRYPTOR – INTEROPERABILITY SPECIFICATION, will serve as a basis and allows manufacturers from different nations to develop and produce interoperable IPsec devices to be used in federated IP network environments such as the Federated Mission Networking (FMN).

Communications Security Services

Candidate

AComP-4787 Ed1 contains several sections out of which following form basis for interoperability in the context of FMN SP5

  • Core Specification
    • Threshold requirements considered Minimum Interoperability Requirements.
  • Gateway Extension
    • Understand that NINE devices for FMN are gateway devices.
  • Generic Discovery Client Extension
    • The initiation of the discovery process is required when a packet transmitted to a SA endpoint is marked as unreachable; this is foreseen in NINE Core as part of the “Peer NINE Reachability Detection”. The support of this feature is essential for devices since it ensures the reachability of the NINE endpoints.
  • Reachability Extension
    • NINE “Reachability” Extension defines the required mechanism to discover, maintain and advertise subnets of networks which are available at the PlainText interface (including through SAs) using routing protocols (like RIPv2 and RIPng).
  • Traffic Protection - Suite B Cryptography Core

Infrastructure Standards Profiles

Infrastructure Security Standards Profiles

Service Standard Implementation Guidance

Certificates Exchange Profile

The Certificates Exchange Profile specifies the use of public standards for exchange of digital certificates.

Digital Certificate Services,

Technical Services

Candidate

The PEM format with base64-encoded data shall be used to exchange Certificates, Certificate Revocation Lists (CRLs), and Certification Requests.

Cryptographic Algorithms Profile

The Cryptographic Algorithms Profile specifies the use of public standards for cryptographic algorithm interoperability to protect IT systems.

Digital Certificate Services,

Technical Services

Candidate

The following algorithms and parameters are to be used to support specific functions

  • Root CA Certificates
    • Digest Algorithm SHA-256 or SHA-384 (Root CA certificates, which were signed using SHA-1 before 1 January 2016, may be used until 1 January 2025)
    • RSA modulus size (bits) 3072 or 4096
    • ECC Curve NIST P-256 or P-384
  • Subordinate CA Certificates
    • Digest Algorithm SHA-256 or SHA-384
    • RSA modulus size (bits) 2048, 3072 or 4096
    • ECC Curve NIST P-256 or P-384
  • Subscriber Certificates
    • Digest Algorithm SHA-256 or SHA-384
    • RSA modulus size (bits) 2048, 3072 or 4096
    • ECC Curve NIST P-256 or P-384
For further guidance on the implementation the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2 shall also be considered.Even more guidance
  • A digital certificate service provider shall choose which combination of algorithm and keylength chain to build. The service portfolio may contain several parallel solutions.
  • You shall not mix key-algorithms in one CA/sub-CA chain.
  • A digital certificate service consumer shall support the full spectrum of possible combinations in algorithm and keylength.
  • During a mission instantiation, the service designer shall verify service consumer capabilities with regard to supported algorithms.

Digital Certificate Profile

The Digital Certificate Profile provides standards and guidance in support of a Public Key Infrastructure (PKI) on federated mission networks.

Digital Certificate Services,

Technical Services

Candidate

The version of the encoded public key certificate shall be version 3.For further guidance on the implementation the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2 shall also be considered.

Transport Layer Security Fallback Profile

This profile provides detailed information, guidance, and standardsto be used for the usage of Transport Layer Security version 1.2 (TLS 1.2) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers.

Directory Services,

Informal Messaging Services,

Technical Services,

Text-based Communication Services,

Web Hosting Services

Candidate

TLS 1.2 compression SHALL be disable with the use of the "null" compression method.

Candidate

TLS 1.2 base standards. Mandatory extensions: Section 7.4.1.4.1 - Signature Algorithms

Candidate

Transport Layer Security (TLS) Renegotiation Indication Extension Renegotiation shall only be initiated by the server.Implementation shall be compliant with RFC 7525, section 3.5

Candidate

TLS extensions Mandatory extensions: Section 3 - Server Name Indication Extension Disallowed extensions: Section 7 - Truncated HMAC

Candidate

Session Hash and Extended Master Secret Extension

Candidate

Negotiated Finite Field Diffie-Hellman Ephemeral Parameters Required curves: secp256p1secp384p1

Candidate

Supported Elliptic Curves extension. Required extensions: Section 5.1/5.2 - Supported Point Formats Required curves: secp256r1secp384r1

Certificate validation

  • Federated services that implement TLS shall perform certificate validation. Certificate validation shall include checking at least full certificate path validation, certificate validity period and certificate revocation status.
  • Federated services that implement TLS shall be able to check the revocation status of digital certificates through HTTP or OSCP endpoints.
  • If compliance and validation of Digital Certificates fail, TLS connections shall be terminated
Cipher suites
  • Implementations shall be configured to only use the following cipher suites
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Mandatory for RSA certificates)
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Optional)
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Mandatory for ECC certificates)
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Optional)
  • If no cipher suite could be negotiated, TLS connections shall be terminated.
Maximum lifetime and session termination
  • The upper limit for the lifetime of a TLS session shall not exceed 48 hours.
  • When the TLS connection is closed, ephemeral keys shall be securily deleted.
Disallowed standards and extensions
  • SSL version 2.0, version 3.0 and TLS version 1.0 or 1.1
  • The Heart Beat Extension (RFC 6520
  • Encrypt-then-MAC extension (RFC 7366)

Transport Layer Security Profile

This profile provides detailed information, guidance, and standards to be used for the usage of Transport Layer Security version 1.3 (TLS 1.3) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers.

Directory Services,

Informal Messaging Services,

Technical Services,

Text-based Communication Services,

Web Hosting Services

Candidate

Base standard

Certificate validation

  • Federated services that implement TLS shall perform certificate validation. Certificate validation shall include checking at least full certificate path validation, certificate validity period and certificate revocation status.
  • Federated services that implement TLS shall be able to check the revocation status of digital certificates through HTTP or OSCP endpoints.
  • If compliance and validation of Digital Certificates fail, TLS connections shall be terminated
Cryptographic algorithms and cipher suites
  • TLS_AES_128_GCM_SHA256 (mandatory)
  • TLS_AES_256_GCM_SHA384 (recommended)
  • TLS_CHACHA20_POLY1305_SHA256 (recommended)
  • If no cipher suite could be negotiated, TLS connections shall be terminated.
Maximum lifetime and session termination
  • The upper limit for the lifetime of a TLS session shall not exceed 48 hours.
  • When the TLS connection is closed, ephemeral keys shall be securily deleted.
Disallowed standards and extensions
  • SSL version 2.0, version 3.0 and TLS version 1.0 or 1.1
  • The Heart Beat Extension (RFC 6520)

Digital Certificate Validation (OCSP) Profile

The Digital Certificate Validation (OCSP) Profile provides standards and guidance in support of a digital certificate validation based on OCSP.

Digital Certificate Services

Candidate

The Online Certificate Status Protocol (OCSP) capability is mandatory for PKI Service providers. Clients might support this protocol.

The addresses of OCSP endpoints shall be provided in digital certificates through Authority Information Access (AIA) extension.

Digital Certificate Validation (CRL) Profile

The Digital Certificate Validation (CRL) Profile provides standards and guidance in support of a digital certificate validation based on CRL.

Digital Certificate Services

Candidate

Service profile Digital Certificate Validation (CRL) Profile does not refer to any standard.

    CRLs may be provided at multiple locations, these are to be provided in digital certificates through the cRLDistributionPoints extension. Each CA is to provide CRLs over HTTP. Clients must support this protocol.The version of the encoded certificate revocation list (CRL) shall be version 2.

    Infrastructure Networking Standards Profiles

    Domain Naming Profile

    Service Standard Implementation Guidance

    Secure Domain Naming Profile

    The Secure Domain Naming Profile provides standards and guidance to support the hierarchical distributed name system with a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality. These extensions are combined in the Domain Name System Security Extensions (DNSSEC), a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks.

    C3 Taxonomy

    Candidate

    Only the following security algorithms shall be used

    • RSASHA256,
    • RSASHA512,
    • ECDSAP256SHA256,
    • ECDSAP384SHA384.

    Zone Transfer Profile

    The Zone Transfer Profile provides standards and guidance to support zone synchronization in the hierarchical distributed name system for authoritative name servers of federated mission network ing.

    C3 Taxonomy

    Candidate

    Candidate

    Mandatory message digest algorithm is hmac-sha384.

    Anycast DNS Profile

    The Anycast DNS Profile provides standards and guidance for operating an Authoritative Name Service on an anycast address.

    Packet-based Access Services

    Candidate

    DNS operation on shared unicast address

    Candidate

    Operation of anycast services

    Generic Domain Naming Profile

    The Generic Domain Naming Profile provides base standards and guidance to support the hierarchical distributed name system for computers, services, or any resource connected to a federated mission network.

    C3 Taxonomy

    Candidate

    Base standards

    Candidate

    Additional types and bigger payloads

    IPv6 Domain Naming Profile

    The IPv6 Domain Naming Profile contains additions to the base Domain Name System standards, which enable the usage of the Domain Name System in the context of the Internet Protocol, version6.

    C3 Taxonomy

    Candidate

    DNS Extensions for IP version 6

    Candidate

    Address Selection

    Time Synchronization Profile

    Service Standard Implementation Guidance

    Peer Time Synchronization Profile

    The Symmetric Peer Profile provides standards and guidance to support the symmetric synchronization of time servers on the same NTP stratum level across a network or a federation of networks.

    Distributed Time Services

    Candidate

    Protocol modes 1 and 2

    Federation Time Synchronization Profile

    The Client/Server Synchronization Profile provides standards and guidance to support the synchronization of clients and servers across a network or a federation of networks and the safeguard of the accurate use of timestamps.

    Distributed Time Services

    Candidate

    Protocol modes 3 and 4

    Stratum 1 servers must implement IPv4 so that they can be used as time servers for IPv4-based mission networks.

    Infrastructure Processing Standards Profiles

    Service Standard Implementation Guidance

    Virtual Appliance Interchange Profile

    The Virtual Appliance Interchange Profile provides standards and guidance to support the Virtualized Processing Services to exchange virtual appliances between different host platforms.

    Technical Services,

    Virtualized Processing Services

    Candidate

    File format for virtual hard disk drives, which the service consumer has to be able to provide.

    Candidate

    OVF format shall be used as exchange format.

    To ensure optimization of the exchange of virtual appliances, the following guidelines should be observed.The environment should be prepared for optimal implementation of a virtual machine (VM).

    • Strip down the hardware as much as possible, by removing sound cards, USB controllers, CD-ROM and floppy drives, and para-virtualized devices;
    • Minimize the VMs’ HDD footprint to a minimum and use thin provisioning;
    • Unmount any removable devices before exporting to Open Virtualization Format (OVF);
    • Delete all snapshots;
    • Shutdown machine; and
    • Include a CRC Integrity Check.
    The platform should be able to support the following minimalistic set of hardware features
    • vCPU support minimal two vCPUs supported per VM
    • SCSI disk controller minimal two
    • Virtual SCSI harddisks and optical disk minimal eight
    • IDE nodes
    • Virtual IDE disks
    • Virtual IDE CD-ROMs
      • E1000 (Network Interface)
    • SVGA displays minimal one
    • Serial ports minimal one
    Note although OVF defines standard for virtual machine images, there still might be a slight differences how various vendors use it, thus some manual modifications of the OVF files might be necessary before their import.

    Platform Standards Profiles

    Database Platform Standards Profiles

    Service Standard Implementation Guidance

    Directory Data Exchange Profile

    The Directory Data Exchange Profile provides standards and guidance in support of a mechanism used to connect to, search, and modify Internet directories on the basis of the Lightweight Directory Access Protocol (LDAP).

    Directory Services

    Candidate

    Directory Data Structure Profile

    The Directory Data Structure Profile provides standards and guidance in support of the definition of the namespace of a federated mission network on the basis of the Lightweight Directory Access Protocol (LDAP). The Directory Data Structure Profile facilitate the need to share contact information across all participants of a federation, in order to support improved collaboration and communication, for example through the sharing of a Global Address List (GAL) for email addresses.

    Directory Services

    Candidate

    The central DIT, for sharing GAL information, is based on the IETF standards for 'inetOrgPerson' LDAP Object Class.The Federated Directory Services shall be able to exchange inetOrgPerson object class with mandatory Common Name (cn) and Surname (sn) attributes.Based on the specific mission network's requirements, the list of exchanged attributes for a particular mission network might be extended by Service Management Authority (SMA) during the planning process. The table provides mandatory, recommended and optional specific guidance of such attributes within a federation context. The attributes refer back to those attributes as defined in ACP 133 Supp-1(C).[CREATE TABLE FROM TABLE 3 IN SIP FOR IDENTITY INFORMATION]

    Global Address List Schema Mapping Profile

    Participants within a federation may use different directory representations (Active Directory and IETF schemas) for GAL information, therefore, information within the different directories needs to be mapped to the correct representation for each participant.

    C3 Taxonomy

    Candidate

    The ‘Contact’ Object Class, defined in Microsoft Active Directory schema, is not a standard LDAP class.In the case a mapping is required to be performed between the standardised IETF 'inetOrgPerson' Object Class and the 'Contact' Object Class then the following rules must be applied

    • All mandatory attributes in the Consumer object class must be created; and,
    • the cardinality of attributes values in the Consumer object class must be maintained (e.g. an attribute may only be allowed a single value in the Consumer’s object class, but the Provider’s object class may allow multiple values).
    A potential list of suitable attributes for replication is displayed in the Table. The table provides
    • Mappings between the Active Directory and IETF schemas (for those suitable attributes);
    Object class the attribute is derived from; and,
    • Obligations and cardinality.
    The following guide will assist in understanding the table
    • “ADUC” - the Active Directory field that is shown in “Active Directory User and Computers” for the attribute (where it exists);
    • “Attribute” - the attribute name (which may be different from the LDAP NAME);
    • “M” – is the attribute mandatory within the Object Class;
    • “OC” – the Object Class with which the attribute is associated; and,
    • “Single-Value” – is the attribute single or multi valued.
    [CREATE TABLE FROM TABLE 2 IN SIP FOR IDENTITY INFORMATION]

    Web Platform Standards Profiles

    Service Standard Implementation Guidance

    Metadata Labelling Profile

    Metadata Labelling Profile describes how to apply standard confidentiality metadata to common protocols and file formats.

    Communication and Collaboration Applications,

    Direct Messaging Services,

    Informal Messaging Services,

    Metadata Repository Services,

    Technical Services,

    Text-based Communication Services,

    User Applications,

    Web Hosting Services

    Candidate

    The Allied Data Publication and associated binding profiles describe the syntax and mechanisms for applying Confidentiality Metadata.

    The structure of the binding is defined in ADatP-4778.The labelling values shall be based on the security policy defined for the mission.

    Web Authentication Profile

    The Web Authentication Profile provides standards and guidance in support of principal authentication and exchange of authenticated principal's identity attributes between Mission Network Participants.

    Security Token Services,

    Web Hosting Services

    Candidate

    Identity providers must support the following components of the SAML 2.0 specification

    • Profiles Web Browser SSO Profile and Single Logout Profile.
    • Bindings HTTP Redirect Binding and HTTP POST Binding.
    When making authentication requests<code><samlp AuthnRequest> </code>to Identity Providers, the requesting SP/RP must fulfill the following requirements
    • All Authentication Requests shall be signed.
    • HTTP-Redirectbinding shall be used for the transmission of Authentication Request messages.
    Authentication responses from an identity provider must fulfill the following requirements
    • HTTP-POSTbinding shall be used for the receipt of<code><samlp Response> </code>messages.
    • SAML Assertions shall contain a<code> <saml NameID> </code>element with the following format to enable Single Logout <code>urn oasis names tc SAML 2.0 nameid-format transient.</code>
    • All<code><saml Attribute></code>elements shall contain a NameFormat of<code>urn oasis names tc SAML 2.0 attrname-format uri </code>. Required attribute names are listed in the Context section.
    • <code> <ds KeyName> </code>element, specified in the XML Digital Signature Core specification [1], inside the<code> <ds KeyInfo> </code>element shall be left empty.
    • If encryption is used for SAML Response messages, the assertion element shall be encrypted as a whole. Encryption of only Attributes and/or NameID is not allowed for SAML Response messages. Thus, SAML Response messages shall contain a<code> <saml EncryptedAssertion> </code>element in case encryption is used.
    • For Single Logout request messages<code> <saml EncryptedID> </code>element shall not be used. Instead transient NameIDs shall be used to hide the user identity.
    In order to make web authentication more robust, implementations should allow five (5) minutes of clock skew in both directions when interpreting timestamps in SAML assertions.[1] XML Signature Syntax and Processing Version 2.0, W3C Working Group Note 23 July 2015,https //www.w3.org/TR/xmldsig-core2/#sec-KeyInfo

    Structured Data Profile

    The Structured Data Profile provides standards and guidance for the structuring of web content on federated mission networks.

    Direct Messaging Services,

    Technical Services,

    User Applications,

    Web Hosting Services

    Candidate

    General formatting of information for sharing or exchange.

    XML shall be used for data exchange to satisfy those Information Exchange Requirements (IERs) within a FMN mission network instance that are not addressed by a specific information exchange standard. XML schemas and namespaces are required for all XML documents.

    Web Content Profile

    The Web Content Profile provides standards and guidance for the processing, sharing and presentation of web content on federated mission networks. Web presentation services must be based on a fundamental set of basic and widely understood protocols, such as those listed below. These recommendations are intended to improve the experience of Web applications and to make information and services available to users irrespective of their device and Web browser. However, it does not mean that exactly the same information is available in an identical representation across all devices: the context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Some services and information are more suitable for and targeted at particular user contexts. While services may be most appropriately experienced in one context or another, it is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations.

    Web Hosting Services

    Candidate

    Publishing information including text, multi-media, hyperlink features, scripting languages and style sheets on the network.

    Candidate

    Providing a common style sheet language for describing presentation semantics (that is, the look and formatting) of documents written in markup languages like HTML.

    To enable the use of web applications by the widest possible audience, web applications shall be device independent and shall be based on HTML5 standards and criteria for the development, delivery and consumption of web applications and dynamic websites. HTML5 contains new features for attributes and behaviors, plus a large set of associated technologies such as CSS 3 and JavaScript that allows more diverse and powerful Web sites and applications.Web applications will not require any browser plug-ins on the client side as some organizations or end user devices do not allow the use of Java Applets or proprietary extensions such as Silverlight (Microsoft), Flash (Adobe) or Quick Time (Apple). Implementers shall use open standard based solutions (HTML5 / CSS3) instead.These requirements are mandatory for all web content consumers (browsers) and are optional for web content providers. It is expected that in the future FMN Spiral Specifications they will also become mandatory for the web content providers.

    Web Feeds Profile

    The Web Feeds Profile provides standards and guidance for the delivery of content to feed aggregators (web sites as well as directly to user agents).

    Web Hosting Services

    Candidate

    Web content providers must support at least one of the two standards (RSS and/or Atom).

    Candidate

    Receivers of web content such as news aggregators or user agents must support both the RSS and the ATOM standard.

    RSS and Atom documents should reference related OpenSearch description documents via the Atom 1.0 link element, as specified in Section 4.2.7 of RFC 4287.The rel attribute of the link element should contain the value search when referring to OpenSearch description documents. This relationship value is pending IANA registration. The reuse of the Atom link element is recommended in the context of other syndication formats that do natively support comparable functionality.The following restrictions apply

    • The type attribute must contain the value application/opensearchdescription+xml.
    • The rel attribute must contain the value search.
    • The href attribute must contain a URI that resolves to an OpenSearch description document.
    • The title attribute may contain a human-readable plain text string describing the search engine.

    Web Platform Profile

    The Web Platform Profile provides standards and guidance to enable web technology on federated mission networks.

    Web Hosting Services

    Candidate

    HTTP MAY (only) be used as the transport protocol for CRL and AIA exchange between all service providers and consumers (unsecured HTTP traffic). HTTP traffic shall use port 80 by default.HTTPS MUST be used as the transport protocol between all service providers and consumers to ensure confidentiality requirements (secured HTTP traffic). HTTPS traffic shall use port 443 by default.

    Web Service Messaging Profile

    The Web Service Messaging Profile (WSMP) defines a set of service profiles to exchange a wide range of XML-based messages. WSMP is extensible and may be used by any Community of Interest (COI). It is based on publicly available standards and defines a generic message exchange profile based on the Request/Response (RR) and the Publish/Subscribe (PubSub) Message Exchange Pattern (MEP). WSMP is platform independent and can be profiled for different wire protocols such as SOAP. Other protocols like REST, JMS, AMQP, and WEBSocket will be profiled later. This profile is intended for software developers to implement interoperable "WSMP services" and "WSMP clients".

    C3 Taxonomy

    Candidate

    To enable plug-and-play interoperability a pre-defined minimum set of topics referenced and shared by multiple communities of interest is recommended. This TopicNamespace is included in Annex A Information Products - Detailed Definitions to the FMN Spiral 4 Procedural Instructions for Situational Awareness.The version of the WSMP Standard used with MIP4-IES (Version 4.3) is WSMP 1.3.2.

    Web Services Profile

    The Web Services Profile provides standards and guidance for transport-neutral mechanisms to address structured exchange of information in a decentralized, distributed environment via web services.

    C3 Taxonomy

    Candidate

    Candidate

    Provide the elements a web service needs to deliver a suitable UI service, such as remote portlet functionality.

    The preferred method for implementing web-services are SOAP, however, there are many use cases (mashups etc.) where a REST based interface is easier to implement and sufficient to meet the IERs.Restful services support HTTP caching, if the data the Web service returns is not altered frequently and not dynamic in nature. REST is particularly useful for restricted-profile devices such as mobile phones and tablets for which the overhead of additional parameters like headers and other SOAP elements are less. The foundational document of the REST architectural style may be found athttp //www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

    OAuth 2.0 Authorization Server Bootstrap Profile

    OAuth 2.0 Authorization Server Bootstrap Profile provides standards and guidance on how OAuth 2.0 Clients can obtain the necessary information required to interact with an OAuth 2.0 Authorization Server.

    Direct Messaging Services,

    Security Token Services,

    Technical Services,

    User Applications

    Candidate

    The OAuth 2.0 Authorization Server Metadata is retrieved from a well-known location.Alternatively, OAuth 2.0 Clients can configure some or all of this information in an out-of-band manner.As a minimum the OAuth 2.0 Authorization Server Metadata is recommended to contain the issuer, token_endpoint, jwks_uri and grant_types_supported fields.

    SAML 2.0 Bootstrap Profile

    The SAML 2.0 Bootstrap profile is based on the SAML2.0 standard.

    Direct Messaging Services,

    Security Token Services,

    Technical Services,

    User Applications

    Candidate

    Security Token Services Profile

    The Security Token Services Profile supports the exchange of SAML 2.0 assertions to support federated Identity and Access Management.

    Direct Messaging Services,

    Security Token Services

    Candidate

    Candidate

    How the SAML 2.0 Token has been retrieved from the local STS to be used at the federated STS is not a federation issue.The operations that are specified here are the minimal operations that SHALL be implemented by the STS in order to support the exchange of SAML Security Tokens between federation partners. Other operations that are defined by the relevant specification MAY be implemented by the STS in accordance with those specifications.

    • Issue
    Based on the credential provided/proven in the request, a new token is issued, possibly with new proof information.Providers and Consumers SHALL use the following WS-Addressing actions to enable specific processing context to be conveyed to the recipient -http //docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Issue-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinalProviders and Consumers SHALL use the following URI as a wst RequestType element -http //docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    • Renew
    A previously issued token with expiration is presented (and possibly proven) and the same token is returned with new expiration semantics.Providers and Consumers SHALL use the following WS-Addressing actions to enable specific processing context to be conveyed to the recipient -http //docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Renew-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/RenewFinalProviders and Consumers SHALL use the following URI as a wst RequestType element -http //docs.oasis-open.org/ws-sx/ws-trust/200512/Renew

    OAuth 2.0 Assertion Grant Profile

    The OAuth 2.0 Assertion Grant Profile supports the exchange of SAML 2.0 or JWT assertions for Access Tokens to be used to access federated protected resources (i.e. REST-based web services)

    Direct Messaging Services,

    Security Token Services

    Candidate

    Candidate

    A federated Authorization Server supports this profile by providing a Security Token Service Endpoint (HTTP collection resource identified by the request URI) for a Client to make a request to exchange a Security Token (SAML or JWT assertion) from its own domain for a new Security Token (Access Token) that can be used to support chaining web services and access to federated protected resources.How the Client receives a SAML or JWT assertion is out of scope for this profile.The SAML assertion, if used, shall be compliant with the structure specified in the SIP for Middleware.The JWT assertion, if used, shall be compliant with the structure specified in the SIP for Middleware.When complying with this profile the Client must set the fields of its assertion grant token requests as follows

    • If the Client is exchanging a SAML assertion for an Access Token the grant_type parameter value is urn ietf params oauth grant-type saml2-bearer and the assertion parameter value is the SAML assertion.
    • If the Client is exchanging a JWT assertion for an Access Token the grant_type parameter value is urn ietf params oauth grant-type JWT-bearer and the assertion parameter value is the JWT assertion.
    • The resource parameter must be used to indicate the federated service or protected resource where the resultant Access Token is intended to be used.
    The Authorization Server ensures that the assertion provided by the Client is valid and not expired.When complying with this profile the Authorization Server must set the fields of the assertion grant token response as follows
    • The access_token parameter value is the Access Token issued as part of the request.
    • The token_type parameter value is Bearer.
    Note If supporting the OAuth 2.0 DPoP Profile the token_type parameter value is DPoP. Note If supporting the OAuth 2.0 HTTP Message Signatures Profile token_type parameter value is PoP.The Access Token format may be compliant with the OAuth 2.0 Access Token Profile.

    SAML 2.0 Assertion Profile

    The SAML 2.0 Assertion Profile facilitates interoperability for distributing Claims, structured in SAML 2.0, between federated entities.

    Direct Messaging Services,

    Security Token Services

    Candidate

    The list of Claims to be provided in the SAML assertions has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Middleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support SAML assertions.

    JSON Web Token Assertion Profile

    The JSON Web Token Assertion Profile facilitates interoperability for distributing Claims, structured as a JWT assertion, between federated entities.

    Direct Messaging Services,

    Security Token Services

    Candidate

    The list of Claims to be provided in the JWT assertion has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Middleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that JSON Web Tokens.

    OAuth 2.0 Access Token Profile

    The OAuth 2.0 Access Token Profile facilitates interoperability for distributing Claims, structured as a JWT bearer Access Token, between federated entities.

    Direct Messaging Services,

    Security Token Services

    Candidate

    The list of Claims to be provided in the JWT access token has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Midleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support OAuth 2.0 Access Tokens in JSON Web Token format.

    Secure SOAP-based Request Response Profile

    The Request-Response Message Exchange Pattern (MEP) involves a consumer sending a request message to a provider, which receives and processes the request, ultimately returning a message in response. The Secure SOAP-based Request Response profile provides the key elements of security infrastructure required to implement uniform, consistent, interoperable and effective protection of the resources exposed by partners in a federated environment.

    Direct Messaging Services,

    Technical Services,

    User Applications

    Candidate

    The recommendations provided in the Service Interface Profile (SIP) Securing SOAP-based Request-Response Web Services are intended to give directives, along with clarifications and amendments on the use of securing SOAP-based Request-Response web services.

    Secure REST-based Request Response Profile

    The Secure REST-based Request Response profile supports consistent and compliant use of the uniform interface offered by HTTP for accessing a federated protected resource (REST-based Web Service). The Client makes a protected access request to the Resource Server (authority part referred to within the request URI) presenting the Access Token in the Header of the HTTP request. If the Access Token is successfully validated the Resource Server processes the authorised request and the result is returned to the Client.

    Direct Messaging Services,

    Technical Services,

    User Applications

    Candidate

    The Access Token is encoded in the HTTP Authorization entity-header by the Client.The auth-scheme parameter for the HTTP Authorization entity-header is specified to indicate the type of Access TokenAs a minimum for complying with this profile, the auth-scheme parameter value for the HTTP Authorization Header is Bearer.Note If supporting the OAuth 2.0 DPoP Profile the auth-scheme parameter value is DPoP).Note If supporting the OAuth 2.0 HTTP Message Signatures Profile the auth-scheme parameter value is PoP).In the cases where a Client receives a 401 status error code, that Client SHALL request an Access Token from the Authorization Server as specified in PRF-139 OAuth 2.0 Assertion Grant Profile.

    SOAP-Based Request Response Profile

    The SOAP-Based Request Response Profile defines the standard interface for sending a SOAP Message from a Consumer to a Provider and returning the results. The profile covers only the call from a Consumer to the Provider using SOAP, and the response from the Provider. This details the structuring of the Message.

    Direct Messaging Services,

    Technical Services,

    User Applications

    Candidate

    Providers must reject unsupported versions of SOAP.Upon request, Providers are to make available to authorized Consumers a Web Service Description Language (WSDL) describing the service interface.

    REST-Based Request Response Profile

    The REST-Based Request Response Profile provides the implementation details for REST-based Request-Response Message Exchange Pattern (MEP). The profile covers only the call from a Consumer to the Provider using HTTP, and the response from the Provider.

    Direct Messaging Services,

    Technical Services,

    User Applications

    Candidate

    Candidate

    Candidate

    Candidate

    Candidate

    Candidate

    When a Consumer asks a Provider for a resource, the Provider is expected to respond with the best possible representation for that resource, given the Consumer's preferences.This profile places no constraints on the type of data that can be exchanged between Consumers and Providers in the body of an HTTP Message request or response. However, it is recommended that XML or JSON be used as the MIME media type exchanged between Consumers and Providers in the body of an HTTP Message request or response.HTTP requests from the Consumers using the HTTP verbs GET, HEAD, PUT and DELETE are honoured as idempotent requests by the Provider.Create, Read, Update and Delete (CRUD) are the main operations used when dealing with information in persistent storage.While REST/HTTP has similar operations, the correspondence with CRUD is not a direct one-to-one match, specifically for the Create and Update methods, but also due to the granularity of HTTP resources.REST offers generic uniform HTTP interface methods (HTTP verbs RFC 7231 (IETF)]) that apply to the request URI entity which is the URI specified on the HTTP request.It is RECOMMENDED that RESTful web services use the prescribed HTTP verbs for Create, Read, Update and Delete (CRUD) operations as specified in below

    • Get Retrieves an information object identified by the request URI.
    • Put Creates a new information object identified by the request URI. (Updates an information object identified by the request URI. It is recommended that the update operation is a complete update of the information object identified by the request URI.)
    • Post Updates an information object identified by the request URI. (The request URI may create new additional information objects; update additional information objects; or perform a variety of create or updates of information objects.)
    • Patch Creates a partial update of an information object identified by the request URI. (Updates an information object identified by the request URI. It is recommended that the update operation includes a set of instructions or description of changes describing what needs to be modified in the information object identified by the request URI. The entire set of instructions are required to be applied atomically.)
    • Delete Deletes an information object identified by the request URI.
    • Head Retrieves the same HTTP header fields and HTTP status code as the GET HTTP verb without the representation of the information object identified by the request URI.
    • Options RESTful web services can use this HTTP verb to determine the list of HTTP verbs supported by the information object identified by the request URI.
    A fundamental axiom of the architecture of the World Wide Web is that URIs should be opaque to Consumers i.e. a Consumer should not need to pick apart a URI to determine what it means or what to do with it.Consumers must not be capable of gathering sensitive information about the information object or the Communications and Information System (CIS) containing the information object through aggregation techniques carried out on the URI.Where metadata about the resource needs to be conveyed, it must be done using the standard HTTP headers and the rest of the information a resource conveys is carried in the representation of the resource itself.In environments that typically have high latency and bandwidth constraints Consumers and Providers may support HTTP caching for the HTTP verbs GET, PUT and HEAD.Cached contents must be protected.Caching of sensitive information is prohibited. A Consumer shall indicate to all entities in the HTTP request/response chain that information shall not be cached by inserting the HTTP header cache-control with the additional directive of no-store. or no-cache. As such, information must not be cached when a HTTP request contains a HTTP Cache-Control Header field with the values no-store and no-cache.

    Direct Notification Publish Subscribe Profile

    This profile provides provides standards and guidance for Publish-Subscribe components (Producer, Subscription Manager and Consumer) based on WS-BaseNotification.

    Direct Messaging Services,

    Technical Services,

    User Applications

    Candidate

    Candidate

    Brokered Notification Publish Subscribe Profile

    The Brokered Notification Publish Subscribe Profile provides standards and guidance based on WS-BrokeredNotification.

    Direct Messaging Services,

    Message Brokering Services,

    Technical Services,

    User Applications

    Candidate

    Candidate

    In a brokered environment it is possible to generate a situation, where notifications may circulate in a set of brokers. This behaviour has to be solved with organisational methods if no additional features are added to a brokered environment.

    OAuth 2.0 DPoP Profile

    DPoP, an abbreviation for Demonstrating Proof-of-Possession at the Application Layer, is an application-level mechanism for sender-constraining OAuth access and refresh tokens. It enables a client to demonstrate proof-of-possession of a public/private key pair by including a "DPoP" header in an HTTP request. The OAuth 2.0 Proof of Possession Profile is based on the internet draft ID OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer1.

    Direct Messaging Services,

    Security Token Services,

    Technical Services,

    User Applications

    Candidate

    Service profile OAuth 2.0 DPoP Profile does not refer to any standard.

      Proof-of-Possession IS supported between the Client and the Authorization Server; and, Client and Resource Server.

      OAuth 2.0 HTTP Message Signatures Profile

      The OAuth 2.0 framework provides methods for Clients to get delegated access tokens as bearer tokens from an Authorization Server for accessing protected resources. The OAuth 2.0 HTTP Message Signatures Profile defines an access token type that binds the access token to a cryptographic key known to the Client1. The Client uses HTTP Message Signatures2to digitally sign requests using its key, thereby proving Proof-of-Possession to present the access token to the Resource Server.

      Direct Messaging Services,

      Security Token Services,

      Technical Services,

      User Applications

      Candidate

      Service profile OAuth 2.0 HTTP Message Signatures Profile does not refer to any standard.

        Communications Transmission Standards Profiles

        Wireless NB LOS Standards Profiles

        Service Standard Implementation Guidance

        NATO Narrowband waveform for VHF/UHF Radios edition 1

        The Narrowband Waveform (NBWF) provides ground–ground interoperability over air between troops/platforms of different nations at the tactical battlefield using the military VHF and UHF band (30 - 500 MHz).

        Wireless LOS Mobile Narrowband Transmission Services

        Candidate

        NBWF - HEAD STANAG

        Candidate

        NBWF - Physical Layer

        Candidate

        NBWF - Link Layer

        Candidate

        NBWF - Network Layer

        For FMN Spiral 5, NATO Narrowband Waveform Profile A shall be implemented according to Annex G of AComP 5630, i.e. one-hop voice and data wireless communication using PHY modes N1 and NR. Other PHY modes and profiles are optional.

        SATURN Waveform edition 4

        A narrow-band waveform with Fast Frequency Hopping EPM Mode for UHF Radio. A/G/A use, typically used voice-only.

        Wireless LOS Mobile Narrowband Transmission Services

        Candidate

        SATURN - a fast frequency hopping EPM mode for UHF radio. AComP-4372 EDITION A

        A/G/A use, typically used voice-only.

        Wireless NB BLOS Standards Profiles

        Service Standard Implementation Guidance

        Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF) Phase 1 edition 1

        This profile specifies the interoperability and performance characteristics of terminal equipment that will operate over NATO or national UHF satellite systems.

        Wireless BLOS Mobile Narrowband Transmission Services

        Candidate

        Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF).

        Wireless WB LOS Standards Profiles

        Service Standard Implementation Guidance

        NATO HDRWF (ESSOR) Standards Profile edition 1

        NATO HDRWF (ESSOR) is a wideband waveform standard originated from the EU ESSOR program and community.

        Wireless LOS Mobile Wideband Transmission Services

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards.

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards System Description

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards System Design

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards Physical Layer Specifications

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards MAC Layer Specifications

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards LLC Layer Specifications

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards NET Layer Specifications

        Candidate

        These standards define NATO HDRWF based on ESSOR Standards MGT Layer Specifications

        NATO High Capacity Data Rate Waveform (NHCDRWF) edition 1

        Wideband UHF waveform

        Wireless LOS Mobile Wideband Transmission Services

        Candidate

        NHCDRWF - Head Specification

        Candidate

        NHCDRWF - Link/Network Layer Specification

        Candidate

        NHCDRWF - Modem Specification

        Last updated on Thu, 21 Mar 2024 15:51:28 UTC
        This page is work in progress