From: owner-atnp_sgb3@cena.fr on behalf of Tony Kerr [tony.kerr@cival.co.uk] Sent: 14 October 2002 16:37 To: atnp_ccb_chair@tls.cena.fr Cc: atnp_sgb2@tls.cena.fr; atnp_ccb_sme4@tls.cena.fr; atnp_sgb3@tls.cena.fr Subject: PDR M2020002 - ULCS - CF State Table - predicates p4, p5 in NULL state - RESOLVED Title: ULCS CF State Table - predicates p4, p5 in NULL state PDR Reference: M2020002 Originator Reference: US-SV4-02-02 SARPs Document Reference: 4.3.3.1.2, Tables 4.3-4, 4.3-5 Status: RESOLVED Impact: C PDR Revision Date: 04 Oct 2002 (FORWARDED -> RESOLVED) 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: Edition 3, 2002 SARPs Language: English Summary of Defect: The CF is assumed to be in the NULL state whenever there is no state information available, and there is dialogue/association. In paragraph 4.3.3.3.2.1.1, it states that "a new instance of communication shall be created, with its CF initially in the NULL state." Predicates p4 and p5 assume state information to be available which contradicts this. Since this instance of communication (and the associated user actions) can only specify "security" or "no security" on the D-START req, only p6 should be used during dialogue establishment. Further, the use of p0 & p5 in STA0 (D-START req) which calls for the event of SA-SEND req requires knowledge of the security ASE that is not readily available, (nor discernable) is it is assumed that the CF started in the NULL state. There are two possible courses of action: 1. Change the state table by adding a new state (NULL01) that maintains communication state information upon completion of the release phase. In this case, the use of p4 and p5 would be possible with maintenance of appropriate state information. The transition to the NULL state would occur due to an event from the security ASE. 2. Remove predicates p4 and p5 from dialogue establishment and use only p6. This would remove the requirement for state information in the NULL state. Assigned SME: SV4 SME (tony.kerr@cival.co.uk) SME Commentary: Discussed at ATNP/SGB2 meeting 13 Mar 2002. It was agreed that S-ASO and CF do not maintain security state information ("Security Context"), rather the SSO does. The conditions under which this information should be discarded or maintained across sequential dialogues between the same peers are being clarified by ATNP SGB2/SGB3. This PDR was FORWARDED for further study. Following further review, it was agreed that the State Table security predicate definitions p4, p5 and p6 in Table 4.3-5 are confusing, and their use does not fully align with the SARPs text in all cases. Although the text takes precedence, the State table should be made consistent. Introducing a new state would require extensive validation by modelling and/or implementation, and is not seen as necessary. The following changes are proposed to clarify the State Table and align it with the text. These changes should satisfy the concerns stated in the PDR, since no prior knowledge is assumed in the CF when D-START req / A-ASSOC ind is invoked: all the required information is in the relevant primitives. Proposed SARPs amendment: 1/ Table 4.3-5, predicate p4 REPLACE: "Dialogue supporting key management exchange" WITH: "The Security Requirements parameter in the D-START primitive issued by the local user was set to the logical value "Secured Dialogue Supporting Key Management", the value in the response primitive being equal to that supplied by the CF in the indication primitive." 2/ Table 4.3-5, predicate p5 REPLACE: "Secured dialogue" WITH: "The Security Requirements parameter in the D-START primitive issued by the local user was set to the logical value "Secured Dialogue", the value in the response primitive being equal to that supplied by the CF in the indication primitive." 3/ Table 4.3-5, predicate p6 REPLACE: "Security initially required on the Dialogue" WITH: "The remote peer requested / agreed to use security, indicated by the ACSE-Requirements parameter in the A-ASSOCIATE indication or confirmation primitive having the logical value "authentication"." 4/ Table 4.3-4, State Table, Cell (D-START req, STA 0) REPLACE: p0 & ~p6: WITH: p0 & ~(p4|p5): Rationale: on the D-START request, all that is known is what the local user is requesting. 5/ Table 4.3-4, State Table, Cell (D-START rsp+, STA1) REPLACE: ~p1 & ~p6: WITH: ~p1 & ~(p4 | p5 | p6): Rationale: The action only applies if a) the remote (initiating) user did not propose security and b) the local (responding) user did not attempt to use security. 6/ Table 4.3-4, State Table, Cell (D-START rsp-, STA1) REPLACE: ~p1 & ~p6: WITH: ~p1 & ~(p4 | p5 | p6): Rationale: as above. 7/ Table 4.3-4, State Table, Cell (A-ASSOCIATE cnf+, STA1) DELETE: p6 & ~(p4 | p5): STA2 D-START cnf+ INSERT AT END OF CELL: p4 = p5 = FALSE Rationale: With the predicates defined as above, the logic should have been (~p6 & (p4 | p5)) to align with the CF text. If the local (initiating) user proposed security but this was rejected by the peer (e.g. it is a Version 1 peer) then the action is the same as if security was not proposed in the first place, and this is covered by the following predicate / action in the cell: (~p6: STA2; D-START cnf+). The local user must then decide, based on security policy, whether to proceed in non-secure mode or abort the dialogue. Predicates p4 and p5 should be reset to FALSE, to indicate that the dialogue is not secured. 8/ Table 4.3-4, State Table, Cell (A-ASSOCIATE cnf-, STA1) DELETE: p6 & ~(p4 | p5): STA0 D-START cnf- Rationale: Same as above. If the local (initiating) user proposed security but this was rejected by the peer (e.g. it is a Version 1 peer) then the action is the same as if security was not proposed in the first place, and this is covered by the following predicate / action in the cell: (~p6: STA0; D-START cnf-). In this case no dialogue is established and the local initiator would have to decide whether to accept the non-authenticated User Data based on local policy. 9/ Table 4.3-4, State Table, Cell (SA-START ind, STA1) DELETE: p4: Rationale: With the predicates defined as above, the CF cannot know what the local user will do in response to the D-START ind. In any case, the predicate is redundant and is not reflected in the CF text (4.3.3.7.2.2.1). 10/ Table 4.3-4, State Table, Cell (SA-SEND ind, STA1) DELETE (3 occurrences): & p5 Rationale: This is a bug. SA-SEND could occur on a Dialogue Supporting Key Management, e.g. if the CM-ground-user used the "maintain" option. In any case, the predicate is redundant and is not reflected in the CF text (4.3.3.7.4.2). Impact on Interoperability: None. The changes merely align the State Table with the normative text. PDR Validation Status: Thorough review. SME Recommendation to CCB: RESOLVED CCB Decision: RESOLVED (CCB/16 Toulouse meeting 04 Oct 2002)