Title: ULCS CF State Table - Error Cases for Security ASO PDR Reference: M2020003 Originator Reference: US-SV4-02-03 SARPs Document Reference: 4.8, 4.3 Status: FORWARDED Impact: C PDR Revision Date: 14 Mar 2002 (ACCEPTED -> FORWARDED) 28 Feb 2002 (SUBMITTED -> ACCEPTED) PDR Submission Date: 14/02/2002 Submitting State/Organization: USA Submitting Author Name: James Moulton Submitting Author E-mail Address: moulton@ons.com Submitting Author Supplemental Contact Information: 22636 Glenn Dr Suite 305 Sterling, VA 20164 USA SARPs Date: Draft Edition 3 (Jan 2002) SARPs Language: English Summary of Defect: The CF does not include error detection and handling of security events. Assigned SME: Tony Kerr, SV4 SME (tony.kerr@cival.co.uk) SME Commentary: In fact, the CF DOES include error detection and handling, though not specified in a "clean" way that respects the SASO service boundary. For example, 4.8.5.3 (Exception Handling) specifies that the SASO CF should invoke SE-U-ABORT req and "behave as though an SE-U-ABORT indication has been received." 4.8.5.2.2.4 specifies the behaviour when SE-U-ABORT ind is received, which is to invoke SSO-Stop and "invoke by local means the dialogue service error handling procedures (see 4.3.3.1.2.4)." This could be tidied up by defining a SA-ABORT ind primitive as proposed. The proposed solution is incomplete, as it does not include the generation of SA-ABORT by the SASO CF in 4.8.5, nor does it describe this new service in 4.8.3. It would also require additions to Table 4.3-6 and a new subsection in 4.3.3.7 (4.3.3.7.1 could be re-instated). Discussed at ATNP/SGB2 meeting Phuket 13 Mar 2002. Agreed that exception handling needs a complete review from an end-to-end perspective. For example, the conditions under which the peer should flush the security context (SSO-Stop) following a dialogue Abort need further elaboration. This includes questions such as when should a CPDLC (or ADS or FIS) user be able to re-start a dialogue with the retained security context, and when would this be a security loophole. Some error cases in the basic dialogue service should also be elaborated. For example, 4.3.3.1.2.4 states: "The error handling shall result in the association being aborted, if one exists, and a notification being give to the Application user." It is not made explicit what should happen if the association is in one of the Pending states. Therefore, this PDR was recommended to be FORWARDED for further consideration by relevant ATNP subgroups (at least SGB2, SGB3, SGA2). Proposed SARPs amendment: Add a new event (SA-ABORT ind) to the Security ASO upper. This event would be used to indicate a security event to the dialogue user. [If a new state maintaining state information is added (NULL1) or potentially in state NULL] Add new row SA-Abort ind in state table: Row SA-Abort ind, column STA0: (remove state information) Row SA-Abort ind, column STA1: p6: STA0 D-START cnf- Row SA-Abort ind, column STA2: p4 | p5: STA0 P-U-ABORT req (no data) D-ABORT ind Row SA-Abort ind, column STA3: p4 | p5: STA0 P-U-ABORT req (no data) D-ABORT ind Row SA-Abort ind, column STA4: p4 | p5: STA0 P-U-ABORT req (no data) D-ABORT ind Impact on Interoperability: None. PDR Validation Status: The proposed change would need extensive validation by modelling and/or implementation. SME Recommendation to CCB: Remain FORWARDED until a complete proposal is worked out by ATNP subgroups. CCB Decision: FORWARDED (CCB meeting Phuket 14/3/02)