From: owner-atnp_ccb_chair@cena.fr on behalf of Tony Kerr
[tony.kerr@cival.co.uk]
Sent: 11 November 2002 10:33
To: atnp_ccb_sme4@tls.cena.fr
Cc: atnp_ccb_chair@tls.cena.fr
Subject: PDR M2110002 - ULCS - Release Collision with Security -
ACCEPTED

Title: 			SV4 - Release Collision with Security

PDR Reference:          	M2110002

Originator Reference:

SARPs Document Reference:   	Sub-Volume IV 4.3.3.7.4.2.11-14

CAMAL Document Reference:	-

P/OICS Document Reference	-

Status:                     	ACCEPTED

Impact:					B

PDR Revision Date:              	11 Nov 2002 (ACCEPTED)
						08 Nov 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:

When both users of a secured dialogue decide to release the dialogue at the
same time, a release collision occurs.  This is not handled correctly by the
Control Function.  (The State Table is correct, but the textual
description - which takes precedence - is wrong).


Assigned SME:                    	Sub-Volume IV SME


Proposed SARPs amendment:

1/ In 4.3.3.7.4.2.11, REPLACE:
and is in the RELEASE COLLISION state, the CF shall retrieve the previously
stored A-RELEASE Confirmation parameters
WITH:
and is in the RELEASE COLLISION state, and an A-RELEASE Confirmation
primitive has been received, the CF shall retrieve the previously stored
A-RELEASE Confirmation parameters

2/ In 4.3.3.7.4.2.12, REPLACE:
and is in the RELEASE COLLISION state, the CF shall retrieve the previously
stored A-RELEASE Confirmation parameters
WITH:
and is in the RELEASE COLLISION state, and an A-RELEASE Confirmation
primitive has been received, the CF shall retrieve the previously stored
A-RELEASE Confirmation parameters

3/ DELETE 4.3.3.7.4.2.12 bullets b) and c), and REPLACE with the following:
b)	Construct an SA-SEND Request primitive as specified in Table 4.3-50.
c)	Invoke the SA-SEND Request primitive.

4/ In 4.3.3.7.4.2.13, REPLACE:
and no A-RELEASE primitive was received,
WITH:
and no A-RELEASE Confirmation primitive has been received,

5/ In 4.3.3.7.4.2.13, bullet a) REPLACE:
the Data parameter of the SA-SEND
WITH
the User Data parameter of the SA-SEND

6/ In 4.3.3.7.4.2.14, REPLACE:
and no A-RELEASE primitive was received,
WITH:
and no A-RELEASE Confirmation primitive has been received,


Impact on interoperability:

Without this correction, orderly release will not function correctly in the
case of a release collision on a secured dialogue.  An authentication
failure would occur at the dialogue initiator when the closing A-RELEASE
confirmation is received, as the expected SETR APDU would not be present.
Thus the dialogue would be aborted ungracefully, and the initiator would not
receive the D-END User Data.  The Dialogue Responder would not see any
problem.

PDR Validation Status:		Paper walkthrough.

SME Recommendation to CCB: 	ACCEPT the PDR

CCB Decision: