3GPP TSG SA WG3	S3-99353
Meeting #6, Sophia Antipolis, 29 September - 1 October, 1999

Source:	Secretary TSG SA WG3 (Ansgar Bergmann)
Title:		Report of TSG SA WG3 Meeting #6
Status:	Approved 

Table of contents

1	Opening of the meeting; general	3
2	Approval of the Agenda	3
3	Registration and assignment of input documents	3
4	Approval of the meeting report of TSG-SA3 Meeting no. 5 and 5bis; reports from joint meetings	3
4.1	SA3 no. 5	3
4.2	SA3 no. 5 bis (25 August 1999 in Bonn)	4
4.3	Joint S2/S3/T3 session on USIM security issues (24 August 1999 in Bonn)	5
5	Reports / Liaisons from other groups	6
5.1	TSG-SA	6
5.2	TSG-CN, TSG-RAN, TSG-T	6
5.3	Partners and their bodies	7
5.4	Others	7
6	Authentication mechanism as TIA TR-45 ESA candidate	8
7	Algorithm evaluation	8
8	MExE security	10
9	Review of specifications	10
9.1	TS 21.133, Security threats and requirements	10
9.2	TS 33.102, Security architecture	10
9.2.1	MAP security	10
9.2.2	IMEI security	11
9.2.3	Support for multiple authentication algorithms and keys	11
9.2.5	UMTS - GSM interoperation	12
9.2.6	Integrity protection	12
9.2.7	Network wide confidentiality:	12
9.2.8	Re-structuring of 33.102 section 6	13
9.2.9	Enhanced window mechanism	13
9.3	TS 33.103, Integration guidelines	13
9.4	TS 33.105, Cryptographic algorithm requirements	13
9.5	TS 33.106, Lawful interception requirements	14
9.6	TS 33.107, Lawful interception architecture	14
9.7	TS 33.120, Security principles and objectives	14
9.8	TR 33.900, Guide to 3G security	14
9.9	TR 33.901, Criteria for cryptographic algorithm design process	14
9.10	Formal analysis of security mechanisms	14
10	Review of open issues in 33.102	14
10.1	Enhanced User Identity Confidentiality	14
11	Drafting sessions	15
12	CRs for approval at SA#5; specifications for information / approval at SA#5	15
13	Review of project plan	15
14	Future meetings	15
15	Any other business	16
16	Close of meeting	16
Annex A: List of documents	16
Annex B: Participants	19
Annex C: Decision of S3#6	19
Annex D: Action points from S3#6	21
Annex E: CRs agreed by S3 for approval at SA#5	22
Annex F Liaison Statements from S3#6	23
Annex G Specifications for approval / information at SA#5	23

1	Opening of the meeting; general
The 3GPP TSG SA WG3 Chairman, Professor Mike Walker, welcomed the delegates and thanked ETSI for hosting the meeting. He set the main objective of the meeting:
-	to prepare all necessary changes to the security specifications for SA#5.

The last day of the meeting, Friday, 1 October, was chaired, due to travel schedules, by Michael Marcovici, then Bart Vinck, and finally Charles Brookson.
2	Approval of the Agenda
•	S3#6 approved the following agenda:
1	Opening of the meeting
2	Approval of the Agenda
3	Registration and assignment of input documents
4	Approval of the meeting report of TSG-SA3 Meeting no. 5
5	Reports / Liaisons from other groups
5.1	TSG-SA
5.2	TSG-CN, TSG-RAN,TSG-T
5.3	Partners and their bodies
5.4	Others
6	Authentication mechanism as TIA TR-45 ESA candidate
7	Algorithm evaluation
8	MExE security
9	Review specifications
9.1	TS21.133, Security threats and requirements
9.2	TS33.102, Security architecture
9.3	TS33.103, Integration guidelines
9.4	TS33.105, Cryptographic algorithm requirements
9.5	TS33.106, Lawful interception requirements
9.6	TS33.107, Lawful interception architecture
9.7	TS33.120, Security principles and objectives 
9.8	TS33.900, Guide to 3G security
9.9	TS33.901, Criteria for cryptographic algorithm design process
9.10	TS33.902, Formal analysis of security mechanisms (based on S3-99183)
10	Review of open issues in 33.102
11	Drafting sessions
12	Approval of draft specifications and CRs
13	Review project plan
14	Future meetings
15	Any other business
16	Close of meeting

3	Registration and assignment of input documents
See Annex A.
4	Approval of the meeting report of TSG-SA3 Meeting no. 5 and 5bis; reports from joint meetings
4.1	SA3 no. 5
•	The meeting report was approved, see S3-99257
Two liaison statements from S2:
-	S2-99636 = S3-99226 Annex F, re-issued at S3#6 as S3-99315, Answer to the liaison on the time constraints on the execution of cryptographic algorithms,
-	S2-99587 = S3-99226 Annex A, re-issued at S3#6 as S3-99316, Answer to the Liaison Statement on Authentication for Mobile IP Operations in UMTS,
had been postponed at S3#5, see section 5.4 for further treatment in S3#6. 
All action points from S3#5 meeting are closed: 
•	List of messages to be integrity protected: Done, see S3-99333.
•	Responses for Annex C of 33.105 from other groups: Closed.
•	Check of X20 (whether it should be 24 bits): Done.
•	CR to correct figure in 33.103: Superseded.
•	To specify what should happen if the MS discovers that integrity is not provided (that is, if the check fails): Done, see CR 33.102-013.
•	To examine consequences of the CR in S3-99180 (modified synchronisation procedure) on the option of a global counter in 33.102: done
•	Update of S3-99238, the work plan of specifications: It was updated by Peter Howard. Creation of a directory in the S3 domain where the latest versions of specifications can be found that are not yet under change control: There is a general directory for drafts of all groups. Specifications of S3 will be put there as decided by S3.
•	Peter Howard should distribute after the meeting S3-99248, CR to 33.105 on Cipher keystream block length, adding the relevant information, for discussion and if possible agreement by e-mail. Done.
•	To take up the protection of user data against modification on the radio interface: Not maintained as formal action point.
•	Peter Howard should distribute S3-99246, CR to 33.102 on Cipher key setting, with the aim to reduce the options for the handling of cipher keys generated in different domains, for e-mail discussion and, if possible, agreement in S3. Done.
•	Wael Adi to provide the slides (S3-99250): Done.
•	S3 will try to produce (via e-mail correspondence) a document for the joint USIM meeting on 24th August with a single preferred mechanism. Done.
•	A draft of the Guide to 3G security (3G TR 33.900) will be distributed by Charles Brookson via e-mail. Done.
•	Bart Vinck announced that he would provide some additional points areas were technical work is necessary. Closed.
•	Peter Howard should provide an electronic copy of S3-99258. Done.
4.2	SA3 no. 5 bis (25 August 1999 in Bonn)
•	The S3#5bis meeting report was approved, see S3-99273
S3#5bis had mainly discussed the following items:
-	Selection for the cipher and integrity keys in the signalling plane: 
•	S3#5bis had approved the CR to 33-102 in S3-99265. S3#6 noted this approval. 
	(The principle of the CR is: when a key is set for PS or CS domain user plane, then it also applies to the whole signalling plane; so that, for example, when a PS connection exists and keys for PS are set, they will be used for signalling as well; if later a CS connection will be established and corresponding keys will be set, the signalling starts to use these keys; when later the CS connection is released, signalling would continue to use the CS keys until a new setting is ordered.) 
