ETSI TS 102 310-2012 Smart Cards Extensible Authentication Protocol support in the UICC (Release 9) (V9 1 0 Release 9)《智能卡 UICC中支持的可扩展鉴权协议 版本9 1 0 R9》.pdf

《ETSI TS 102 310-2012 Smart Cards Extensible Authentication Protocol support in the UICC (Release 9) (V9 1 0 Release 9)《智能卡 UICC中支持的可扩展鉴权协议 版本9 1 0 R9》.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 102 310-2012 Smart Cards Extensible Authentication Protocol support in the UICC (Release 9) (V9 1 0 Release 9)《智能卡 UICC中支持的可扩展鉴权协议 版本9 1 0 R9》.pdf（19页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 102 310 V9.1.0 (2012-09) Smart Cards; Extensible Authentication Protocol support in the UICC (Release 9) Technical Specification ETSI ETSI TS 102 310 V9.1.0 (2012-09)2Release 9 Reference RTS/SCP-T0013v910 Keywords card, protocol, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis

2、 Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The present do

3、cument may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of th

4、e PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/s

5、tatus.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction ex

6、tend to reproduction in all media. European Telecommunications Standards Institute 2012. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Membe

7、rs and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 102 310 V9.1.0 (2012-09)3Release 9 Contents Intellectual Property Rights 4g3Foreword . 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informativ

8、e references 6g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 6g34 Introduction 6g35 Architecture 7g35.1 Architectural Principles 7g35.2 EAP clients discovery 8g35.3 EAP-capable-application selection . 9g35.4 Key derivation 9g35.5 Authentication Status . 9g36 EAP relate

9、d Commands . 9g36.1 EAP Authenticate . 9g36.1.1 Command description . 9g36.1.1.1 Command parameters and data . 10g36.2 Specific status conditions returned . 11g36.2.1 Status words 11g37 EAP Files 12g37.1 EFEAPKEYS(EAP derived keys) . 12g37.2 EFEAPSTATUS(EAP Authentication STATUS) . 13g37.3 EFPUId(Pe

10、rmanent User Identity) 13g37.4 EFPs(Pseudonym) . 14g37.5 EFCurID(Current Identity) 14g37.6 EFReID(Re-Authentication Identity) 15g37.7 EFRealm(Realm value of the identity) 16g3Annex A (normative): List of SFI Values . 17g3A.1 List of SFI Values at the DFEAPLevel 17g3Annex B (informative): Change hist

11、ory . 18g3History 19g3ETSI ETSI TS 102 310 V9.1.0 (2012-09)4Release 9 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and no

12、n-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/ipr.etsi.org). Purs

13、uant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present doc

14、ument. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). The contents of the present document are subject to continuing work within TC SCP and may change following formal TC SCP approval. If TC SCP modifies the contents of the present

15、 document, it will then be republished by ETSI with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 0 early working draft; 1 presented to TC SCP for information; 2 presented to TC SCP for approval; 3 or greater indicates TC

16、SCP approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. ETSI ETSI TS 102 310 V9.1.0 (2012-0

17、9)5Release 9 1 Scope The present document defines additional features that are to be provided by the UICC to support EAP authentication capabilities. The goal of these new features is to adapt the UICC to provide support of different EAP methods, ensuring interoperability between the UICC and any te

18、rminal independently of their respective manufacturers. The present document defines: The architectural framework. The additional commands required. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific r

19、eferences, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version of that document in the same Rele

20、ase as the present document. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term va

21、lidity. 2.1 Normative references The following referenced documents are necessary for the application of the present document. 1 IETF RFC 3748: “Extensible Authentication Protocol (EAP)“. NOTE: See at http:/www.ietf.org/rfc/rfc3748.txt. 2 ETSI TS 102 221: “Smart cards; UICC-Terminal interface; Physi

22、cal and logical characteristics“. 3 IETF RFC 2716: “PPP EAP TLS Authentication Protocol“. NOTE: See at http:/www.ietf.org/rfc/rfc2716.txt. 4 IETF RFC 4282: “The Network Access Identifier“. NOTE: See at http:/www.ietf.org/rfc/rfc4282.txt. 5 IETF RFC 2661: “Layer Two Tunneling Protocol L2TP“. NOTE: Se

23、e at http:/www.ietf.org/rfc/rfc2661.txt. 6 IETF RFC 1661: “The Point-to-Point Protocol (PPP)“. NOTE: See at http:/www.ietf.org/rfc/rfc1661.txt. 7 IEEE Std 802.1X-2004: “IEEE Standard for Local and metropolitan area networks Port-Based Network Access Control“. 8 IEEE Std 802.11-2007: “Telecommunicati

24、ons and information exchange between systems - Local and Metropolitan Area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications“. ETSI ETSI TS 102 310 V9.1.0 (2012-09)6Release 9 2.2 Informative references The following reference

25、d documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. Not applicable. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: authentica

26、tor: end of the EAP link initiating EAP authentication peer or supplicant: end of the EAP Link that responds to the authenticator 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AKA Authentication and Key Agreement DF Dedicated File DO Data Object EAP E

27、xtensible Authentication Protocol EF Elementary FileL2TP Layer two Tunnelling Protocol LAN Local Area Network MSK Master Session Key NAI Network Access Identifier PPP Point-to-Point Protocol TLS Transport Layer Security UTF UCS Transformation FormatWEP Wired Equivalent Privacy 4 Introduction The Ext

28、ensible Authentication Protocol is a general authentication framework, which supports multiple authentication methods. EAP typically may run directly over data link layers such as PPP (see RFC 1661 6) or IEEE Std 802.1X-2004 7 and IEEE Std 802.11-1999 8. As described in RFC 3748 1, EAP implementatio

29、ns consist of three main components: A lower layer that is responsible for transmitting and receiving EAP frames between the peer and the authenticator. EAP has been run over a variety of lower layers (including PPP, IEEE 802 LANs, IEEE 802.11 WLANs, and L2TP (see RFC 2661 5). An EAP layer that rece

30、ives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from EAP methods. EAP methods that implement the authentication algorithms and receive/transmit EAP messages via the EAP layer. ETSI ETSI TS 102 310 V9

31、.1.0 (2012-09)7Release 9 The UICC offers suitable possibilities for the implementation of some of these EAP methods in the peer side, since it provides the required protection of credentials and authentication algorithms. This is even more important when the following conditions apply: The authentic

32、ation methods require the usage of credentials that are stored in the UICC. For security reasons, these credentials are not to be revealed in clear in an unprotected peer environment (e.g. a laptop or mobile terminal). The present document defines the principles that shall be implemented in the UICC

33、 in order to enable that UICC applications may support one or more of these EAP methods. 5 Architecture 5.1 Architectural Principles The following architectural principles are applied: The authenticator is able to perform an EAP authentication process (using an specific EAP method) with a UICC appli

34、cation implementing this method. That means that the authentication is performed end-to-end between the authenticator and the UICC application. The peer is composed of several components: - The UICC EAP Framework provides information to the terminal about the existing UICC applications that provide

35、UICC EAP clients. - A UICC application provides one or more UICC EAP clients. - A UICC EAP client implements one specific EAP method. UICC AUTHENTICATOR UICC Application 1 EAP method EAP method 1 EAP Layer EAP lower layer UICC Application 2 EAP method 2 EAP method 1 TERMINAL UICC EAP Framework EAP L

36、ayer EAP lower layer SUPPLICANT Figure 5.1: EAP architecture when supplicant is split between a UICC and a terminal ETSI ETSI TS 102 310 V9.1.0 (2012-09)8Release 9 5.2 EAP clients discovery When a UICC application implements one or more EAP clients, its corresponding record in EFDIRshall contain the

37、 following EAP related Data Objects: Application EAP support types list: defining the EAP methods supported by the corresponding UICC application. Application EAP Dedicated File list: defining a list of Dedicated Files, each of them associated to one supported EAP method. Likewise, each EAP method i

38、s associated to one DF. Each of this DF are hereafter referred as DFEAP. Application EAP Label: Defining a user readable label defining the EAP clients. Table 5.1: Coding of EAP related DOs Bytes Length Description Status 1 1 Discretionary template tag = 73 M 2 1 Length of the discretionary template

39、 = X M 3 to (2+X) X Discretionary Template X Table 5.2: Coding of EAP Discretionary Template related DOs Bytes Length Description Status 1 1 EAP Application service specific data content tag =A0 M 2 1 EAP Application service specific data content length = Y M 3 to (2+Y) Y EAP Application service spe

40、cific data content M Table 5.3: Coding of EAP Application Service Specific Data Content related DOs Bytes Length Description Status 1 1 Application EAP supported types list tag = 80 M 2 1 Length of the Application EAP supported types list = A M 3 to (2+A) A Application EAP supported types list M 3+A

41、 1 Application EAP Dedicated file list tag = 81 M 4+A 1 Length of Application EAP Dedicated file list = B M (5+A) to (4+A+B) B Application EAP Dedicated File list M 5+A+B 1 Application EAP Label tag = 82 M 6+A+B 1 Length of the Application EAP Label = C M (7+A+B) to (6+A+B+C) C Application EAP Label

42、 M Coding: Application EAP supported types list: - Contain a list of supported EAP type (as defined in RFC 3748 1) each of them coded in one byte except for expanded types that are coded on 8 bytes. EXAMPLE 1: An UICC application supporting EAP-MD5 (see RFC 3748 1) and EAP-TLS (see RFC 2716 3) provi

43、des the following “Application EAP supported types list“: square4 040Dcorresponding to EAP-MD5 (Type=4) and EAP-TLS (Type=13). Application EAP Dedicated Files list: - Contain a list of file identifiers of each DFEAPassociated to a particular supported EAP type. Each of them coded in two bytes. ETSI

44、ETSI TS 102 310 V9.1.0 (2012-09)9Release 9 EXAMPLE 2: Using the previous example, A DF 6D34 for EAP-MD5 and a DF 6D35 for EAP-TLS will result in the following EAP Dedicated Files list: square4 6D346D35. Application EAP label: - The application label is a DO that contains a string of bytes provided b

45、y the application provider to be shown to the user for information. 5.3 EAP-capable-application selection The terminal shall use the information in EFDIRfile if available to present the list of EAP-capable applications to the user or to any application that may request an EAP authentication. The ter

46、minal shall then select the corresponding EAP-capable-application to start an EAP authentication. Once selected, all EAP-Client state machines of the application are reset. 5.4 Key derivation It is possible for many EAP methods to derive key material after successful authentications. These keys may

47、be used for subsequent processes (e.g. for WEP encryption in IEEE Std 802.11-1999 8). Keys derived from an authentication shall be retrieved by the terminal by inspecting the file EFEAPKEYS. 5.5 Authentication Status The terminal may retrieve the authentication status of the EAP client in the select

48、ed UICC application by inspecting the mandatory file EFEAPSTATUS. 6 EAP related Commands The following clauses specify the additional commands needed to implement the EAP framework in the UICC. 6.1 EAP Authenticate 6.1.1 Command description The function is used to transfer the EAP packets from the t

49、erminal to the selected UICC EAP client (i.e. EAP client in the selected UICC application that corresponds to the given EAP type). The UICC EAP client shall provide a response EAP packet (as defined in RFC 3748 1) or a warning status word according to the authentication method being used. The UICC EAP client shall maintain the state machine of the authentication process as described for the particular EAP method used. The function is related to a particular UICC application supporting