Title: SV2 - D-START cnf "Security Requirements" parameter PDR Reference: M0120001 Originator Reference: M01200x1 SARPs Document Reference: CM SARPs 2.1.3.3.10.3, 2.1.3.7.7.3, 2.1.3.5.6.5, 2.1.3.9.9.2, 2.1.5.3.2.3.1, 2.1.5.3.3.3.1.1, 2.1.5.3.3.3.1.2, 2.1.5.3.3.3.1.3, 2.1.5.3.3.2.1.1, 2.1.5.3.3.2.2.1, 2.1.5.3.3.6.1, 2.1.5.3.3.6.2,2.1.5.3.3.7.1, 2.1.5.3.3.7.2, 2.1.5.3.3.10.1, 2.1.6.2.3.2, 2.1.7.2.2.5, 2.1.7.2.2.8, 2.1.7.2.2.7, 2.1.7.2.2.9, 2.1.7.2.3.1, 2.1.7.2.6.1 ADS SARPs 2.2.1.5.3.15.6 section and note & 2.2.2.5.3.4.6 section and note CPDLC SARPs notes to 2.3.5.3.3.1, 2.3.5.3.3.2, 2.3.5.3.3.3, 2.3.5.3.3.4 FIS SARPs 2.4.5.3.12.7 section and note Status: ADOPTED (except CM 1h and 1r) Impact: B (CM) C(other) PDR Revision Date: 30/01/02 (RESOLVED -> ADOPTED) 07/03/01 (PROPOSED -> RESOLVED) 05/03/01 (ACCEPTED -> PROPOSED, CPDLC part added) 22/02/01 (add CM input) 20/02/01 (SUBMITTED -> ACCEPTED) PDR Submission Date: 20/12/00 Submitting State/Organization: STNA Submitting Author Name: Picard, F Submitting Author E-mail Address: picard_frederic@stna.dgac.fr Submitting Author Supplemental Contact Information: tel. +33.5.62.14.55.33 fax. +33.5.62.14.54.01 SARPs Date: Doc 9705 Draft Ed 3 SARPs Language: English Summary of Defect: 1/ SG-B3 (ULCS) changed in version 2 the D-START confirmation "Security Requirements" parameter from optional to mandatory. As a consequence, the DSP provides always the ASE with the "Security Requirement" parameter, even when the peer is a version 1 system. The current version 2 ASE SARPs specify what the ASEs must do upon receipt of a D-START confirmation without security parameter. Since this can not happen anymore, the SARPs must be changed accordlingly. 2/ In addition, the check of the D-START confirmation security parameter is applicable to version 2 ASE only. This is not explictly indicated in the FIS and ADS SARPs. 3/ CM had an additional problem with the logon and update services. Since both of these services have different APDUs depending on whether the peer is a version 1 or version 2 CM, there needs to be a method to determine what the peer is. Previously, a check was done on the received D-START Security Requirements parameter. If the parameter was not present, then it was known that the peer was a CM version 1, as a CM version 2 must provide the parameter. However, in light of 1/ above, this assumption is no longer valid, since the local version 2 dialogue service will always provide a Security Requirements parameter. For the CM-logon, the CM-ground-ASE will know the peer's version number since an association is maintained with the peer for the duration of the service. Therefore, the ASE is capable of knowing the peer's version and can choose the proper PDU accordingly. This is also the case for the CM-update when a dialogue is being maintained. However, for the CM-update when a dialogue is not maintained, it is necessary for the CM-ground-user to explicitly indicate to its ASE which APDU to use. This was done by using the addition of a Security Required parameter in the CM-update Request primitive. If the parameter is provided, then the ASE knows to use the version 2 APDU. If the parameter is not provided, then the ASE knows to use the version 1 APDU. Assigned SME: Sub-Volume II SME Proposed SARPs amendment: 1-CM 1a) 2.1.3.3.10.3 Change "When the CM-air-user requires an unsecure CM-logon service, the..." to "When the CM-air-user requires an unsecure CM-logon service or the CM-air-user is communicating with a CM version 1 ground system, the..." 1b) 2.1.3.7.7.3 Change "When the CM-ground-user requires an unsecure CM-contact service, the..." to "When the CM-ground-user requires an unsecure CM-contact service or if the CM-ground-user is communicating with a version 1 CM aircraft, the..." 1c) Add new sections: 2.1.3.5.6.5 When communicating with a version 1 CM aircraft, the CM-ground-user shall be prohibited from providing the Security Required parameter. 1d) 2.1.3.9.9.2 Change "When the sending CM-ground-user requires an unsecure CM-forward service , the..." to "When the sending CM-ground-user requires an unsecure CM-forward service or if communicating with a version 1 CM ground system, the..." 1e) 2.1.5.3.2.3.1. Delete "and the D-START confirmation Security Requirements parameter is not provided" 1f) Notes to 2.1.5.3.2.3.1, 2.1.5.3.3.3.1.1, 2.1.5.3.3.3.1.2, 2.1.5.3.3.3.1.3: Replace "...may either be equal to that value (if communicating with a CM version 2 peer) or may not be provided (if communicating with a CM version 1 peer)" with "...will be equal to that value. A CM version 1 peer will not set the Security Requirements parameter. However, the local upper layers will convert the absent parameter into a "No security" value. Therefore, the check to see that the received D-START confirmation Security Requirements parameter value is the same as the D-START request Security Requirements parameter value will work for CM version 2 communicating with both CM version 2 and CM version 1 peers." 1g) 2.1.5.3.3.2.1.1, 2.1.5.3.3.2.2.1 Note: Change "...is not set in the case..." to "...is not explicitly set by the CM-ground-ASE in the case..." 1h) 2.1.5.3.3.6.1: Change "...and, if CM version 2, the Security Requirements parameter was not provided in the D-START indication, the..." to "...and, if version 1 CM or version 2 CM communicating with a version 1 CM, the..." 1i) 2.1.5.3.3.6.2: Change "For CM version 2, upon receipt of a CM-logon service response, if the CM-ground-ASE is in the LOGON state and the Security Requirements parameter was provided in the D-START indication, the..." to "For a version 2 CM not communicating with a version 1 CM, upon receipt of a CM-logon service response, if the CM-ground-ASE is in the LOGON state, the..." 1j) 2.1.5.3.3.7.1a): change "create a CMGroundMessage..." to "if version 1 CM, or if version 2 CM and the Security Required parameter is not provided, create a CMGroundMessage..." 1k) 2.1.5.3.3.7.1b) Insert new b), re-lettering existing text: if version 2 CM and the Security Required parameter is provided, create a CMGroundMessage APDU with a cmSecureUpdate APDU-element based on the CM-update Update Information parameter value, 1l) 2.1.5.3.3.7.2a): Change "if the ground system is maintaining a dialogue with a version 1 CM aircraft peer, create a..." to "if version 1 CM, or if version 2 CM emulating a version 1 CM, create a..." 1m) 2.1.5.3.3.7.2b): Change "for CM version 2, if the ground system is maintaining a dialogue with a version 2 CM aircraft peer, create a..." to "if CM version 2 not emulating a CM version 1, create a..." 1n) 2.1.5.3.3.10.1b)5): Change "if CM version,..." to "if CM version 2 and the Security Required parameter is provided,..." 1o) 2.1.6.2.3.2: Delete Note 2; change "Note 1" to "Note" 1p) 2.1.7.2.2.5: Change "For CM version 2, upon receipt of a CM-logon service indication with the Security Required parameter not provide or for CM version 1, upon receipt of a CM-logon service indication, the CM-ground-user..." to "Upon receipt of a CM-logon service indication from a CM version 1 peer, the CM-ground-user..." 1q) 2.1.7.2.2.5 Note: Add the following to the existing text: The CM-ground-user can determine the version of the peer by an indication of the Version Number parameter in the CM-logon indication if the CM-air-ASE version is lower than the CM-ground-ASE version (as is the case for a CM version 2 CM-ground-ASE communicating with a version 1 CM-air-ASE), or by the absence of the Version Number parameter in the CM-logon indication if the CM-air-ASE version is the same as the CM-ground-ASE version (as is the case for a version 1 CM-ground-ASE communicating with a version 1 CM-air-ASE or a version 2 CM-air-ASE in emulation mode). 1r) 2.1.7.2.2.7 Change "Upon receipt of a CM-logon service indication with the Security Required parameter provided with the value "No security", the..." to "For CM version 2, upon receipt of a CM-logon service indication with the Security Required parameter provided with the value "No security" and when communicating with a version 1 CM peer, the..." 1s) 2.1.7.2.2.8, 2.1.7.2.2.9: Change "For version 1 CM,..." to "When communicating with a CM version 1 peer,..." 1t) 2.1.7.2.3.1: Insert new note as follows, and change existing "Note.-" to "Note 2.-": Note 1. - This applies to both CM version 1 and CM version 2. 1u) 2.1.7.2.6.1 Add note as follows: Note.- This applies to both CM version 1 and CM version 2 in emulation mode. 2-ADS 2a) change in 2.2.1.5.3.15.6 from: and with a parameter value containing an abstract value equal to the abstract value set in the D-START request parameter: to: and, in version 2, with a parameter value containing an abstract value equal to the abstract value set in the D-START request parameter: 2b) Change the note to 2.2.1.5.3.15.6 from: To: 3-ARF 3a) change in 2.2.2.5.3.4.6 from: and the parameter value containing an abstract value equal to the abstract value set in the D-START request parameter: to: and, in version 2, the a parameter value containing an abstract value equal to the abstract value set in the D-START request parameter: 3b) Change the note to 2.2.2.5.3.4.6 from: To: 4-CPDLC Change note to section 2.3.5.3.3.1 from: Change note to section 2.3.5.3.3.2 from: Change note to section 2.3.5.3.3.3 from: Change note to section 2.3.5.3.3.4 from: Note.- For CPDLC version 2, if a secure D-START request was issued (i.e. the Security Requirements parameter was set to "Secured exchange") then the D-START confirmation Security Requirements parameter must be equal to that value. If an unsecure D-START request was issued (i.e. the Security Requirements parameter was set to "No security") then the D-START confirmation Security Requirements parameter may either be equal to the value (if communicating with a CPDLC version 2 peer) or may not be provided (if communicating with a CPDLC version 1 peer). To: Note.- For CPDLC version 2, if a secure D-START request was issued (i.e. the Security Requirements parameter was set to "Secured exchange") then the D-START confirmation Security Requirements parameter must be equal to that value. If an unsecure D-START request was issued (i.e. the Security Requirements parameter was set to "No security") then the D-START confirmation Security Requirements parameter may either be equal to that value. A CPDLC version 1 will not set the Security Requirements parameter. However, the local upper layers will convert the absent parameter into a "No security" value. Therefore, the check to see that the received D-START confirmation Security Requirements parameter value is the same as the D-START request Security Requirements parameter value will work for ARF version 2 communicating with both CPDLC version 2 and CPDLC version 1 peers. 5-FIS 5a) change in 2.4.5.3.12.7 from: and with a parameter value containing an abstract value equal to the abstract value set in the D-START request parameter, to: and, in version 2, with a parameter value containing an abstract value equal to the abstract value set in the D-START request parameter, 5b) Change the note to 2.4.5.3.12.7 section from: To: Impact on interoperability: None. The changes clarify how version1/version2 interoperability issues during the dialogue establishment phase. PDR Validation Status: level A: SG-A2 analysis and inspection SME Recommendation to CCB: PROPOSED CCB Decision: atnp_ccb_chair: SUBMITTED (20/12/00) atnp_ccb_chair: ACCEPTED (20/02/01) CCB-13/1 (Honolulu): PROPOSED (05/03/01) CCB-13/2 (Honolulu): RESOLVED (07/03/01)