-	Interoperation between UMTS and GSM: The results of the meeting were issued in S3-99266, a draft Liaison Statement to S2. After distribution, some comments from T-Mobil in S3-99295 had been received. These comments were dealt with at S3#6:
*	in point 11 of S3-99266, the UMTS cipher key, not the GSM cipher key is meant. 
*	The USIM should always be able to calculate the GSM and UMTS security parameters.
*	For the last point in S3-99266 (PS 'handover' from pre-99 GSM to UMTS) it was clarified that the solution is offered for the case that the possibility is required.
*	Concerning the implementation of UMTS MM security procedures in the R99 GSM-only MS, it was clarified that by default, the MM protocol of 24.008 apply to both GSM and UMTS. Also the question (whether a R99 GSM only mobile station has to implement the UMTS R99 authentication procedure) is not really relevant to the technical solution, as anyhow it has to be guaranteed that the core network gets the information in an appropriate way whether the mobile supports the UMTS authentication procedure.
For the revised LS to S2 in S3-99336 and the CR to 33.102 in S3-99232 on the topic of GSM-UMTS interworking, see section 9.2.
-	Enhanced user identity confidentiality: A conclusion had not been reached at S3#5bis. See section 10.1.
-	Re-structuring of 33.102 section 6: Principles were agreed, see corresponding CR 33.102-012 in S3-99338, approved by S3#6, see section 9.2.
4.3	Joint S2/S3/T3 session on USIM security issues (24 August 1999 in Bonn)
The draft report of the Joint S2/S3/T3 session on USIM security issues is S3-99274. Main points:
-	addressing of algorithms and keys;
-	handover/roaming/interoperation between GSM and UMTS;
-	resources for cryptographic algorithms in the USIM: Amongst other points, the joint meeting had concluded that 500 ms should be considered as a maximum time for execution of the authentication algorithm in the USIM. At S3#6 there were several comments that this is not very ambitious for 3rd generation;
-	enhanced user identity confidentiality; see section 4.2 and section 10.1 for follow up discussions in S3#5bis and S3#6.
-	IMUI / IMSI relationship: It had been clarified that so far, nobody had been able to explain why these two identities should be distinguished.
•	S3#6 agreed to change the term IMUI (TMUI) to IMSI (TMSI) in its documentation
-	The joint meeting had studied T3-99238, a discussion document about USIM security requirements currently contained in S3 specifications but not yet reflected in T3 specifications. It had concluded that the following features need to be addressed by T3:
*	User Identify Confidentiality;
+	Identification by temporary identities;
+	Identification by a permanent identity;
*	User authentication;
+	User-to-USIM authentication;
+	USIM-Terminal Link;
*	Message authentication of signalling information sent to/from UE;
*	USIM application security.
-	T3-99244 is a discussion document listing several USIM requirement from 33.103 v1.0.0 that require clarification. 
-	T3-99245 is a proposal as to how some of the features listed in T3-99238 could be incorporated into T3 specifications.
It had been concluded at the joint meeting that many of the issues raised in T3-99238, T3-99244 and T3-99245 have already been discussed within S3 and that the next version of 33.103 would contain clarifications.
At S3#6, it was agreed that an updated version of 33.103 incorporating all relevant updates relevant to the USIM would be sent by the rapporteur, Colin Blanchard, to T3 on Sunday, 3 October 1999, and that Nigel Barnes would attend the T3 meeting in Korea to assist with questions that might to arise. See also section 9.3 on 33.103.
5	Reports / Liaisons from other groups
5.1	TSG-SA
There had been no meeting of SA between S3#5 and S3#6. The SA Chairman had asked the WGs to clearly identify in their contributions for SA#5 between R99 and R2000 issues.
S2-99636 = S3-99226 Annex F, re-issued at S3#6 as S3-99315, Answer to the liaison on the time constraints on the execution of cryptographic algorithms: S3#6 clarified that X4 is the time for algorithm calculation time. Its value represents information for the algorithm design (SAGE) rather than for system architecture (S2). 
•	Mike Walker will talk to the S2 Chairman and give him the responses needed to questions of S2-99636
S2-99587 = S3-99226 Annex A, re-issued at S3#6 as S3-99316, Answer to the Liaison Statement on Authentication for Mobile IP Operations in UMTS, Nigel Barnes to draft an answer (to invite S2 for a presentation at next S3 meeting). 
•	S3-99339, LS to S2 on Authentication for Mobile IP Operations in UMTS, revision of S3-99326 (drafted by Nigel Barnes), answering the LS from S2 to S3 in S2-99587 = S3-99226 Annex A, re-issued at S3#6 as S3-99316, was approved with the modification to change the date to 28
5.2	TSG-CN, TSG-RAN, TSG-T
S3-99286, LS from N2B to SA3 on Securing MAP Based Transmission of Sensitive Data between Network Elements (=N2-99A42), contains the following comments: 
-	First, TSG CN2 believes that the transport of the Layer 1 messages between Key Administration Centers (KACs) is outside the scope of TSG CN2. Therefore, TSG CN2 is not in the position to advice TSG SA3 concerning which transport mechanism to be used.
-	Second, TSG CN2 also raises the concern about the usage of additional header information (i.e. security header) to ensure securing MAP messages. Current MAP messages (GSM Release 97 & 98) already overrun the maximum message length that fits within a single PDU. This fact introduced segmentation of MAP messages within GSM, which causes decreased efficiency of the MAP message transmission. The addition of the additional header information will certainly not benefit the segmentation issue.
-	Finally, TSG CN2 would like to point that the network domain security mechanisms focuses only on the capability of securing MAP based transmission of sensitive data. TSG CN2 believes that the GTP based transmission will also contain sensitive data. This data will require an equal level of security (e.g. authentication parameters, subscriber profile information, etc). Therefore securing GTP based transmission messages needs to be secured as well.
Discussion at S3#6: 
-	On the first point: S3 acknowledge this and will modify their work plan accordingly.
-	On the second point: S3 recognise this but stress the importance of this security feature.
-	On the third point: S3 has noted this and will extend their specifications using industry standard techniques (such as IPsec) where appropriate. The possibility of extending these mechanisms to secure CAP/INAP signalling is also being investigated. 
•	The responding LS to NS on MAP security in S3-99347 (answer to S3-99286=N2-99A42) was approved
For CR 33.102-014 on network domain security, attached to the LS, see section 9.2.
Workshop on hooks and extensions: S3-99287, Report from workshop on hooks and extensions: The requirements to harmonise authentication and ciphering was noted and will be an urgent medium term task.
Multiple RABs:
•	A LS in s3-99330 to R2 (prepared by Charles Brookson), responding to a LS from R2 in S3-99288 = R2-99983, Response to LS on Ciphering mechanisms in case of multiple RABs, was approved
S3-99289, LS to S2 cc T3, S3 on parameters to be stored in the USIM (=R2-99984), was noted by S3#6.
S3-99323 is a LS from T2 SW6 on Terminal Service Implementation Capabilities in the security domain, requesting S3 to classify the whole Terminal Service Implementation Capabilities in the security domain.
•	Response to S3-99923?
•	A LS to T2  in S3-99329, prepared by Sebastien Nguyen Ngoc, complementing earlier LS form S3 to T2 SW8 in S3-99252, responding to S3-99290, Liaison Statement from T2 SW8, Cover letter for TR21.904, Terminal Capabilities Report, interim version, was approved
	It adds the necessary security requirement for UMTS-GSM interoperation. Annexed is CR 33.102-015 (s3-99332), see section 9.2.
