Title: SV4 - Security ASO clarifications PDR Reference: M2090006 Originator Reference: SB3W0615 UL-1 to UL-7 SARPs Document Reference: Sub-Volume IV 4.3.3.7, 4.8 CAMAL Document Reference: - P/OICS Document Reference - Status: ACCEPTED Impact: C PDR Revision Date: 22 Oct 2002 (UL-9 to UL-16 added) 23 Sep 2002 (Accepted, UL-8 added) 16 Sep 2002 (SUBMITTED) Submitting State/Organization: CIVAL Consulting Ltd Submitting Author Name: A J Kerr Submitting Author E-mail Address: tony.kerr@cival.co.uk Submitting Author Supplemental Contact Information: Tel: +44 (0)1252 724386 SARPs Date: Doc 9705 Ed 3 (Jul 02) P/OICS Date: - SARPs Language: English Summary of Defect: UL-1) There is a parameter type mismatch between the Security ASO in SV4 and SSO in SV8. Calling / Called Entity IDs are a choice of (24-bit address, facility designator or PSAP address) in ULCS, whereas SSO expects AP Title or PSAP Address. Although these are only abstract parameters, the various parts of Doc 9705 should be consistent; ULCS should be clarified wherever SSO is invoked. UL-2) In 4.8.5.2.2.2.1.a) the presence of atnCertificates should not be assumed in the received ATNEstablish. The field may be absent, and *will* be absent in CM Logon indication, for example. UL-3) The Security ASO lower interface is not cleanly specified. There is a need to pass additional (local) protocol control information in addition to SESE APDUs, and this should be made explicit. (This is probably due to over-zealous excision of the former SEND-SEI service). Also, there are vague statements such as 4.8.5.2.2.9.1 that should be clarified. UL-4) Table 4.3-36 states that Calling Presentation Address is "Not Used". However, non-ATS applications will be using the PSAP Address form of identification exclusively, and must be accommodated. Also, in 4.8.3.4, the SA-SEND Entity IDs are AP-Title types. The alternative PSAP Address form should be accommodated. UL-5) A receiving entity should verify that the called and calling entityIDs are as expected. On receiving SETR APDU, the DS CF should validate that the called entityID in fact corresponds to itself. ULCS should verify received entity IDs in the CM Logon Response. (ACSE Responding AP Title. Could possibly be done by local knowledge of own ID when calling SSO-SignCheck?). UL-6) In 4.8.5.2.2.3.1.d) 2), the ASN.1 identifier atnCertificate should be atnCertificates. Also, in the same bullet, clarify as follows: "the compressed key agreement public key certificate path retrieved in b) as the only element of the atnCertificates field of the ATNEstablish." In bullet b), clarify as follows: "if the Called Entity ID refers to a ground entity, then get the compressed key agreement public key certificate path from the airborne peer's State CA to ground entity's key agreement public key by activating the SSO-GetCertificatePath function..." (See also related PDR M2090002 on SSO-GetCertificatePath parameters). UL-7) In the Dialogue Service description, it should be clarified that the abstract value "Secured Dialogue Supporting Key Management" is only applicable to air-ground dialogues; secure ground-ground dialogues should only use the value "Secured Dialogue." The description of SA-SEND in 4.8.1 Note 5 does not include the ground -ground case. UL-8) Reference is made to "the atnEstablishSE object identifier" and to "the atnProtectSignSE object identifier" in several places in 4.8.5.2. In each of these cases, the Security Exchange is defined in 4.8.4.1.1 using the LOCAL form of identifier. Therefore, it is incorrect to refer to OIDs for these items. UL-9) SE-P-ABORT indication issued by the Security Exchange Service Element is not handled correctly in the Security ASO. The current handling in 4.8.5.2.2.5.1 is limited to ATNEstablish, whereas SE-P-ABORT indication could occur whenever SESE detects a problem with a security exchange, not just when processing an atnEstablish SEI. The handling is to call SSO-Stop, abort the dialogue and provide notification to the DS-User. Any associated SEPA APDU is not handled. UL-10) 4.8.2.1.2 states "in the event of an SA-User invoking a Security ASO service primitive when the Security ASO is not in a state specified in 4.8.5, the SA-User shall be notified by local means." However, 4.8.5 does not specify any states; the Security ASO is currently stateless. UL-11) If an SSO function fails to perform a requested security operation then 4.8.5.2.1.1 refers to exception handling procedures as described in 4.8.5.3. However, 4.8.5.3 describes all exceptions under the "Unrecoverable System Error" heading. An SSO error indication is not necessarily a (local) system error and may not be unrecoverable. UL-12) During exception handling by the Security ASO, 4.8.5.3.1.1 b) states "behave as though an SE-U-ABORT indication has been received." However, it is not specified what SE-U-ABORT ind parameter values are assumed. Different assumed parameters would result in different error handling. UL-13) In 4.8.5.2.2.4.1, "SE-TRANSFER Indication Fatality indicator" should be "SE-U-ABORT Indication Fatality Indicator" UL-14) In 4.8.5.2.2.5.1, "SE-TRANSFER Indication Fatality indicator" should be "SE-P-ABORT Indication Fatality Indicator" UL-15) Inaccurate predicate definitions in Table 4.3-5. The p1 definition states: "i.e. the CF which issued an A-ASSOCIATE request primitive", but p1 is used when a SASO-APDU is received in STA1 BEFORE A-ASSOCIATE req is issued. The p2 definition states: "i.e. the CF issued an A-RELEASE request primitive", but p2 is used when a SASO-APDU is received in STA3 BEFORE A-RELEASE req is issued. UL-16) The Scope and Structure in 4.8.1 Note 2 does not mention section 4.8.6. UL-17) 4.8.3.3. Note 2 wrongly implies that SA-START must be invoked before SA-SEND for all applications. UL-18) Table 4.8-2 has the SA-SEND User Data indication as "U(=)"; it should be "C(=)" UL-19) Table 4.8-14 has "Called Entity ID" instead of "Called Peer" as an input parameter to SSO-Stop. UL-20) In Tables 4.8-7, 4.8-13, 4.8-17, the value of "Item identifier" is set to the "abstract value that identifies an atnEstablish (or atnProtectSign) security exchange item" In fact, with the ATN security exchanges specified in 4.8.4, all security exchanges only have a single SE item, and all item identifiers have the INTEGER value 1. Assigned SME: Sub-Volume IV SME Proposed SARPs amendment: UL-1) UL-2) UL-3) UL-4) In 4.3.3.7.2.2.1, bullet b) [Accommodate the fact that there may not be a Calling Peer ID] In 4.3.3.7.2.2.1, Table 4.3-36, row "Calling Presentation Address" REPLACE "Not used" WITH "Derived as in b) above" In 4.8.3.4, Note 1, REPLACE: "The initiating SA-user is identified by specifying an AP-Title in the SA-SEND request primitive." WITH: "Name or address (AP Title or PSAP Address) identifying the application in which this Security ASO invocation resides." In 4.8.3.4, Note 2, REPLACE: "The SA-user identifies the intended peer SA-User by specifying an AP-Title in the SA-SEND request primitive." WITH: "Name or address (AP Title or PSAP Address) identifying the application in which the intended remote peer Security ASO invocation resides." [There may be other cases] UL-5) UL-6) In 4.8.5.2.2.3.1.b), REPLACE: "if the Called Entity ID refers to a ground entity, then get the key agreement public key certificate path of the local system by activating the SSO-GetCertificatePath function..." WITH "if the Called Entity ID refers to a ground entity, then get the compressed key agreement public key certificate path from the airborne peer's State CA to ground entity's key agreement public key by activating the SSO-GetCertificatePath function..." In 4.8.5.2.2.3.1.d) 2), REPLACE: "the key agreement public key certificate retrieved in b) as the atnCertificate field of the ATNEstablish." WITH: "the compressed key agreement public key certificate path retrieved in b) as the only element of the atnCertificates field of the ATNEstablish." UL-7) In 4.8.1.1 Note 5, REPLACE: This protection is based on the appending of a Message Authentication Code (MAC) to the data. WITH: This protection is based on the appending of a Message Authentication Code (MAC) or, in the ground-ground case, a digital signature, to the data. In 4.8.1.1 Note 5, bullet a) REPLACE: which computes an exchange key with the session key and security parameters, WITH: which for air-ground communication computes an exchange key with the session key and security parameters and uses this to compute the MAC value, or for ground-ground communication computes a digital signature with the sender's private authentication key, In 4.8.1.1 Note 5, bullet b) 2) REPLACE: the MAC computed from the SA-user data computed with the exchange key and the security parameters, and WITH the MAC or digital signature, and In 4.8.1.1 Note 5, bullet c REPLACE: checks that the received MAC value is correct WITH checks that the received MAC value or digital signature is correct. UL-8) In 4.8.5.2.2.1.1, Table 4.8-7, REPLACE "the atnEstablishSE object identifier" WITH "the atnEstablishSE identifier" In 4.8.5.2.2.2.1, REPLACE "the atnEstablishSE object identifier" WITH "the atnEstablishSE identifier" In 4.8.5.2.2.3.1, Table 4.8-13, REPLACE "the atnEstablishSE object identifier" WITH "the atnEstablishSE identifier" In 4.8.5.2.2.2.2, REPLACE "the atnEstablishSE object identifier" WITH "the atnEstablishSE identifier" In 4.8.5.2.2.2.3, REPLACE "the atnProtectSignSE object identifier" WITH "the atnProtectSignSE identifier" In 4.8.5.2.2.6.1, Table 4.8-17, REPLACE "the atnProtectSignSE object identifier" WITH "the atnProtectSignSE identifier" UL-9 UL-10) In 4.8.2.1.2, REPLACE: "In the event of an SA-User invoking a Security ASO service primitive when the Security ASO is not in a state specified in 4.8.5, the SA-User shall be notified by local means." WITH: "In the event of an SA-User invoking a Security ASO service primitive when the Security ASO is not able to process it (e.g. SA-SEND request issued before SA-START exchange has completed), the SA-User shall be notified by local means." UL-11) In 4.8.5.3, DELETE the sub-heading: "4.8.5.3.1 Unrecoverable System Error" and RENUMBER 4.8.5.3.1.1 as 4.8.5.3.1 UL-12) In 4.8.5.3.1.1 b), REPLACE: "behave as though an SE-U-ABORT indication has been received." WITH "behave as though an SE-P-ABORT indication with Fatality Indicator set to "Fatal" has been received." UL-13) In 4.8.5.2.2.4.1, REPLACE "SE-TRANSFER Indication Fatality indicator parameter" WITH "Fatality Indicator parameter" UL-14) In 4.8.5.2.2.5.1, REPLACE "SE-TRANSFER Indication Fatality indicator parameter" WITH "Fatality Indicator parameter" UL-15) (p1 case: should be "the CF received a D-START request from the local DS-user") (p2 case: should be: "the CF received a D-END request from the local DS-User") (there may be other cases...) UL-16) In 4.8.1 Note 2, add a new bullet item: f) 4.8.6: SESE PROFILE REQUIREMENTS specifies the functional profile for the Security Exchange Service Element (SESE). UL-17) In 4.8.3.3, Note 2, REPLACE: The SA-START service must first have been successfully completed to establish the security relationship between the peers. WITH For air-ground communication, the SA-START service must first have been successfully completed via a Key Management exchange by this or another application to establish the required security knowledge between the end systems. UL-18) In 4.8.3.4, Table 4.8-2, row "User Data", column "Ind", REPLACE "U(=)" WITH "C(=)" UL-19) In 4.8.5.2.2.4.1, Table 4.8-14 REPLACE "Called Entity ID" WITH "Called Peer" UL-20) In 4.8.5.2.2.1.1, Table 4.8-7, row "Item identifier", REPLACE "abstract value that identifies an atnEstablish security exchange item" WITH "Value 1" In 4.8.5.2.2.3.1, Table 4.8-13, row "Item identifier", REPLACE "abstract value that identifies an atnEstablish security exchange item" WITH "Value 1" In 4.8.5.2.2.6.1, Table 4.8-17, row "Item identifier", REPLACE "abstract value that identifies an atnProtectSign security exchange item" WITH "Value 1" Impact on interoperability: PDR Validation Status: SME Recommendation to CCB: Await proposed resolution CCB Decision: