3GPP TSG SA WG3	draft S3-99499
Meeting #8, Sophia Antipolis, 16-19 November, 1999

Source:	Secretary TSG SA WG3 (Ansgar Bergmann)
Title:		Report of TSG SA WG3 Meeting #8 - draft 06

Table of contents

1	Opening of the meeting; general	4
2	Approval of the Agenda	5
3	Registration of input documents and assignment of input documents to agenda items	6
4	Approval of meeting reports	6
TSG-SA3 Meeting no. 7	6
SMG10 Meeting no. 2/99	7
SMG10 ad hoc meeting, 26th November 1999	8
SMG10 WPD meeting	8
5	Reports / Liaisons from other 3GPP and SMG groups	8
5.1	TSG-SA plenary and WGs, SMG plenary	8
5.2	TSG-CN, TSG-RAN, TSG-T, SMG STCs	9
5.3	3GPP partners and their bodies	9
5.4	Others (GSMA, GSM2000, T1P1, SAGE, TIA TR-45, etc.)	10
5.4.1	GSM Association Plenary (including Security Group and GSM2000 Working Party)	10
5.4.2	SAGE	10
5.4.3	TIA	10
6	Status of 3G security	11
7	2G security issues (morning of 17th)	11
7.1	LCS	11
7.2	GPRS	11
7.3	Cryptographic algorithm management	12
7.4	IST	12
7.5	CTS	12
7.6	Security of terminals supporting user input storage	12
7.7	Review of work items for 2G	12
8	3G security issues	12
8.1	Cipher development	12
8.2	Authentication algorithm	13
8.3	Terminal security	13
8.4	GLR security review	14
8.5	Mobile IP / all-IP core network security review	14
8.6	MExE security review	14
8.7	TIA TR-45 activity	15
8.8	Interworking GSM - 3G	16
9	Amalgamation of S3 and SMG10	16
10	Working party meetings	16
10.1	SMG10-WPA: Mechanisms	16
10.2	SMG10-WPB: Services	16
10.3	Joint S3 / SMG10-WPD: Lawful Interception	16
10.4	Ad hoc on 33.102	16
11	Review of draft 3G specifications	17
11.1	TS 33.107, Lawful interception architecture	17
11.2	TR 33.900, Guide to 3G security	17
12	Identification and review of CRs and resolution of open issues	17
12.1	TS 33.120, Security principles and objectives	17
12.2	TS 21.133, Security threats and requirements	17
12.3	TS 33.106, Lawful interception requirements	17
12.4	TR 33.901, Criteria for cryptographic algorithm design process	17
12.5	TS 33.102, Security architecture	18
12.6	TS 33.103, Integration guidelines	19
12.7	TS 33.105, Cryptographic algorithm requirements	19
12.8	TR 33.902, Formal analysis of security mechanisms	19
13	Update 3G project plan	19
13.1	Check progress against milestones	19
13.2	Plan review of other specifications to ensure that security is properly integrated	19
14	Any other business	20
15	Reports from working parties, liaison statements and documents for approval	20
16	Future meetings dates and venues	20
17	Close of meeting	20
Annex A: List of documents	21
Annex B: Participants	22
Annex C: Decision of S3#8	23
Annex D: Action points from S3#8	23
Annex E: Status of CRs	25
Annex F: Liaison Statements from S3#8	26
Annex G: Specifications for approval / information at SA#6	26

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 objectives of the meeting:
-	to stabilise the SA3 deliverables;
-	to progress outstanding issues:
-	authentication (in particular: applicability of authentication procedures for 3GPP2);
-	terminal security - including ME-USIM interface, IMEI security;
-	visibility and configurability- cipher indicator;
-	GLR security;
-	mobile IP including adaptability of 3GPP security mechanisms to an all IP based network;
-	to establish a process for verifying that security functions and protocols are properly implemented in the other specifications in a timely manner;
-	to integrate SMG10 and TSG SA WG3, to outline a work programme for the combined group;
-	to work out security aspects of automatic establishment of  roaming agreements;
-	to specify means for secure transfer of billing records.1

•	The objectives of S3#8 were approved.

Mike Walker summarised the status of specifications:

TS33.120	Security principles and objectives	Approved at SA#3	Stable.	
TS21.133	Security threats and requirements	Approved at SA#3.	Proposed CR on data integrity of user traffic presented at S3#8.	
TS33.102	Security architecture	Approved at SA#3. 
11 CRs approved at SA#4. 
10 CRs approved at SA#5.	Several CRs being developed. 	
TS33.103	Integration guidelines	Approved at SA#5.	CRs expected to align with 33.102.	
TS33.105	Cryptographic algorithm requirements	Approved at SA#4. 
3 CRs approved at SA#5.	CRs may be required to align with 33.102.	
TR33.901	Criteria for cryptographic algorithm design process	Approved at SA#4.	Stable.	
TS33.106	Lawful interception requirements	Approved at SA#4. 	Draft CR presented at S3#8 for information.	
TS33.107	Lawful interception architecture and functions	Approval at SA#6 planned.	Originally planned for approval at SA#5. Document not yet stable. Final draft to be presented at S3#9.	
TR33.900	Guide to 3G security	Approval at SA#6 planned.	Draft presented at S3#6. Final draft must be available at S3#9.	
TR33.902	Formal analysis of security mechanisms	Approved at SA#6.	Some sentences for the scope and a CR to add the second paper are required.	

Comments at S3#8: Some of the outstanding issues relate to R99, some to R2000. This was clarified more during the meeting:

2	Approval of the Agenda
•	S3#6 approved the following agenda (based on S3-99398):

1	Opening of the meeting
2	Approval of the agenda
3	Registration and assignment of input documents
4	Approval of meeting reports
4.1	TSG-SA3 Meeting no. 7
4.2	SMG10 Meeting no. 2/99
4.3	SMG10 ad hoc meeting, 26th November 1999
5	Reports / Liaisons from other 3GPP and SMG groups
5.1	TSG-SA plenary and WGs, SMG plenary
5.2	TSG-CN, TSG-RAN, TSG-T, SMG STCs
5.3	3GPP partners and their bodies
5.4	Others (GSMA, GSM2000, T1P1, SAGE, TIA TR-45, etc.)
6	Status of 3G security
7	2G security issues (morning of 17th)
7.1	LCS 
7.2	GPRS
7.3	Cryptographic algorithm management
7.4	IST
7.5	CTS
7.6	Security of terminals supporting user input storage
7.7	Review of work items for 2G
8	3G security issues
8.1	Cipher development
8.2	Authentication algorithm
8.3	Terminal security
8.4	GLR security review
8.5	Mobile IP / all-IP core network security review
8.6	MExE security review (afternoon of 17th)
8.7	TIA TR-45 activity (afternoon of 17th)
9	Amalgamation of S3 and SMG10?
10	Working party meetings?
10.1	SMG10-WPA: Mechanisms
10.2	SMG10-WPB: Services
10.3	Joint S3 / SMG10-WPD: Lawful Interception
11	Review of draft 3G specifications
11.1	TS 33.107, Lawful interception architecture
11.2	TR 33.900, Guide to 3G security
12	Identification and review of CRs to approved 3G specifications and resolution of open issues
12.1	TS 33.120, Security principles and objectives 
12.2	TS 21.133, Security threats and requirements
12.3	TS 33.106, Lawful interception requirements
12.4	TR 33.901, Criteria for cryptographic algorithm design process
12.5	TS 33.102, Security architecture
12.6	TS 33.103, Integration guidelines
12.7	TS 33.105, Cryptographic algorithm requirements
12.8	TR 33.902, Formal analysis of security mechanisms
13	Update 3G project plan 
13.1	Check progress against milestones
13.2	Plan review of other specifications to ensure that security is properly integrated
14	Any other business
15	Reports from working parties, liaison statements and documents for approval
16	Future meetings dates and venues
17	Close of meeting

3	Registration of input documents and assignment of input documents to agenda items
See Annex A.
4	Approval of meeting reports
TSG-SA3 Meeting no. 7
•	The report in S3-99397 was approved.
Motorola had asked for the inclusion of the following statement into the S3#7 meeting report:
	"Motorola stated that they might or might not have IPR with respect to the specifications being drawn up by this working group. However, if Motorola does have any IPR with respect to any of these specifications, then Motorola is prepared to grant irrevocable licenses on fair, reasonable and non-discriminatory terms and conditions in accordance with the ETSI IPR Policy, subject to the condition that Motorola is given a reciprocal license."
However it was concluded at S3#8 that this statement should rather be sent in a letter to the ETSI Director General than stated in the meeting report.
Action points from S3#7:
•	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. Superseded.
•	Integrity protection for SMS should be included (e.g., as a protected mode which can or can't be applied). CR required for S3#8. Integrity protection for general user data: This should be removed or completed. At S3#7, a principle agreement was reached. Possibly CRs required for S3#8. Bart Vinck will draft a CR to 21.133 to reflect the working assumption on SMS and user data integrity protection. Done.
•	TS 33.107 to be prepared for SA approval at SA#8. Done: See s3-99399
•	Charles Brookson to draft some text for a press release, making a wider public aware of the 3GPP security specifications: This should be done after SA#6.
•	Geir Køien to contact S2 and to agree a short paper sketching what the contents of the S2 presentation on mobile IP to S3 should be. Interested S3 delegates should join the activity. (S3 delegate Steven Bare indicated his participation.)
•	S3-99377: RB to draft an answer as S3-99393 after S3#7. Done.
•	Colin Blanchard to co-ordinate an e-mail group to further study MExE security aspects and to respond to the LS in S3-99297 and S3-99379; to prepare proposals for MExE security at S3#8. Done, action point handed over to Tim Wright.
•	Wael Adi to co-ordinate an e-mail group to elaborate proposals how to proceed on IMEI security. E-mails should be sent to the S3 e-mail exploder and should contain the string "IMEI security" as sub-string of the subject field. Done, see S3-99401.
•	PH to draft a CR 33.102-025 to shorten KSI to 3bits (to become S3-99389). Done.
•	RB to create S3-99395, CR 33.102-023r1 on Distribution of Authentication vectors between VLRs/SGSNs (rev. of S3-99369). RB to create S3-99396, CR 33.102-024r1 on Secure UMTS-GSM Interoperation (rev. of S3-99370) for S3#8. Done.
•	Some further minor changes to 33.103 will be necessary: KSI (3 bits), AUTN (112-144 bits), GI instead of GMSI. Done.
•	GH to provide an updated main part of 33.902, some sentences for the scope and a CR for addition of the second paper. Done.

SMG10 Meeting no. 2/99
•	The report in S3-99430 was approved.
Action points:
•	It had been commented at SMG#29 that SMG10/TSG SA WG3 should look at security related questions of the GLR concept. So far, input has not yet been received by SMG10.
•	Mike Walker to draft a LS to SMG on GEA2.
•	Simon Collins, Ansgar Bergmann: To prepare the report on MAP security as a report for SMG#30.
•	Ansgar Bergmann and Henri Gilbert should check GSM 03.20 and other specifications to prepare the necessary change requests to ensure that ciphering is mandatory for GPRS: Closed, action transferred to SMG10 WPA.
•	Mike Walker will write a Liaison Statement to TSG CN WG2 that there must be a network option whether to apply IST to emergency calls. Done: S3-99412.
•	A LS to TSG CN WG2 in S3-99412 was approved.
•	SMG10 to discuss AP99-074 (= Annex A of Tdoc SMG P‑99‑542), a liaison statement from SMG9 to SMG10 and SMG concerning possible security issues with handsets supporting a user input storage mechanism: Done, see 7.6.
•	Ansgar Bergmann should make the latest version of FM stage 1 available to SMG10: Done.

SMG10 ad hoc meeting, 26th November 1999
•	The report in S3-99440 (revision of S3-99429) was approved.
SMG10 WPD meeting
The report in S3-99404 was noted. 
5	Reports / Liaisons from other 3GPP and SMG groups
5.1	TSG-SA plenary and WGs, SMG plenary
S3-99419 is a LS fromS1 to T3, copy to S3, on Support of GSM Services within the USIM application. The document was noted. It informs that 
-	eMLPP is required for release ´99. The stage 1 specification (22.067) has been transferred to 3GPP.
-	S1 has concluded that the ASCI services VGCS and VBS are not part of 3G release '99. The requirements for these services in future 3G releases are for further study. However, a general requirement in 22.101 is that a UICC shall be able to be used for access to GSM services. This means that the ASCI services need to be supported by the UICC. Whether this requires that the relevant fields are included in the USIM application (or may be supported via the SIM application) is a decision which is left open to T3.
-	Network Indication of Alerting: currently not considered as a part of 3GPP work.
-	SIM application toolkit: required for 3G release ´99. 
-	Simultaneous use of multiple USIMs: the requirement to support multiple USIMs on the same UICC exist, but only for the purpose of selecting one active at a time. 
-	Concerning ME personalisation, the document proposes to transfer 22.022 to S3. This was accepted by S3#8.
•	S3 accepted prime responsibility for 22.022 (ME personalisation). Mike Walker will inform the S1 chairman and also report this to SA#6.
Report from SMG#30: Mike Walker presented S3-99414, Report to SMG10 from SMG#30:
-	SS7 Security: The report prepared by SMG10 had been accepted by SMG#30 and the note had been taken that work will now go to SA3. SMG#30 asked the report to be turned into a TR.
-	The CR to 03:20 on introduction of EDGE variant of A5 had been approved by SMG#30. The corresponding LS on use of A5 for EDGE had been noted by SMG#30.
-	The CR to 03.20 on clarification of triplet re-use had been approved by SMG#30.
-	The LS on use of 64 bit Kc had been noted and the timing agreed by SMG#30, but concern had been expressed at SMG#30 over roaming if some operators have BTSs which use the full Kc.
-	The LS on GEA2 had been presented to SMG#30; several manufacturers had reported that they have applied for GEA2, but have not yet received the specification. SMG#30 asked SMG10 to propose a timetable for introduction of GEA2.
-	The LS to T1P1 on LCS had been noted by SMG#30.
-	Mike Walker had presented the conclusions of the SMG10 study of SMS abuse to SMG#30, but did not formally table the LS because some of the text is confusing. He advised that operators contact their lawyers with regard to liability for content. A revised document should be provided to SMG. 
-	SMG had welcomed the proposal of amalgamation of SMG10 and SA3.
-	There had been some discussion at SMG330 on the way in which the GSM algorithms are distributed.
-	The CRs on IMEI security had been accepted by SMG#30 with some (minor) change and date of June 2002 for full compliance. Final versions of CRs should be elaborated under leadership of SMG10.
Clarifications at S3#8/SMG10-99#3: 
-	On the usage of a full 64 bit length for Kc, it had been agreed at SMG#30 to make the necessary changes of equipment available by May 2000; Charles Brookson reported to S3#8/SMG10-99#3 that GSMA had decided at its plenary to introduce the necessary changes in the field until end of 2000. It was emphasized at S3#8/SMG10-99#3 that if operators do not keep to that schedule, roaming into those networks from PLMNs using the full length will always fail.
	Timetable for the introduction of GEA-2: See 7.2.
•	IMEI security: Drafting of final versions of CRs has been postponed at S3#8/SMG10-99#3, and should be done in time for SMG#31.
The SMG10 status report to SMG#30 (slide presentation) in S3-99413 was noted by S3#8/SMG10-99#3.
5.2	TSG-CN, TSG-RAN, TSG-T, SMG STCs
•	LS T3-99364 from T3 to S3: Clarification of USIM related security issues in 33.102: As a response, S3-99437, LS to 3GPP TSG-T3 on Clarification of USIM-related security issues in 33.102 and 33.103, was approved.
S3-99405, Liaison Statement NP-OSA99025 from CN on security issues in VHE/OSA: This document asks whether there are outstanding security requirements in the area of service capability features. Answer: There are no requirements identified in addition to those already identified for CAMEL, SAT and MExE.
•	As a response to S3-99405, Liaison Statement NP-OSA99025 from CN on security issues in VHE/OSA, S3-99448, LS to TSG CN OSA ad-hoc, copy to TSG SA WG1, TSG SA WG2 on Security issues in VHE/OSA, was approved.
S3-99431, LS R2-99G84 from RAN on ciphering complexity: It was clarified that the cipher algorithm is designed to protect against known/chosen text attacks. It was not clear at the meeting whether the text in the LS is correct: It was presumed that the complexity might be higher if it was required to have different masks at LS re-transmission. Nevertheless the information should be given back that there is neither a requirement to change nor to keep the mask.
•	Later in the meeting, S3-99457, revising S3-99445, LS to RAN on ciphering L2 re-transmissions, answering S3-99431, was approved.
S3-99435: This LS form N2, informing that N2 hasn't got sufficient time to specify the necessary changes for MAP security, was noted.
•	S3-99402, LS T3-99364 from T3 to S3 on Clarification of USIM related security issues in 33.102: As an answer to S3-99402 (and S3-99432), S3-99437, LS to 3GPP TSG-T3 on Clarification of USIM-related security issues in 33.102 and 33.103 was approved.
5.3	3GPP partners and their bodies
The meeting was informed that China (CWTS) joined 3GPP. 
An extension of responsibilities has been proposed in other fora (see P-99-753, Committee Correspondence, Source: 2G/3G SIM, USIM & R-UIM officials meeting): All major players in the area of mobile telecommunication smart cards proposed that SMG9 extends its role to act as the central focus point for all next generation telecommunications smart cards, in the following areas:
-	physical interface specifications
-	the common logical interface
-	file ID allocation (DFs) at the common level, respecting existing directory structures
-	shared data that is technology independent (e.g. the phone book).
5.4	Others (GSMA, GSM2000, T1P1, SAGE, TIA TR-45, etc.)
5.4.1	GSM Association Plenary (including Security Group and GSM2000 Working Party)
Charles Brookson gave a report describing that:
-	support was given by the Plenary to the IMEI security measures, and operators were asked to support the concept at SMG Plenary;
-	a new document SG07 on GSM Risks and Threats was presented and approved;
-	changes were made to distribution of the algorithms so that they could be distributed to a wider circulation than just operators;
-	some discussions took place at Plenary on the false base station attack. A discussion took place about the fact that the encryption indicator would help the customer detect the attack, the desire was expressed that perhaps SMG10 might consider re-evaluating the work it had done on mutual authentication for GSM. The need for this was because it had become apparent that cheaper equipment had become available than the normal test equipment;
-	the Plenary had chosen a date of end year 2000 for operators to bring in and have available a 64-bit length for Kc. This was because it had become apparent that some manufacturers had base stations that needed hardware modification. It was necessary that all operators must be able to support 64 bits to allow for roaming mobiles;
-	the EDGE standard required different test data to be produced for A5. The GSMA was funding this work;
-	the Security Group was developing a new authentication algorithm using an operator variant key. The GSM 2000 group was also taking this up;
-	the next GSM 2000 (joint SMG10 & GSMA SG working Group will be on the 16th December.
5.4.2	SAGE
Per Christoffersson reported on the progress:
The status of the algorithm work in the SAGE 3GPP Algorithms Task Force was presented by Per Christoffersson. The Task Force have had 5 meetings , the last one the previous week . 
The external evaluators, Nokia, Ericsson and Motorola have taken active part and contributed well.  S table specifications of the algorithms were accomplished last week.  The SAGE task force is now in the process of turning over documents to the independent evaluators which have been selected by S3. The three teams which have now been contracted by ETSI are Bart Preneel, Leuven (B) /Lars Knudsen, Bergen (N), Ecole National Superieure, Paris (F) and Royal Holloway (UK).  These parties are now receiving the following documents for a one month study of the algorithms: 
-	formal specification of f8 and f9;
-	formal specification of KASUMI;
-	conformance test data;
-	statistical test results;
-	3GPP 33.102;
-	3GPP 33.105;
-	a note from the designers;
-	a note on the context for the algorithms.
The SAGE task force will consider the results of these evaluations at a meeting in December 14-15 and take appropriate action. If all goes well delivery to 3GPP can be accomplished in late December/early January.
All members of the SAGE TASK Force have expressed the wish that the algorithm specifications will be published as 3G specifications. 
5.4.3	TIA
See section 8.7.
6	Status of 3G security
7	2G security issues (morning of 17th)
7.1	LCS 
Asbjørn Grøvlen presented S3-99441, a presentation on the status of LCS.
The LCS features BSS centric architecture (SMLC on BSS level), E-OTD and GPS were confirmed at SMG#30 in R98, and the CRs were approved on condition of timely presentation of corresponding R99 CRs. The outstanding CRs and specifications are targeted for SMG#30bis.
S3-99428 is a LS from T1P1 on Location Services – Encryption Key Management Procedures: T1P1 asks SMG10 for advice regarding Encryption Key management procedures. The broadcast messages are encrypted using the DES algorithm with a 56 bit key; the key is distributed to the MS with point-to-point signalling messages (encrypted with A5). In the network keys are transported unencrypted on the following interfaces: 
-	SMLC - BTS, 
-	co-ordinating SMLC - other SMLC
-	key management entity - co-ordinating SMLC.
T1P1 also asks for endorsement of the security aspects of GSM 04.35.
Comments of S3#8/SMG10-99#3:
-	The clear text transmission within the network of the keys is current practice for A5, so the intended way does not fall below the standard GSM level.
•	The LS to T1P1 on LCS in S3-99443 answering S3-99428, was approved.
7.2	GPRS
Change requests on mandatory ciphering for GPRS: CRs to 03.20, possibly 02.09, 03.60, 02.60 and 04.08 might be necessary.
Time scales for introduction of GEA-2: 
Operators expressed the wish to introduce GEA-s from mid 2000 onwards. Manufacturers expressed that they have to consult at home in order to establish a realistic transition plan; as a possible date for introduction, mid 2002 was mentioned. 
•	Mike Walker to check whether there are export restrictions for GEA-1 or GEA-2. It had been identified that there are problems to get the GEA-2. This should also be discussed with ETSI secretariat. At the moment GEA-2 is confidential. The view was expressed that this should be the recommended handling for 64 bit key algorithms.
•	It was agreed that all new GSM and 3G cipher algorithms (including KASUMI) should be designed so that they could be published, and that they should be published.
Note: 	BEANO, a 128 bit key algorithm designed for usage between public operators, is confidential and is probably restricted to CEPT. The decision above does not extend to BEANO. There is a publicly available requirement specification for BEANO (a TC SEC document). Per Christoffersson will discuss an extension of application of BEANO in SAGE or the possibility to design a new algorithm for that purpose.
•	RB to draft a LS to SAGE on BEANO and publication of algorithms.
It was also suggested to study the future use of KASUMI for GPRS.
•	To establish a time plan and to check for necessary CRs.
7.3	Cryptographic algorithm management
No input received.
7.4	IST
No input received.
7.5	CTS
The current version of GSM 01.56 will be made available on the ETSI server but it will not be published by ETSI until a clarification from the rapporteur has been received whether there are outstanding essential corrections (a CR had been approved by SMG#29, but had been based on an unofficial interim version which had some significant differences to the official version 7.0.0.)
Usage of A5/1 for CTS: Charles Brookson has sent a formal letter to France Télécom / CNET (as the owner of A5/1) whehter usage for CTS is permitted. An answer is outstanding.
•	CR to 03.20, LS to GSMA.
Note: 	It was reported that A5/2 is still in use in several networks.
7.6	Security of terminals supporting user input storage
Tdoc SMG10 AP99-074 is a LS from SMG9 to SMG and SMG10 on Possible security issues with handsets supporting a user input storage mechanism. SMG#29 had asked SMG10 to study it and to elaborate proposals. The document had been tabled at the SMG10 ad hoc in October 1999 but had not been treated due to lack of time.
Problem reported by SMG9: It has come to SMG9's attention that there are MEs that store recently entered information in the ME to be offered to the user when new user input is required. SMG9 are concerned that this will prevent sensitive information entered from within Execution environments such as SAT from remaining secret.  SMG9 therefore ask SMG10 to consider the implications of this feature, particularly with reference to application environments and suggest the level of support allowable for this feature. SMG9 ask SMG to recommend that no such feature is enabled during execution environments until SMG10's recommendations are available.
•	Later in the meeting, S3-99458, revising S3-99453, was approved as an answer to AP99-074.
7.7	Review of work items for 2G
Postponed.
8	3G security issues
8.1	Cipher development
A5/1 was obtainable for manufacturers through a "local operator". Now the rules have been changed and manufacturers - as associate members - can directly get it from Charles Brookson.
A5/2 is obtainable from GSMA secretariat.
GEA-1 is available from GSMA, it is also available from ETSI.
GEA-2 is available from ETSI. At SMG#30 the impression was that no manufacturer has received it so far.
For KASUMI, S3 sees the preferable solution to publish the specifications as 3GPP specifications, and then as SDO deliverables. Still, there might be certain export licensing aspects, and clarifications needed concerning ownership/publication fees.
•	Mike Walker will inform 3GPP on the advice from S3 how to publish KASUMI and will take care of the problems mentioned.
8.2	Authentication algorithm
It was debated to which degree a 3G authentication algorithm should be specified in 3GPP. Possibilities:
-	do nothing (leave it to operators);
-	ask SAGE to design an algorithm;
-	ask GSMA to take responsibility;
-	provide 'building kit' based on standard MAC functions.
Vodafone volunteered to become the rapporteur of the requirement specification for an authentication algorithm.
•	Mike Walker to inform SAGE, 3GPP and GSMA that SAGE should elaborate an authentication algorithm or building blocks for an authentication algorithm.
8.3	Terminal security
Wael Adi presented S3-99401, Applications and relevance of secured IMEI for 3GPP. The document compiles statement from the interested parties on IMEI security, describes applications of a secure IMEI, collects requirements from 3G specifications on IMEI security and proposes the following requirements:
-	cryptographic provable identity;
-	identity is not possible to read modify or remove. Any attack on the terminal/unit identity should be time consuming and technically expensive;
-	low-cost implementation;
-	security should have cryptographic level;
-	low network management overhead (small data base);
-	distributed processing (no central data base). 
Wael Adi presented S3-99439, Essential Requirements for secured Identity in 3GPP Mobile Equipment, proposing basic requirements on the mobile equipment to exhibit provable identity for applications such as those in Doc s3 99-401. 
-	Hardware Requirements to enable cryptological identification of a unique terminal:
1.	A tamperproof write-only secret nonvolatile identity SIMEI  (whatever tamperproof  means in the current state of the art technology)
2.	Either  a one way function ( say f8 or f9) which maps this  secret identity SIMEI and a challenge CH into a response RES to prove the existence of the secret identity in the terminal (RES  =   f8,9 ( SIMEI, CH))
	Or : some public-key one way function Fp (say squaring function as Rabin-Lock) which proves the existence of the write-only secret identity in the terminal. RES = Fp(SIMEI, CH1, CH2 ...)
There should be no hardware possibility (trap door) to read  the SIMEI
-	System  Requirements These requirements are highly application and protocol dependent (tbd). 
1.	One or many system protocols which proves the identity for relevant applications
2.	A central data base for some applications. This should be avoided as far as possible
After a long discussion, it was agreed to create a living document, editor Wael Adi, on IMEI security. Scope:
1. Possible levels of security
- basic physical integrity protection
- cryptographic protection (0 knowledge protocol)
- [possible refinements and further levels]
2. Types of services possible with each level of security
3. Technical requirements of each of the security levels.
8.4	GLR security review
Peter Howard gave a summary on the GLR specification work so far, see S3-99410. The current GLR specification is S3-99403. An initial discussion on security aspects took place, however without immediate identification of dangers.
The reason given for establishment of a GLR is the reduction of signalling traffic, however Stefan Pütz reported that there have been earlier contributions also addressing gateway functionalities (e.g., between 3GPP and 3GPP2).
It was agreed that Peter Howard will co-ordinate further activities on GLR security aspects. T-Mobil announced interest to contribute.
8.5	Mobile IP / all-IP core network security review
Per Christoffersson presented S3-99421, CR 33.102-026 on Mobile IP. The CR states the following view: 
•	The introduction of Mobile IP functionality for end users in 3G has no influence on the security architecture for 3G. 
•	IP terminals supporting Mobile IP functionality and used for 3G access must be equipped with Mobile IP security independent of the 3G network security architecture as they must also be possible to use in non-3G networks (e.g. fixed IP networks). 
•	3G networks, supporting Mobile IP functionality, must also support a separate security functionality for Mobile IP to be able to manage Mobile IP terminals. 
•	On the other hand , 3G networks security architecture can not be influenced or reduced by the Mobile IP option as the 3G security must be able to handle non-Mobile IP terminals. 
•	The Mobile IP security functionality must thus be separate from the 3G security and it is also developed in an other forum,  IETF. 
Clarifications at S3#8: The CR is not intended for immediate approval, decisions should be taken when S2 has made a presentation on mobile IP.
Agreement at S3#8: 
-	The proposal is mainly targeted to R99, R2000 might change the approach. 
-	The IETF security functions should be profiled for the 3G environment, that should be a task for S3. This would however not mean to invent new IP security functions.
-	Evolution of 3G security in an overall IP based core network.
•	It was decided to continue discussion on (Mobile) IP security aspects off-line.
S3-99426, Compilation of documents on Mobile IP, was available for information at the meeting.
8.6	MExE security review 
Tim Wright presented S3-99446, a status report on MExE:
Clarifications:
-	A mobile station can use WAP without MExE.
Additional problem areas identified in S3#8:
-	complexity of administrator handling.
Mark Cataldo presented S3-99442, responding to the MExE comments made in S3-99297, and summarising the views of most MExE delegates.
Clarifications, additional information at S3#8: 
-	WAP has not adopted the signed contents concept. The possibility of un-trusted applications to set up calls and to send DTMF was added because it is required for WTA (Wireless Telephony Applications).
-	For all actions triggered by an un-trusted application, the user has to give authorisation. (The user could be anyone having inserted a SIM.) The question was raised whether an application could generate a wrong text prompting for an authorisation (e.g., asking for authorisation for a call with a faked number). Mark Cataldo responded that the authorisation should be given by explicit MMI functions.
-	It was clarified that there are no restrictions for parallel execution of applications.
-	MExE foresees a journal (the exact contents and format are not defined in MExE) to be maintained in the mobile equipment, stored in a secured area.
-	The roots for applications shall be stored in secure areas. It was commented that this secure storage might have similarities with secure IMEI storage.
-	New root keys can be installed under secure conditions.
-	User revocation of permission is possible.
-	Applications would typically downloaded by action of the user, but the initiative could also be taken from the network or by another application.
-	A deletion of the MExE as a whole is not specified.
-	External port access: RB commented that there could be a market for un-trusted applications accessing external ports; it was clarified that at the moment, only trusted applications have access;
-	for the operator, it is rather complex to disable applications on mobile equipment;
Proposed and agreed recommendations of S3#8:
-	a one for all disabling / deletion of applications (as one single action) is not specified, was however recommended.
-	recommendation to list forbidden actions only in the security table: This was seen as a means to simplify the table; Mark Cataldo saw no problem in going that way; however it was commented that there has been a lot of work on the security table, and that S3 has no clear view of the necessities that have driven the MExE group to define the table as it is;
-	external port access: this was seen to be finally the user's responsibility;
-	it should be clear at any point in time whether a trusted or an un-trusted application is acting; 
-	it was proposed to avoid that un-trusted applications run at the same time as trusted applications; this would be difficult when a trusted application is running all the time, e.g., for a calendar / alerting function;
-	it was proposed that a trusted application can propose (to the user) to stop un-trusted applications; however, this was considered to be too dangerous;
-	the operation system should ensure that user input only goes to one application at a time (similar as in a multi-windows system).
•	Later in the meeting, S3-99449, LS to 3GPP TSG-T2 SWG1 (MExE) on MExE R99, was approved as an answer to S3-99438.
8.7	TIA TR-45 activity
Bart Vinck presented S3-99423, Report TR-45.2/TR-45.3.
Clarifications at S3#8:
-	integrity and user data confidentiality are seen by some US operators as value added services (chargeable).
-	in TR-45, there is no requirement to terminate all calls where authentication fails; for example, the call might be transferred to a customer care centre;
-	GSM and current 3GPP R99 do not foresee an information to home network when authentication fails. This was considered an urgent problem in S3#8;
.-	Siemens and Vodafone are preparing a paper how to meet the TR-45 requirements for authentication on common control channels.
•	Later in the meeting, S3-99460, LS to: TIA TR-45.AHAG, cc: TIA TR-45, TR-45.2, TR-45.3, TR-45.5 on Principles concerning the development of a common authentication mechanism to support global roaming (rev. of S3-99454) was approved.
•	To study information exchange on failed authentication between HLR and serving network.
8.8	Interworking GSM - 3G
Hiroshi Aono presented S3-99422, source DoCoMo, proposing to make interoperation between 3GPP and GSM systems as a Terminal Baseline Implementation Capability optional instead of mandatory and to have it as mandatory if the UE supports GSM SIM card.
Sebastien Nguyen Ngoc stated on behalf of France Télécom the preference to keep the feature as mandatory.
•	S3 does not take a decision on S3-99422 but will implement in its specifications the consequences of decisions taken by TSG SA WG1 on the matter of support of conversion functions in the UE.
9	Amalgamation of S3 and SMG10
It was agreed to continue S3 and SMG10 in joint meetings.
10	Working party meetings
10.1	SMG10-WPA: Mechanisms
A meeting was not possible due to lack of time.
•	CRs to make GPRS encryption mandatory.
10.2	SMG10-WPB: Services
A meeting was not possible due to lack of time.
•	CRs for IMEI security.
10.3	Joint S3 / SMG10-WPD: Lawful Interception
There will be a session 1-3 December, Wien, hosted by Siemens.
10.4	Ad hoc on 33.102
S3-99447, a LS from N2 to S3 on Confirmation of TS 33.102 section 6.3.4 Distribution of authentication vectors between VLRs: 
•	CR to 33.102 to be prepared (Bart Vinck): The SN/VLRn cannot send Authentication data request with IMSI but rather with TMSI/LAI to SN/VLRo; normally, only a TMSI but not an IMSI can be available when the subscriber roams into a new VLR area and makes retrieval of authentication vectors necessary. 
S3-99432, LS from T3 to S3 on Request for clarification on 33.103 "Integration Guidelines": TSG-T3 had reviewed 3G TS 33.103 “3G Security: Integration Guidelines” v2.0.0 and asked SA3 to clarify several technical points.
•	As an answer to S3-99432 (and to S3-994020), s3-99437, LS to 3GPP TSG-T3 on Clarification of USIM-related security issues in 33.102 and 33.103, was approved.
S3-99433, LS from RAN on Proposed Reply to LS on Security Algorithm Information in UE Capability was noted.
S3-99434, LS N1-99D06 from N1LS to R3, S3 on Security Algorithm Information in UE Capability: This LS raises the question why information from the MS on cipher capabilities should be able at the MSC/SGSN and argues that this would contradict basic design principles.
S3-99436 is LS R3-99D49 from R3 to SA3, CN1, RAN2 on Security Mode Control procedure.
•	The LS in S3-99461 (revision of S3-99393), answering to S3-99434 and S3-99436, was approved.
11	Review of draft 3G specifications
11.1	TS 33.107, Lawful interception architecture
Berthold Wilhelm presented S3-99399, 33.107 V0.0.5. It is intended to present a stable version to S3#9 which would then presented to SA for approval. 
The chairman emphasized that assistance from other regulators is required. Only the German and UK regulators contribute to the work. This could lead to the assumption that other regulators have no requirements on lawful interception.
On 23-24 November, there will be another joined meeting with TC Security on lawful interception.
Berthold Wilhelm indicated his difficulties to participate at S3 meetings if the invitation doesn't arrive in time.
11.2	TR 33.900, Guide to 3G security
A new version will be circulated towards the end of the month.
12	Identification and review of CRs and resolution of open issues
12.1	TS 33.120, Security principles and objectives 
No input received.
12.2	TS 21.133, Security threats and requirements
CR 21.133-001 on Data integrity of user traffic in S3-99450 was approved.
12.3	TS 33.106, Lawful interception requirements
A CR is expected for S3#8.
12.4	TR 33.901, Criteria for cryptographic algorithm design process
No change intended.
12.5	TS 33.102, Security architecture
•	S3-99451, CR 33.102-024r2 on Secure UMTS-GSM Interoperation (rev. of S3-99407), 
S3-99408, CR 33.102-023r1 on Distribution of AV between VLRs, 
S3-99409, CR 33.102-030 on Handling of the MS UEA and UIA capability information
should be further discussed at S3#9.
S3-99425: This document proposes integrity protection to become optional when a SIM is used instead of a USIM. 
•	A benefit of making integrity protection optional when a SIM is used instead of a USIM was not seen; also such an option would make the system more complex. S3-99425 was rejected.
Sequence numbers: Günther Horn presented S3-99420, Evaluation of alternatives for sequence number management, source: Siemens, proposing to chose one of the schemes for sequence number management in 33.102, the generation of mixed individual/global sequence number in the AuC according to Annex C.6 and the handling of sequence numbers by means of lists according to Annex C.4; furthermore, it is proposed to make the support for protection against counter wrap around (USIM lock out) mandatory.
Views expressed at S3#8: 
-	"The sequence number management is operator specific, a standardisation from interoperability point of view is not necessary."
-	"Selection of one mechanism may simplify life for manufacturers and operators."
In this matter, also S3-99444 and S3-99424 were discussed. The matter should be carried on by Siemens.
•	Siemens should send around an elaboration of its proposal and seek an agreement by correspondence under a 7 days rule. Companies objecting the CR should prepare a counter-CR. Working assumptions: 48 bits maximum length for the sequence number SQN; a minimum size list should be specified; a maximum age for SQNs (in terms of maximum difference between highest and lowest entry in the list) should be controlled by the USIM, manageable via the AMF. It should be checked whether SQN-LO can be introduced in GSM, otherwise it should not be introduced into 3G either.
S3-99406, CR 33.102-029 on AVs in VLR at Location Update: It was commented that this CR is based on the assumption of a simplified sequence number management; also that it might not work with the turbo charger concept.
•	S3-99406, CR 33.102-029 on AVs in VLR at Location Update, was sent back to Siemens for further investigation.
•	S3-99416, CR 33.102-027 clarification of re-authentication during PS connections: There was a possible contradiction with 23.060. Postponed to S3#9.
S3-417: This document raises the problem that the current specifications do not allow the USIM to trigger re-authentication and key setting during a connection; this may be useful in the PS mode where long connections lasting several days might be commonplace. The solution proposed is to allow the USIM to initiate a re-authentication during a long PS session. Another solution would be to require a re-authentication by the network with a minimum frequency so that the USIM would terminated the session if re-authentication is not performed often enough.
•	Agreement: An increased level security is justified; Vodafone should prepare the necessary CRs in N1 and T3, also make them aware of alternative ways, and if it is considered feasible in these groups, the feature should be introduced.
CR 33.102-025 in S3-99389: Note a difference to GSM, where 111 means that a valid key is not available, whereas in 3G it means: "not available for use" (this would include the case that the lifetime has expired). 
•	CR 33.102-025 in S3-99389 was approved.
It was recommended to write another CR clarifying that there is parallel handling of packet domain and circuit domain cipher keys.
•	S3-99459, CR 33.102-022r1 on Refinement of Enhanced User Identity Confidentiality (rev. on S3-99427) was approved. 
Note: 	However it should be checked whether there may be the need to include the new identity in a location update request to a GSM MSC; in this case it could not be longer than an IMSI.
CR 33.102-028 (planned to be issued in S399-418): The document was withdrawn.
•	Further work identified: To elaborate 33.102 annex A.
12.6	TS 33.103, Integration guidelines
•	S3-99415: CR 33.103-004 in S3-99415 was approved.
•	S3-99456, CR 33.103-001r1 on Refinement of Enhanced User Identity Confidentiality (rev. of S3-99362 and S3-99452), was approved.
12.7	TS 33.105, Cryptographic algorithm requirements
•	CR 33.105-005 in S3-99455: in a figure, the direction bit is missing. Approved.
12.8	TR 33.902, Formal analysis of security mechanisms
•	Günther Horn will send an updated version on 22 November to S3. Comments are needed asap.
13	Update 3G project plan 
13.1	Check progress against milestones
Peter Howard presented 3G PD 30.810, Project plan for security, v1.0.0, in s3-99400. Comments were made to the progress (relating to section 3.1). 
•	Peter Howard to distribute S3-99411, Revised S3 update of 3G PD 30.810, Project plan for security, v1.0.0, revising s3-9940.
•	GSM 03.48 has to be transformed into a 3GPP specification.
13.2	Plan review of other specifications to ensure that security is properly integrated
As there is no TSG plenary checking all specifications for completeness, S3 considers it necessary to check whether the security features are correctly included in the TSG specifications.
•	It was agreed 
- to review the main specifications in S3#10; 
- to ask S2 to identify the other relevant specifications, so that they can be studied;
-	S3 will then try to identify missing aspects in spring 2000.
-	Mike Walker will contact the S2 chairman and the co-ordination group.
-	A corresponding  new section 3.4 will be added to 3G PD 30.810, Project plan for security. 
14	Any other business
15	Reports from working parties, liaison statements and documents for approval
16	Future meetings dates and venues
Meeting	Date	Location	Host	
S3#9	7-9 December 1999	Helsinki	Nokia	
S3#10	19-21 January 2000	Brussels	Siemens	
S3#11	22-24 February 2000	Mainz	RegTP	
S3#12	11-14 April 2000 (including joint meeting with AHAG)	Stockholm	Ericsson	
S3#13	23 - 25 May	Tokyo	DoCoMo	

17	Close of meeting
The meeting was closed.

Annex A: List of documents
[separate file]
Annex B: Participants

Name	Company	SDO	participated (x = "yes", - = "no"	
Mike Walker, Chairman	Vodafone	ETSI	x	
Wael Adi	BOSCH TELECOM DANMARK A/S	ETSI	x	
Adnan Al-adnani	PANASONIC MOBILE COMMUNICATIONS	ETSI	-	
Stefan Andersson	ERICSSON L.M.	ETSI	-	
Hiroshi Aono	NTT DoCoMo	TTC	x	
Nigel Barnes	MOTOROLA Ltd	ETSI	-	
Stephen Beer	Dera	ETSI	-	
Colin Blanchard	BT	ETSI	-	
Rolf Blom	ERICSSON L.M.	ETSI	x	
Charles Brookson	DTI	ETSI	x	
Mark Cataldo (at MExE session)	Motorola	ETSI	x (at MExE session)	
Takeshi Chikazawa	Mitsubishi Electric Co.	ARIB	x	
Per Christoffersson	TELIA AB	ETSI	x	
Simon Corfield	Dera	ETSI	-	
Luc de Bie	Siemens Atea	ETSI	-	
Louis Finkelstein	Motorola	T1	x	
Masahiro Furuse	NTT DoCoMo	ARIB		
Günther Horn	SIEMENS AG	ETSI	x	
Peter Howard	VODAFONE Group Plc	ETSI	x	
Rafal Jaczynski	Polkomtel SA	ETSI	x	
Brian King	Motorola Inc.	T1		
Mariko Kishi	Mitsubishi Electric Co.	ARIB		
Geir Køien 	TELENOR AS	ETSI	x	
Michael Marcovici	Lucent Technologies	T1	x	
Semyon Mizikovsky	Lucent Technologies	T1	-	
Sebastien Nguyen Ngoc	France Telecom	ETSI	x	
Valtteri Niemi	NOKIA Corporation	ETSI	x	
Petri Nyberg	Sonera Corp.	ETSI		
Stefan Pütz	T-Mobil	ETSI	x	
Ludovic Rousseau	GEMPLUS Card International	ETSI	x	
Roland Schmitz	Deutsche Telekom AG	ETSI	-	
Vesa Tervo	Nokia	ETSI	x	
Benno Tietz	Mannesmann Mobilfunk	ETSI	x	
Marco Tosalli	TELECOM ITALIA S.p.A.	ETSI	-	
Peter Trautmann	BMWi	ETSI	-	
Bart Vinck	Siemens Atea NV	ETSI	x	
Berthold Wilhelm	BMWi	ETSI	x	
Tim Wright	Vodafone	ETSI	x (at MExE session)	
Ansgar Bergmann (Secretary)	ETSI	ETSI	x	
x = participated

Annex C: Liaison Statements from S3#8
Tdoc S3-99	status	Title	
412	approved, sent	LS to: TSG-CN WG2, copy: TSG-CN, TSG-SA, on the application of IST to emergency calls	
437	approved, sent	LS to 3GPP TSG-T3 on Clarification of USIM-related security issues in 33.102 and 33.103	
443	approved, sent	LS to T1P1 on LCS	
448	approved, sent	LS to TSG CN OSA ad-hoc, copy to TSG SA WG1, TSG SA WG2 on Security issues in VHE/OSA (response to 405)	
449	approved, sent	LS to 3GPP TSG-T2 SWG1 (MExE) on MExE R99	
457	approved, sent	LS to RAN2 on ciphering complexity (rev of 445)	
458	approved, sent	LS to: SMG9, MExE, copy: SMG on Response to liaison statement on possible security issues with handsets supporting a user input storage mechanism	
460	approved, sent	LS to: TIA TR-45.AHAG, cc: TIA TR-45, TR-45.2, TR-45.3, TR-45.5 on Principles concerning the development of a common authentication mechanism to support global roaming (rev. of 454)	
461	approved, sent	LS to: R3, N1, cc: R2, on Response to liaison statement on Security Mode Control procedure and CN handling of classmark information (answer to 434 and 436)