S3-99291: It was agreed in S3#6 that for INAP, there are similar security problems an for MAP. However, CAMEL/INAP security is not in the S3 work plan, and can not be included realistically for R99. For SAT, S3 has no plan to change the secure transport mechanisms. MExE security is part of the S3 R99 work plan. Contact persons: The representative for MExE is Tim Wright.
•	The LS to S2 in S3-99346 on VHE/OSA stage 2, informing on the S3 plans for MExE, CAMEL and SAT, drafted by PH, responding to a LS from S2 in S2-99793 = S3-99291, was approved
S3-99293, LS from T2 on Synchronisation: The document was noted. S3#6 agreed that the topic is not related to S3 areas.
S3-99294, LS from N2 on enhanced user identity confidentiality: see section 10.1. 
S3-99305, draft LS from R3 on Support over Iu for Ciphering for Multiple RABs, explains that for R99, the RANAP protocol on the Iu interface will support the ciphering of either all or none of the RABs that are active towards a specific user from a specific core network domain (CS or PS). This was noted by S3#6 with satisfaction.
S3-99307 is a draft LS from R3, presented to S3 by Ericsson. It informs that RAN WG3 had recently approved a Security Mode Control procedure in the Iu RANAP protocol which corresponds to the traditional ciphering mode command control procedure supplemented with Integrity Protection functionality as mandated by 33.102. The principles of verification of the „UE Classmark“, without interpretation in UTRAN were however left open, and S3 was asked to comment on the feasibility of such mechanism. The UE Classmark has to be available in the CN. RAN WG3 also asked for the status of discussion on re-authentication, understanding that it may result in changing of security mode control information in the course of a communication. Further R3 assumes that UMTS Encryption Algorithms (UEA) and UMTS Integrity Algorithms (UIA) permitted to be used for security mode control in UTRAN are given by the CN and the selection of which to be used is performed in SRNC. (This mechanism is in essence similar to GSM.)
•	Ansgar Bergmann to create S3-99343, LS to RAN3, cc to RAN2, RAN and T2, to be sent as response to the draft LS in S3-99307, with CR 33.102-013 (S3-99233) attached. 
5.3	Partners and their bodies
S3#6 noted that UWCC has joined 3GPP as a market representation partner.
SAGE: See section 7.
5.4	Others
No input received.
6	Authentication mechanism as TIA TR-45 ESA candidate
S3-99281, AHAG straw poll on the four ESA candidates, contains an e-mail from Peter Howard (sent on 15 September 1999) and an e-mail from Christopher Carroll, AHAG chairman (sent: 08 September 1999).
	AHAG and TR-45 are evaluating ESA schemes. The four candidate mechanisms are from 
-	3GPP
-	Certicom
-	CipherIT
-	Lucent.
	The TR-45 Chair tasked each subcommittee to review the ESA proposals and provide comments and/or recommendations to the AHAG and TR-45 Committee by the December TR-45 meeting. If the subcommittees agree on one proposal, the AHAG shall adopt that proposal as the TR-45 ESA. If the subcommittees cannot agree on a proposal, the TR-45 committee will select one proposal at the December TR-45 meeting. 
	The selection of ESA mainly rests on the decision of subcommittee TR-45.2, TR-45.3, and TR.45.5. The other subcommittees might provide comments. 
	To support the subcommittees in their selection process, the TR-45 Committee has tasked the AHAG to perform a Straw Poll of the ESA candidates. The Straw Poll will ask each company/organization to select the best of the ESA candidates. The AHAG chairman, Chris Caroll, decided to allow one vote per organization. Only companies/organizations that have attended the AHAG at least four times this year will vote (ESA proponents will have one vote). Absentee votes will be accepted if an organization is unable to attend. The voting organizations within AHAG are: Qualcomm, Motorola, Ericsson, Denso Int., Nokia, Lucent Technologies, GTE, AT&T Wireless, CipherIT, Certicom, 3GPP, DOD - NSA, ICO. 
	AHAG are conducting a straw poll on the four ESA candidates at their next meeting in San Juan in October. 3GPP as an organization have a vote as do some 3GPP members who have been attending AHAG on a regular basis recently. It is assumed that 3GPP should vote for the 3GPP candidate. 
S3-99281 proposes 
-	to demonstrate the advantages of the 3GPP scheme 
-	to develop the arguments on why it is desirable to have a common authentication mechanism across both systems 
-	to investigate interworking between networks using the 3GPP authentication mechanism and networks using the current ANSI-41 authentication mechanism. 
	It comments that although the 3GPP mechanism performs well against the public key candidates in this area, it is likely to face more of a challenge from the other secret key candidate. 
Discussion in S3#6: 
Participation at TR-45.2, TR-45.3, and TR-45.5 is important. It should be documented how the 3GPP ESA can be integrated into ANSI-41. It should be clarified that the 3GPP authentication protocol is not dependent on the algorithm, but an example algorithm should also be presented. 3GPP should endorse this initiative and that it should vote for the 3GPP candidate in the staw poll.
Tim Wright and Bart Vinck will give presentations to AHAG, TR-45.2 (CN) and TR-45.5 (CDMA).
•	Action point Tim Wright, Bart Vinck: To send the presentations for AHAG, TR 45-2 (CN) and TR45-5 to the S3 mailing list on Wednesday. Comments have to be made until Friday noon.
7	Algorithm evaluation
Mike Walker presented S3-99278, proposing details of the cipher algorithm evaluation procedure: terms of reference for the evaluators (two evaluators will be contracted with a payment of 20 000 Euro each), a draft letter to evaluator candidates and a list of to evaluator candidates.
•	S3#6 approved the terms of reference in S3-99278
S3 agreed in principle with the draft letter to evaluator candidates (however, the letter could contain some details on the selection procedure of evaluators, some information on the algorithm and some details what the application should contain). Later in the meeting, Charles Brookson presented a revised version which was appreciated by S3 and should be sent to Mike Walker for consideration.
•	S3-99331, Drafting Criteria for Algorithm Evaluators Responses, prepared by a side meeting of S3#6 chaired by Charles Brookson, was approved in principle. It should be reflected in an appropriate way in the letter to evaluator candidates
Comments at S3#6: 
-	The ETSI contract should consider IPRs related to comments from evaluators. 
-	Aspects of non-disclosure would be a matter for the contracts.
-	There could be an ETSI press release associated with the letter asking for further evaluators. However, it would neither be possible to handle a lot of applications nor a lot of evaluations. 
Selection of the two evaluators: This will be done in S3#7 (26-27 October 1999, Den Haag, based on advice of some SAGE/S3 experts meeting on 25 October).
Per Christoffersson presented S3-99292, LS39 from SAGE on cipher algorithm complexity: SAGE has asked manufacturers in a LS sent to S3 for comments on the implementation complexity of the general approach that SAGE proposes to take to the design of . It has been sent to S3 on 12 August 1999. Considering the tight time scales for the algorithm development interested parties were invited to comment on the described example algorithms before end of August, directly to SAGE. This LS has thus not been intended to wait for a formal answer at next S3. 
	Encouraging responses have been received.
Per Christoffersson presented S3-99279, LS on algorithm design work. 
	Additional comments: 
-	Regulations of mass market products will be applicable for mobile stations, but not for base stations: There is a limit of 64 bits in the current Wassenaar agreement, however most countries do no more apply this limit. 
-	External evaluators: Lucent has not taken part in the algorithm development in the evaluation work so far. SAGE had offered to send the first drafts for algorithms to them for evaluation, but there was no response. Ericsson, Nokia and Motorola are taking part.
-	The proposed name of the algorithm is "Kasumi" (which means "mist" in Japanese).
-	Per Christoffersson stated that there may be lots of state information to handle if it is necessary to stop/start the algorithm
Per Christoffersson  presented S3-99317, Comments regarding f8 and f9 design, another LS from SAGE.
	Agreement in S3#6:
- MAC value for f9 should be 32 bits: In a show of hands, this was accepted by the vast majority (14 companies), while 2 companies prefer 24 bytes.
	Time scales: Per Christoffersson indicated that SAGE is on target, but would appreciate to have one month more time.
Licensing of Kasumi relevant Mitsubishi IPRs:
S3 and SAGE had based their work on the 3GPP cipher algorithm on MISTY (developed by Mitsubishi) under the impression that the relevant IPRs for the 3GPP cipher algorithm would be granted license and condition free, realising that other IPR free algorithms would be suitable as well as basis. 
At S3#6, Mariko Kishi presented S3-99311, License Policy, source Mitsubishi. 
	Clarifications at S3#6 to S3-99311: The patent quoted in the 2nd paragraph are world wide.
	Comments of S3: S3 expressed its view that licensing of the Mitsubishi IPRs relevant for KASUMI should not be coupled to IPRs of other companies in areas outside of the cryptographic aspects of 3GPP.
	Later during the meeting, a side meeting (ETSI legal adviser Stéphane Tronchon, Per Christoffersson and Mariko Kishi) discussed the issue further. Stéphane Tronchon reported to S3#6 that Mitsubishi as a member of ETSI will send between 4 and 8 October an IPR statement form and declaration form to ETSI satisfying the requirement of the ETSI IPR policy.
	Comment at S3: In addition, the members of S3 (except Mitsubishi) asked Mitsubishi for a license fee free granting of all IPRs relevant for the 3GPP cipher algorithm. 
8	MExE security
On behalf of Tim Wright, Peter Howard presented S3-99297, informing about the progress on MExE. TS 23.057 V1.3.0 (MExE R99 stage 2) was available to S3#6 as S3-99298. 
	MExE R99 is now under responsibility of S3. 
	Work on using the SIM to provide security services as requested by SMG10 in SMG10 AP99060 has begun within MExE. Stage 2 gives details on the use of a SIM certificate by MExE. Other SMG10 requirements in SMG10 AP99060, such as mandatory support of “one shot” permission (now referred to as single event permission) and the retention of three trusted execution domains were also met by the approved release 98 version of MExE and have been retained within release 99.
	In addition to a general review, S3-99297 asks S3 for guidance on three specific points.
1.	section 8.2 of 23.057, the MExE “security table”
2.	External port access
3.	recent additions to the draft release 99 stage 2 giving access to the screen and keyboard to untrusted (i.e. unsigned) applications. 
•	MExE security to be dealt with further at S3#7.
9	Review of specifications
9.1	TS 21.133, Security threats and requirements
•	Integrity protection for SMS should be included (e.g., as a protected mode which can or can't be applied). CR required for S3#7.
•	Integrity protection for general user data: This should be removed or completed. CR required for S3#7.
9.2	TS 33.102, Security architecture
9.2.1	MAP security
S3-99277: This document was presented by Roland Schmitz. The source companies had discussed MAP security between the security and MAP experts and did not identify substantial problems. Roland Schmitz and maybe some other S3 experts will participate in the next meeting of the signalling ad hoc group of N2 (October in Eaton).
Concerning a LS from N2B on the issue, see section 5.2.
•	S3#6 agreed CR 33.102-014, presented by Roland Schmitz, on Security of MAP-Based Transmissions in S3-99334
	With this CR, there is at least a note pointing to similar security requirements of GTP (the GPRS tunnelling protocol, which is IP based). Further discussions in S3#6 showed that the security requirements on INAP are maybe even more important (see also section 5.2 on S3-99291).
•	S3#6 approved a LS to S2 in S3-99336 (attached: CR 33.102-A015, revising a draft CR in S3-99313) on the topic of GSM-UMTS interworking
•	Roland Schmitz to prepare a CR to 33.102 at S3#7 to at least mention INAP security. 
Note: 	One comment at S3#6 was that a way to realise both MAP and INAP security might be to use a new security component transported by TCAP.
9.2.2	IMEI security
S3-99296 was presented by Stefan Andersson. The document concludes that secure storage based on the change requests to the GSM core specifications and secure signalling based on existing integrity protection mechanisms is adequate for the original usage of the IMEI, blacklisting of stolen equipment; furthermore, that the discussions of IMEI security should be carried out assuming the existence of security mechanisms that guarantee the integrity of the TE software; finally, that new usage of the IMEI should be clearly defined and should result in new requirements preceding any debate on technical solutions.
	Discussion at S3#6: It was clarified that Vodafone is still intending to provide a list of applications which could take benefits from secure IMEI.
	S3-99296 was noted by S3#6.
99303 was tabled but not handled at S3#6.
•	Terminal security will be dealt with further at S3#7. 
9.2.3	Support for multiple authentication algorithms and keys
S3-99302, Support for multiple authentication algorithms and keys, source: Vodafone / Joint session on the USIM at T3#8, was presented by PH. The document elaborates a proposal made by the joint session on the USIM at T3#8:
	It is proposed to add an extra parameter to the authentication token in the user authentication request message to indicate which algorithm and key should be used in the current authentication and key agreement protocol run. The extra parameter would be integrity protected by including it as an input in the calculation of the MAC parameter contained in AUTN. (One of the reasons for integrity protecting it is to help guard against attacks on “spare” algorithms and keys.) It would be used to transport an explicit indicator to the USIM during algorithm and/or key changeover. Outside this period an explicit indicator would not need to be sent. The USIM could store the last correctly verified AID as the current default to be used if an explicit indication is not given. This implicit indication would help save on bandwidth, storage and processing costs. The fact that AID is integrity protection should help to guard against denial of service attacks in this case were the attacker attempts to change the default algorithm and key on the USIM.
	It is for further study whether AID also needs to be added the authentication token AUTS in the synchronisation failure message returned by the user in the event that the sequence number SEQ in the authentication token AUTN is not accepted. 
	Later in the meeting, Peter Howard presented a draft to 33.102 on support of multiple algorithms in S3-99341. There was a discussion in S3#6 on the method to include negotiation parameters in the authentication token. It was responded that the joint T3/S3 meeting had concluded that other methods are less suitable (e.g., to change the algorithm via SMS). Another comment was that if the method is used, it is not necessary to standardise: AUTN can be specified as a parameter with variable length starting with SQN and AK followed by a field for operator specific use. The usage for multiple algorithms could then be described in an annex. The length of that field will be subject to a later CR to the integration guidelines. That was agreed. 
•	Peter Howard to distribute an updated version of the CR to 33.102 on support of multiple algorithms in S3-99341 until Monday, 4 October 1999 evening (Greenwich Time) for agreement by correspondence in S3 until Friday 8 Oct 1999: Done: The updated CR is S3-99348.
9.2.5	UMTS - GSM interoperation
S3-99310 is an analysis of distribution of security parameters between GSM-UMTS. It was noted.
•	CR 33.102-015 on UMTS - GSM compatibility in s3-99332, presented by Rolf Blom, was agreed. 
	The possibility to explicitly transport the GSM triplets in addition to the 3G AV has not been included in the CR, so that the conversion function will also apply to derive triplets from AVs.
	Note: the conversion functions could get individual names in a later version. 
	The CR states in section 6.3.7.1 that a general principle in designing the security interoperation between 3G and 2G networks has been that a UMTS user (i.e. a user with a USIM issued by a R99 HLR/AuC) shall get UMTS level of security whenever possible. 
	Roland Schmitz stated on behalf of T-Mobil that T-Mobil does not want any exception to be made to this general principle. 
9.2.6	Integrity protection
RB presented S3-99309, Intended R2 contribution; Inclusion of message parameters for Integrity Protection, source: Ericsson. 
•	The principles of S3-99309 were agreed
Valtteri Niemi presented S3-99312, Draft CR to 33.102 on integrity procedures. A revision, 
•	CR 33.102-013 on Integrity protection procedures, presented by Valtteri Niemi, in S3-99333 was agreed.
	Comments: The principles of S3-99309 were used as a basis for CR33.102-103 in s3-99333. The integrity algorithm is selected by the network on basis of a list sent by the mobile station. This could be exploited by a mobile only offering a weak algorithm. This however seems unavoidable if a stronger algorithm has been developed to replace a weaker one and a transition time is applied where both are used. 
	The detailed protocols when integrity checking fails are left to the protocol specifications.
9.2.7	Network wide confidentiality:
A CR to 33.102 on network-wide confidentiality in S3-99340 was presented by Peter Howard. The intention is to clean up the description of this feature. 
	It was commented that the CR is a clear improvement of the section, but that, e.g. due to implementation aspects, further changes may be necessary.
•	A revision to be presented by Peter Howard adding a note that, e.g. due to implementation aspects, further changes may be necessary to be circulated  for agreement by correspondence in S3 until Friday 8 Oct 1999. Done: S3-99344.
9.2.8	Re-structuring of 33.102 section 6
Principles had been agreed in S3#5bis, see section 4. S3-99319, S3-99320, S3-99321 were considered in the editorial revision of 33.102:
•	The corresponding CR 33.102-012 in S3-99338 was agreed by S3#6
9.2.9	Enhanced window mechanism
S3-99308, S3-99322, S3-99324 and S3-99304: These documents discuss the enhanced window mechanism. 
	In the discussion in S3#6, the security related concerns of Ericsson against the enhanced mechanism were withdrawn, however the complexity related concerns were maintained.
	Clarification to S3-99304: GLC and SQN2 have to have the same length.
Later in the meeting, Günther Horn presented S3-99342, draft CR to 33.102 on window mechanism. Discussion in S3#6: The following changes were requested: 
-	To indicate the mechanisms of annex C.3 and C.4 as examples. 
-	To move MSC/VLR and serving node relevant parts (which have to be implemented or at least understood in the serving network) to the main body (this applies to 4th paragraph of C.3 and maybe more). 
-	To describe the window management as independent from the temporary identities (in a new sub-section of 6.3).
•	GH to send out a revision of draft CR to 33.102 on window mechanism in S3-99342, to S3 until Monday, 4 October 1999, evening (Greenwich time) for agreement by correspondence in S3 until Friday, 8 October 1999. Done: CR 33.102-018 in S3-99349.
A draft CR to 33.102 on Over the air management of window and list sizes in S3-99342, source: Siemens, was withdrawn and will be integrated into CR 33.102-017.
The CR to 33.102 on generalised scheme for sequence number management in S3-99345, source Siemens, was agreed by S3#6. See annex E for the version presented for approval to SA in S3-99352.
9.3	TS 33.103, Integration guidelines
Colin Blanchard presented , 3G TS 33.103, Integration Guidelines, Version 1.1.1, in S3-99282.
•	It was agreed that duplications of information in 33.102 should be avoided in 33.103.
•	It was agreed at S3#6 that an updated version of 33.103 incorporating all relevant updates relevant to the USIM would be sent by the rapporteur, Colin Blanchard, to T3 on Sunday, 3 October 1999; that Colin Blanchard would distribute a draft version incorporating all necessary changes, intended for approval at SA#5, on Wednesday, 6 October 1999 to the S3 mailing list for comments until Thursday, 7 October 1999; that Colin Blanchard would distribute the resulting version to the S3 mailing list on Friday, 8 October; that Ansgar Bergmann would do the necessary editorial changes for presentation as V2.0.0 to SA#5 for approval on the week-end 9-10 October 1999.
•	Action point for S3#7: The parameter COUNT for ciphering shall be re-named to COUNTC
9.4	TS 33.105, Cryptographic algorithm requirements
S3-99280, Security of the integrity mechanism, source: France Telecom, was presented by Sebastien Nguyen Ngoc. The document proposes different algorithms for integrity protection of user to network and network to user signalling messages.
S3#6 concluded that this has already been decided by SAGE (see S3-99317 on direction bit).
•	CR 33.105-003 on Cipher keystream block length in S3-99301 had been agreed in S3 by correspondence between S3#5 and S3#6. This was noted by S3#6
•	CR 33.105-001, Resources for cryptographic algorithms in the USIM, in S3-99335 (revision of S3-99327) was agreed
•	CR 33.105-002, on MAC used for data integrity of signalling messages, in S3-99337 (revision of S3-99328) was agreed
9.5	TS 33.106, Lawful interception requirements
283, 284.
CRs to 33.106 are planned for SA#6. 
9.6	TS 33.107, Lawful interception architecture
It was not possible to finish the work in time. Therefore the time plan can not be met to present the specification for approval to SA#5. Instead SA#6 is now envisaged. 
S3#6 noted that only the German and UK regulators are the only regulators contributing to the work on LI.
•	TS 33.107 to be prepared for SA approval at SA#6.
9.7	TS 33.120, Security principles and objectives 
No input received.
9.8	TR 33.900, Guide to 3G security
See S3-99325. It is planned for approval at SA#7.
9.9	TR 33.901, Criteria for cryptographic algorithm design process
No input received.
9.10	Formal analysis of security mechanisms
•	GH, AB to prepare it during next week for Korea.
10	Review of open issues in 33.102
10.1	Enhanced User Identity Confidentiality
This feature under study relates to paging with IMSI. The intention is to avoid transmission of IMSI in clear text via the radio interface.
Clear text transmission of the IMSI can happen
(1)	from the mobile to the network if a TMSI has not (yet) been assigned or is considered invalid in the mobile station; typical situation is at first activation of an IMSI;
(2)	from the network to the mobile in a paging message, typically after VLR restoration or TMSI allocation failure, or in some networks if paging with TMSI failed.
S3-99294: This LS from N2 explains mainly that the IMSI is used to derive the SCCP called party address which is needed to route the signalling to the correct HLR. For that purpose,
-	the VLR (in the serving PLMN) uses the Mobile Country Code (MCC) and Mobile Network Code (MNC) which are part of the IMSI to identify the Home Environment (HE); 
-	in most HEs it will be necessary to analyse initial digits of the remaining part of the IMSI, the MSIN, to route the message to the correct HLR. The depth of analysis of the MSIN is HE dependent.
	Discussion in S3: 
-	It is acceptable for S3 that the MCC and MNC as well as an HE dependent initial part of the MSIN are transported unencrypted by the mobile station to the network via the radio interface. 
-	For paging purposes, the encrypted IMSI could be available in the Visited MSC and VLR in addition to, not instead of, the clear text IMSI.
Roland Schmitz presented S3-99314, Enhanced User Identity Confidentiality and IMSI-Paging, on behalf of Mannesmann Mobilfunk. It was commented that the solution 1 of the document (to page with IMSI in clear text and to integrity-protect the paging) would increase the size paging message too much. For the second solution (to page with an encrypted IMSI), it was commented that the next expected paging Id should be known in the ME, that is instead of sending each received encrypted IMSI to the SIM for checking, the encrypted IMSI should be loaded from the SIM into the ME.
Questions on the importance of the scheme were raised.
•	The interested parties to provide the complete description of a robust mechanism and all necessary associated CRs for introduction of enhanced user identity confidentiality to S3#7.
11	Drafting sessions
None convened.
12	CRs for approval at SA#5; specifications for information / approval at SA#5
See Annex E.
13	Review of project plan
•	S3 approved S3-99276, the status of S3 specifications
PH presented S3-99306, 3G PF 30.p-c-sec, 3GPP work program; Project co-ordination aspects; Project Plan for Security, version 0.0.0. Rapporteur is Chris Pudney, Vodafone. It was clarified that the "master" information is contained in the annexed Excel sheet.
	S3 made several comments to improve the representation.
•	To look at the updated version of p-c-sec.
•	Peter Howard to distribute an updated version of the work plan.
14	Future meetings
Meeting	Date	Location	Host	
S3#7	26-27 October 1999	Den Haag, Netherlands	KPN	
S3#8 (partly joint with SMG10-99#3)	16-19 November 1999	Sophia Antipolis, France (Hotel Mediathel)	ETSI	
S3#9	7-9 December 1999	Helsinki	Nokia	
S3#10	19-21 January 2000			
S3#11	22-24 February 2000			
S3#12	11-13 April 2000			
15	Any other business
Mike Walker proposed to invite a greater public to examine the 3G security procedures, e.g., to send out an ETSI press release after SA#5. S3#6 endorsed the idea. 
•	Charles Brookson to draft some text for a press release.
16	Close of meeting
The meeting was closed.
Annex A: List of documents
tdoc	title/topic	source	AI	Result	
S3-99272	Final draft of S3#5bis report		4	Approved as S3-99273	
S3-99273	[reserved for approved S3#5bis report]			Approved	
S3-99274	Draft report from the joint S2/S3/T3 session on USIM security issues	T3 secretary	4	noted	
S3-99275	Draft agenda S3#6	Chairman	2	approved	
S3-99276	Status of specifications	Vodafone	9		
S3-99277	Report of a meeting between T-Mobil and Deutsche Telekom on MAP security	T-Mobil, Deutsche Telekom	9.2		
S3-99278	3GPP Cipher evaluation	S3 Chairman	7		
S3-99279	LS on algorithm design work	SAGE	7		
S3-99280	SECURITY OF THE INTEGRITY MECHANISM	France Telecom	9.4		
S3-99281	AHAG straw poll on the four ESA candidates	Peter Howard, Vodafone	6		
S3-99282	3G TS 33.103, Integration Guidelines, V 1.1.1	Rapporteur (Colin Blanchard)	9.3		
S3-99283	3GPP LI Specification Program Plan	Berthold Wilhelm, RegTP Germany	9.5		
S3-99284	3G TS 33.106 Lawful Interception Requirements	Berthold Wilhelm, RegTP Germany	9.5		
S3-99285	3G TS 33.107 Lawful Interception Architecture and Functions (Content only)	Berthold Wilhelm, RegTP Germany	9.6		
S3-99286	LS to SA3 on Securing MAP Based Transmission of Sensitive Data between Network Elements (=N2-99A42)	N2B	5.2		
S3-99287	TSG-RAN L123 Hooks and Extensions Workshop Sophia Antipolis, France, 24-26, August,1999 - Revised Report version 2.0.0 (=RP-99429)	MCC	5.2		
S3-99288	LS to S3 - Response to LS on Ciphering mechanisms in case of multiple RABs (=N2-99983)	R2	5.2		
S3-99289	LS to S2 cc T3, S3 on parameters to be stored in the USIM (=R2-99984)	R2	5.2		
S3-99290	Liaison Statement - Cover letter for TR21.904, Terminal Capabilities Report, interim version	T2 SW6	5.2		
S3-99291	LS from S2 on Support for VHE/OSA Stage 2 		5.2		
S3-99292	LS39 from SAGE on cipher algorithm complexity	SAGE	7		
S3-99293	LS from T2 on Synchronisation	T2	5.2		
S3-99294	LS on enhanced user identity confidentiality	N2	5.2		
S3-99295	Comments to S3-99266	T-Mobil	4		
S3-99296	Security mechanisms for the IMEI	Ericsson	10		
S3-99297	Update on MExE security	Vodafone	8		
S3-99298	23.057 V1.3.0	T2	8		
S3-99299	- withdrawn -				
S3-99300	TR45 meeting schedule for rest of year	Tim Wright, Vodafone	6		
S3-99301	CR 33.105-003 on Cipher keystream block length (agreed in S3 by correspondence)	S3	9.4		
S3-99302	Support for multiple authentication algorithms and keys	Vodafone	9.2		
S3-99303	The use of Zero-Knowledge Identification mechanisms for 3G Terminal Identification	Vodafone	10		
S3-99304	A generalised description of sequence number management options	Siemens AG	9.2.9		
S3-99305	Draft LS on Support over Iu for Ciphering for Multiple RABs	R3	5.2		
S3-99306	S3 Workplan (rev of S3-99258)	Peter Howard, Vodafone	9, 13		
S3-99307	Proposed liaison statement to SA3, CN1, RAN2	Ericsson	5.2		
S3-99308	Analysis of the window mechanism for sequence number management	Ericsson	9.2.9		
S3-99309	Intended R2 contribution. Inclusion of message parameters for Integrity Protection	Ericsson	9.2.6		
S3-99310	Analysis of distribution of security parameters between GSM-UMTS	Ericsson	9.2.5		
S3-99311	License Policy	Mitsubishi Electric Corporation	7		
S3-99312	Draft CR to 33.102 on integrity procedures
	Nokia	9.2.6		
S3-99313	draft CR on TS 33.102 V3.1.0 (rev. in S3-99336)	DTAG	9.2.1		
S3-99314	Enhanced User Identity Confidentiality and IMSI-Paging	Mannesmann Mobilfunk	10.1		
S3-99315	Liaison Statement: Answer to the liaison on the time constraints on the execution of cryptographic algorithms	3GPP TSG SA 2	4.1		
S3-99316	Liaison Statement: Answer to the Liaison Statement on Authentication for Mobile IP Operations in UMTS	3GPP TSG S2	4.1		
S3-99317	Comments regarding f8 and f9 design	ETSI SAGE 3GPP algorithms Task Force	7		
S3-99318	LS on Terminal Service Implementation Capabilities in the security domain (more recent version in S3-99323)	T WG2/SWG6
	-		
S3-99319	Unclear procedure and item for USIM security feature	NTT DoCoMo	9.2.8		
S3-99320	Proposal and Discussion of USIM security features	NTT DoCoMo	9.2.8		
S3-99321	Security Requirements for USIM	NTT DoCoMo	9.2.8		
S3-99322	Brief response to S3-99308 on the window mechanism for sequence number management	Siemens AG	9.2.9		
S3-99323	LS on terminal Service Implementation Capabilities in the security domain (T2-99724) (more recent version than S3-99318)	T2-SW6	5.2		
S3-99324	Over the air management of windows and list sizes 	Siemens	9.2.9		
S3-99325	3G TR 33.900, A guide to 3rd Generation Security, Version 0.1.0	Rapporteur (Charles Brookson)	9.8	noted	
S3-99326	draft LS to S2 on Authentication for Mobile IP Operations in UMTS			rev. in S3-99339	
S3-99327	Resources for cryptographic algorithms in the USIM	Rapporteur		rev. in S3-99335	
S3-99328	Draft CR to 33.105 on MAC used for data integrity of signalling messages	Rapporteur		rev. in S3-99337	
S3-99329	Additional Terminal Baseline Implementation	S3	5.2		
S3-99330	draft LS to R2, response to LS from Statement on ciphering mechanisms in Case of multiple RABs in R2-99983 = S3-99288	S3	5.2		
S3-99331	Drafting Criteria for Algorithm evaluators responses	S3	7	agreed in principle	
S3-99332	CR 33.102-015 on secure UMTS-GSM interoperation	S3	9.2.5	agreed	
S3-99333	CR 33.102-013 on integrity protection procedures	S3	9.2.6	agreed	
S3-99334	CR 33.102-014 on security of MAP-based transmission	S3	9.2.1	agreed	
S3-99335	CR 33.105-001 on Resources for cryptographic algorithms in the USIM	S3	9.4	agreed	
S3-99336	LS to S2 on Principles for secure GSM-UMTS interoperation	S3	4.2	agreed	
S3-99337	CR 33.105-002 on MAC used for data integrity of signalling messages	S3	9.4	agreed	
S3-99338	CR 33.102-012 on Re-organisation of clause 6	S3	4.2, 9.2.8	agreed	
S3-99339	LS to S2 on Authentication for Mobile IP Operations in UMTS, revision of S3-99326	S3	5.1	agreed	
S3-99340	draft CR 33.102-016 on Network-wide confidentiality	Vodafone		rev. in S3-99344 agreed by e-mail after S3#6	
S3-99341	draft CR 18 to 33.102 on support for multiple authentication algorithms and keys	Siemens		rev. in S3-99349 agreed by e-mail after S3#6	
S3-99342	draft CR to 33.102 in Over the air management of window and list sizes	Siemens		withdrawn	
S3-99343	-- reserved for LS to R3, cc to R2, RAN, T2, response to draft LS from R3 in S3-99305 --			to be distributed by e-mail for agreement by AB	
S3-99344	CR 33.102-016 on Network-wide confidentiality	S3		agreed in S3 by correspondence	
S3-99345	CR to 33.102 on generalised scheme for sequence number management (final version is S3-99352)	Siemens		agreed as S3-99352	
S3-99346	LS to S2 on support for VHE/OSA stage 2 (response to S3-99291 = S2-99793)	S3		approved	
S3-99347	LS to N2 on MAP security (answer to N2-99A42 = S3-99286)	S3		approved	
S3-99348	CR 33.102-017 on Network-wide confidentiality	S3		agreed in S3 by correspondence	
S3-99349	CR 33.102-018 on Support for window and list mechanisms for sequence number management in authentication scheme	S3		agreed in S3 by correspondence	
S3-99350	CR 33.102-019 on Modification of text for window and list mechanisms	S3		agreed in S3 by correspondence	
S3-99351	CR 33.102-020 on Cipher/integrity key setting (revised version of CR in S3-99265)	S3		sent to SA for approval by correspondence after SA5	
S3-99352	CR 33.102-021 on generalised scheme for sequence number management	S3		sent to SA for approval by correspondence after SA5	
S3-99353	S3#6 meeting report	AB			

Annex B: Participants

Name	Company	SDO	
Prof. Michael Walker (Chairman)	VODAFONE Group Plc	ETSI	
Ansgar Bergmann (Secretary)	ETSI	ETSI	
Wael Adi	BOSCH TELECOM DANMARK A/S	ETSI	
Adnan Al-adnani	PANASONIC MOBILE COMMUNICATI	ETSI	
Stefan Andersson	ERICSSON L.M.	ETSI	
Nigel Barnes	MOTOROLA Ltd	ETSI	
Colin Blanchard	BT	ETSI	
Rolf Blom	ERICSSON L.M.	ETSI	
Charles Brookson	DTI	ETSI	
Takeshi Chikazawa	Mitsubishi Electric Co.	ARIB	
Per Christoffersson	TELIA AB	ETSI	
Masahiro Furuse	NTT DoCoMo	ARIB	
Guenther Horn	SIEMENS AG	ETSI	
Peter Howard	VODAFONE Group Plc	ETSI	
Brian King	Motorola Inc.	T1	
Mariko Kishi	Mitsubishi Electric Co.	ARIB	
Geir Køien 	TELENOR AS	ETSI	
Michael Marcovici	Lucent Technologies	T1	
Sebastien Nguyen Ngoc	France Telecom	ETSI	
Valtteri Niemi	NOKIA Corporation	ETSI	
Ludovic Rousseau	GEMPLUS Card International	ETSI	
Dr. Roland Schmitz	Deutsche Telekom AG	ETSI	
Marco Tosalli	TELECOM ITALIA S.p.A.	ETSI	
Peter Trautmann	BMWi	ETSI	
Berthold Wilhelm	BMWi	ETSI	
Annex C: Decision of S3#6 
For decisions on CRs, Liaison Statements and Specifications, see Annex E, F and G. 
•	S3#6 approved the agenda.
•	The meeting report was approved, see S3-99257.
•	The S3#5bis meeting report was approved, see S3-99273.
•	S3#6 agreed to change the term IMUI (TMUI) to IMSI (TMSI) in its documentation.
•	Mike Walker will talk to the S2 Chairman and give him the responses needed to questions of S2-99636.
•	S3#6 approved the terms of reference in S3-99278.
•	S3-99331, Drafting Criteria for Algorithm Evaluators Responses, prepared by a side meeting of S3#6 chaired by Charles Brookson, was approved in principle. It should be reflected in an appropriate way in the letter to evaluator candidates.
•	The principles of S3-99309 were agreed.
•	It was agreed that duplications of information in 33.102 should be avoided in 33.103. 
•	S3 approved S3-99276, the status of S3 specifications.
Annex D: Action points from S3#6
•	Ansgar Bergmann to create S3-99343, LS to RAN3, cc to RAN2, RAN and T2, to be sent as response to the draft LS in S3-99307, with CR 33.102-013 (S3-99233) attached. 
•	Response to S3-99923?
•	Action point Tim Wright, Bart Vinck: To send the presentations for AHAG, TR 45-2 (CN) and TR45-5 to the S3 mailing list on Wednesday. Comments have to be made until Friday noon.
•	MExE security to be dealt with further at S3#7.
•	Integrity protection for SMS should be included (e.g., as a protected mode which can or can't be applied). CR required for S3#7.
•	Integrity protection for general user data: This should be removed or completed. CR required for S3#7.
•	Roland Schmitz to prepare a CR to 33.102 at S3#7 to at least mention INAP security. 
•	Peter Howard to distribute an updated version  of CR 33.102-017 until Monday, 4 October 1999 evening (Greenwich Time): Done: The updated CR is S3-99348.
•	CR 33.102-015 on UMTS - GSM compatibility in s3-99332, presented by Rolf Blom. was agreed. 
•	A revision to be presented by Peter Howard adding a note that, e.g. due to implementation aspects, further changes may be necessary. Done: S3-99344.
•	Attention: One figure is out of range!
•	GH to send out a revision of draft CR 33.102-018 until Monday, 4 October 1999, evening (Greenwich time) for agreement by correspondence in S3 until Friday, 8 October 1999. Done: CR 33.102-018 in S3-99349 and CR 33.102-019 in S3-99350.
•	It was agreed at S3#6 that an updated version of 33.103 incorporating all relevant updates relevant to the USIM would be sent by the rapporteur, Colin Blanchard, to T3 on Sunday, 3 October 1999; that Colin Blanchard would distribute a draft version incorporating all necessary changes, intended for approval at SA#5, on Wednesday, 6 October 1999 to the S3 mailing list for comments until Thursday, 7 October 1999; that Colin Blanchard would distribute the resulting version to the S3 mailing list on Friday, 8 October; that Ansgar Bergmann would do the necessary editorial changes for presentation as V2.0.0 to SA#5 for approval on the week-end 9-10 October 1999.
•	Action point for S3#7: The parameter COUNT for ciphering shall be re-named to COUNTC
•	TS 33.107 to be prepared for SA approval at SA#6.
•	GH, AB to prepare it during next week for Korea.
•	The interested parties to provide the complete description of a robust mechanism and all necessary associated CRs for introduction of enhanced user identity confidentiality to S3#7.
•	To look at the updated version of p-c-sec.
•	Peter Howard to distribute an updated version of the work plan.
•	Charles Brookson to draft some text for a press release.

Annex E: CRs agreed by S3 for approval at SA#5
TSG_MEETING	SPEC	CR	REV	3G_PHASE	CAT	SUBJECT	WG_DOC	WG_STATUS	
SP_05	33.102	012			D	Re-organisation of clause 6	S3-99338	agreed	
SP_05	33.102	013			C	Integrity protection procedures	S3-99333	agreed	
SP_05	33.102	014			C	Security of MAP-Based Transmissions	S3-99334	agreed	
SP_05	33.102	015			C	Secure UMTS-GSM Interoperation	S3-99332	agreed	
SP_05	33.102	016			C	Network-wide confidentiality	S3-99344	agreed	
SP_05	33.102	017			C	Authentication management field	S3-99348	agreed	
SP_05	33.102	018			C	Support for window and list mechanisms for sequence number management in authentication scheme	S3-99349	agreed	
SP_05	33.102	019			D	Modification of text for window and list mechanisms	S3-99350	agreed	
SP_05	33.102	020			C	Cipher/integrity key setting	S3-99351	agreed	
SP_05	33.102	021			C	A generalised scheme for sequence number management	S3-99352	agreed	
SP_05	33.105	001			C	Resources for cryptographic algorithms in the USIM	S3-99335	agreed	
SP_05	33.105	002			C	MAC used for data integrity of signalling messages	S3-99337	agreed	
SP_05	33.105	003			C	Cipher keystream block length	S3-99337	agreed	
Note: TSG SA approved CR 33.102-020 and CR 33.102-021 by correspondence after SA#5.

Annex F Liaison Statements from S3#6
•	S3-99339, LS to S2 on Authentication for Mobile IP Operations in UMTS, revision of S3-99326 (drafted by Nigel Barnes), answering the LS from S2 to S3 in S2-99587 = S3-99226 Annex A, re-issued at S3#6 as S3-99316, was approved.
•	The responding LS to NS on MAP security in S3-99347 (answer to S3-99286=N2-99A42) was approved.
•	A LS in s3-99330 to R2 (prepared by Charles Brookson), responding to a LS from R2 in S3-99288 = R2-99983, Response to LS on Ciphering mechanisms in case of multiple RABs, was approved.
•	A LS to T2 in S3-99329, prepared by Sebastien Nguyen Ngoc, complementing earlier LS form S3 to T2 SW8 in S3-99252, responding to S3-99290, Liaison Statement from T2 SW8, Cover letter for TR21.904, Terminal Capabilities Report, interim version, was approved.
•	The LS to S2 in S3-99346 on VHE/OSA stage 2, informing on the S3 plans for MExE, CAMEL and SAT, drafted by PH, responding to a LS from S2 in S2-99793 = S3-99291, was approved.
•	S3#6 approved a LS to S2 in S3-99336 (attached: CR 33.102-A015) on the topic of GSM-UMTS interworking.
•	Ansgar Bergmann to create S3-99343, LS to RAN3, cc to RAN2, RAN and T2, to be sent as response to the draft LS in S3-99307, with CR 33.102-013 (S3-99233) attached. 
Annex G Specifications for approval / information at SA#5
-	33.103 as V2.0.0 after agreement by correspondence in S3 for approval
-	33.902 for information. 

Note: Time was not sufficient to prepare 33.902 as version 1.0.0 to SA#5 for information (as the main part of the document was only available in PDF and could not be re-formatted). Instead version 0.1.0 was presented. Nevertheless, SA#5 approved that version to become V3.0.0.