Internet Draft P.Urien Document: draft-urien-eap-smartcard-type-02.txt ENST W.Habraken RAAK Technologies D. Flattin Oberthur Card Systems H. Ganem Axalto Expires: January 2006 EAP Smart Card Protocol (EAP-SC) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 1, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Urien & All Informational - Expires January 2006 [Page 1]
EAP Smart Card Protocol (EAP-SC) July 2005 1 Abstract The EAP Smart Card Protocol (EAP-SC) defines an EAP Method and Multiplexing model for the support of Smart Card based authentication methods. EAP-SC provides a uniform framework for interfacing with Smart Cards within the EAP [RFC3748] context. EAP- SC provides for encapsulation of other EAP methods (such as [EAP- TLS], [EAP-SIM] and [EAP-AKA]). Smart Cards are hardware security devices that are widely used in data and voice networks to authenticate users and devices, and to enforce security policies on the client platform. EAP-SC enhances the security of authentication methods by enabling the use of Smart Cards for the secure provisioning and storage of keys and credentials, and the secure execution of security sensitive functions. In addition, EAP-SC provides security requirements for the support of Smart Card based Authentication Methods that ensure a uniform level of security complementary to the underlying authentication method. Urien & All Informational - Expires January 2006 [Page 2]
EAP Smart Card Protocol (EAP-SC) July 2005 Table of Contents 1 Abstract........................................................2 2 Terminology.....................................................4 3 Motivations.....................................................4 4 Architecture....................................................5 4.1 EAP Methods and Smart Cards................................5 4.2 The EAP-SC Multiplexing Model..............................6 4.3 Smart Card Support.........................................6 5 Protocol Overview...............................................7 5.1 EAP-SC Packets.............................................7 5.2 EAP Packet Handling at the Peer Side.......................8 5.2.1 Incoming EAP Packet Handling at the Peer Side.........8 5.2.2 Outgoing EAP Packet Handling at the Peer Side.........9 5.3 EAP Packet Handling at the Authentication Server Side......9 5.3.1 Incoming EAP Packet Handling at the Authentication Server Side.................................................9 5.3.2 Outgoing EAP Packet Handling at the Authentication Server Side.................................................9 6 IANA considerations.............................................9 7 Security Considerations.........................................9 7.1 Threat Model...............................................9 7.2 Smart Card Security Capabilities and Requirements.........10 7.2.1 Smart Card Technology................................10 7.2.2 Tamper Resistant Storage and Execution...............10 7.2.3 Multi Factor Authentication..........................10 7.2.4 Random Number Generation.............................11 7.2.5 Cryptographic Capabilities...........................11 7.2.6 Secure Provisioning..................................11 7.2.7 Certification........................................11 7.3 Smart Cards and EAP Security Claims.......................11 7.3.1 Mutual Authentication................................12 7.3.2 Confidentiality......................................12 7.3.3 Key Derivation.......................................12 7.3.4 Man-in-the-Middle Attacks............................12 7.3.5 Dictionary Attacks...................................12 7.3.6 Cryptographic Binding................................12 7.3.7 Channel Binding......................................12 7.3.8 Protection Against Rogue Networks....................13 7.3.9 Authentication Method Security.......................13 8 Security Claims................................................13 9 References.....................................................13 10 Author's Addresses..........................................14 11 Intellectual Property Statement.............................15 12 Disclaimer of Validity......................................15 13 Copyright Statement.........................................15 14 Acknowledgment..............................................15 Urien & All Informational - Expires January 2006 [Page 3]
EAP Smart Card Protocol (EAP-SC) July 2005 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. EAP Smart Card A Smart Card that supports an EAP authentication method on the smart card, such as a smart card conforming to [SC-EAP] or [UICC-EAP]. Smart Card EAP packet [SC EAP packet] An RFC3748 compliant EAP method packet to be managed by an EAP Smart Card. EAP-SC Authentication Method An Authentication Method implemented on a Smart Card within the framework of EAP-SC, typically an EAP Authentication Method such as EAP-TLS. 3 Motivations Smart Cards are generally considered as the most secure computing platforms. As an illustration NIST [NIST-PIV] recently issued a draft about the Personal Identity Verification (PIV) integrated circuit card. Smart Cards establish a security association between cardholder and embedded application by means of authentication algorithms. The verification of a biometric reading acquired from the individual against a biometric template stored on the card is an example of such an authentication protocol. Smart cards can also be used for a secure implementation of EAP methods or their critical sub parts (Private Keys,). One card MAY holds implementations of several such methods corresponding to distinct EAP types. On the other hand, distinct implementations of the same EAP protocol, resorting or not to the use of a smart card, MAY coexist on the same computer. A mechanism is needed to select a particular implementation. The main benefit of this draft is to define a unique "Umbrella EAP- Type" to be used for all implementations of EAP protocols involving a smart card. This leads also to the definition of a multiplexing Model enabling the selection and execution of specific EAP protocols implemented within a single smart card. Smartcards are standardized by multiple international committee, like [ISO 7816] or [GSM 11.11] and several works are in progress in Urien & All Informational - Expires January 2006 [Page 4]
EAP Smart Card Protocol (EAP-SC) July 2005 order to introduce components [SC-EAP], [WLAN-SIM] dedicated to [IEEE 802.1x] supplicants. As we mentioned it before, smartcard is linked to its bearer by means of multiple mechanisms (PIN, biometric protocols); by nature itÆs used for humanÆs authentication, that MAY conflict with identical EAP methods (EAP-TLS, ...) dealing with system (computer) authentication. We believe that there is a need for defining an unique type for smartcards that doesnÆt conflict with any other method implementations. As an illustration smartcard authentication mechanisms (PIN, biometric...) could by managed as proposed in [WLAN-SC]. 4 Architecture +-+-+-+-+-+-+-+ | Smart Cards | +-+-+-+-+-+-+-+ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP method | EAP method| | EAP method | EAP method| |Type = EAP-SC| Type = Y | |Type = EAP-SC| Type = Y | | | | | | | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer Layer | | EAP ! Auth. Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Layer | | EAP ! Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! Layer | | Lower ! Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authentication Server +------------>---------------+ Figure 1: The Smart Card in the EAP Multiplexing Model 4.1 EAP Methods and Smart Cards According to [RFC3748], EAP methods implement the authentication algorithms, handle fragmentation and receive and transmit EAP messages via the EAP Peer and Authentication Server layers. Urien & All Informational - Expires January 2006 [Page 5]
EAP Smart Card Protocol (EAP-SC) July 2005 When an EAP Method uses a Smart Card, a Smart Card Handler is required to manage communication between the EAP Peer Layer and the Smart Card, and to handle any required user interface and card management functions. Within the EAP multiplexing model, the overall EAP Method functionality is split between the Smart Card Handler and the Smart Card functions or applications. 4.2 The EAP-SC Multiplexing Model The EAP-SC Multiplexing model addresses the fact that Smart Cards can be removed and multiple Smart Cards can be used with a peer. In addition, many types of Smart Card types may be supported, and each Smart Card type may support one or multiple authentication methods and credentials. For this reason, EAP-SC must query the Smart Card and determine the type of card and application before initiating the EAP transaction. The EAP-SC model consists of three layers. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SC Handling method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-TLS | EAP-SIM | Other | | Smart Card | Smart Card | Smart Card | | Handler | Handler | Handler | +-+-+-+-!-+-+-+-+-+-+-+-!-+-+-+-!-+-+-+-!-+-+-+-! ! ! ! Smart Card ! ! ! Packets +-+-!-+-+-+-!-+-+-+-!-+-+-+-!-+-+-+-!-+-+-+-!-+-+ | Smart Card A | Smart Card B | Smart Card C | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EAP-SC Multiplexing Model The EAP-SC handling layer receives and sends EAP packets, selects a Smart Card handler, and passes packets to the Smart Card handler. The EAP Smart Card Handler layer handles the interface to the smart card, as well as any EAP Method specific functions that are not handled in the smart card. The Smart Card executes security sensitive Authentication Method functions in conjunction with the EAP Smart Card Handler. 4.3 Smart Card Support The EAP-SC method MUST be compatible with [SC-EAP] and [UICC-EAP] type Smart Cards that implement [EAP-TLS]. The EAP-SC method MAY Urien & All Informational - Expires January 2006 [Page 6]
EAP Smart Card Protocol (EAP-SC) July 2005 support smart cards supporting [EAP-SIM], [WLAN-SIM], [EAP-AKA], [EAP-PEAP], [EAP-TTLS]. EAP-SC MUST NOT support any Smart Card based EAP Method that does not meet the security requirements in section 7. 5 Protocol Overview 5.1 EAP-SC Packets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = EAP-SC | EAP-SC Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of EAP-SC packet A packet is sent to the EAP-SC Handler when its Type [RFC3748] is equal to the EAP-SC value. The EAP-SC payload is the same format as the Expanded Type described in section 5.7 of [RFC 3748]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: EAP-SC Payload packet format - Vendor-Id, three bytes set to zero, Reserved for Future Use - Vendor-Type, four bytes. The first three significant bytes are null, the least significant byte (Vendor-Type[7,0]) represents the EAP-Type to be processed by the Smart Card. - Vendor-Data, represents the EAP method packet (without the Code, Identifier and Length fields) to be processed by the EAP Smart Card [SC-EAP] or [UICC-EAP]. The complete EAP-SC packet structure with its transported EAP method packet or Smart Card EAP packet is as follow. Urien & All Informational - Expires January 2006 [Page 7]
EAP Smart Card Protocol (EAP-SC) July 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier |Length=SC EAP packet Length + 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = EAP-SC | Vendor-Id = zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = SC EAP packet Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Data = | SC EAP packet | SC EAP packet Payload | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: EAP-SC EAP Packet encoding - The Code field MUST be identical to the transported Smart Card EAP packet Code. - The Identifier MUST be identical to the transported Smart Card EAP packed Identifier. - The Length field MUST be equal to the transported Smart Card EAP packet Length plus 8. - The Type field MUST be set to EAP-SC Type. - The Vendor-Id field MUST be set to zero. - The Vendor-Type field MUST be set to zero for the 3 most significant bytes and set to the transported Smart Card EAP packet Type for the last significant byte. - The Vendor-Data field MUST contains the transported Smart Card EAP packed Type and Payload. 5.2 EAP Packet Handling at the Peer Side 5.2.1 Incoming EAP Packet Handling at the Peer Side The EAP-SC layer rebuilds the transported EAP method packets to be processed by the Smart Card. The EAP-SC layer modifies the incoming EAP-SC packets by removing the EAP-SC Type, the Vendor-Id and the Vendor-Type fields and by subtracting the Length field by 8. Then the EAP message is forwarded to the appropriate Smart Card Handler, such as [WLAN-SC]. Urien & All Informational - Expires January 2006 [Page 8]
EAP Smart Card Protocol (EAP-SC) July 2005 5.2.2 Outgoing EAP Packet Handling at the Peer Side The EAP-SC layer builds the EAP-SC EAP packet from the Smart Card EAP packet to transport. The EAP-SC layer modifies the Smart Card EAP packets by inserting the EAP-SC Type, the Vendor-Id, the Vendor-Type fields and by setting Vendor-Type field with the transported Smart Card EAP Type and adding the Length value with 8. Then, packets are sent to the Authentication Server. 5.3 EAP Packet Handling at the Authentication Server Side 5.3.1 Incoming EAP Packet Handling at the Authentication Server Side The EAP-SC layer modifies the Incoming EAP-SC packets by removing the EAP-SC Type, the Vendor-Id and the Vendor-Type fields and by subtracting the Length field by 8. Then, the EAP packets MUST be processed by the Authentication Server. 5.3.2 Outgoing EAP Packet Handling at the Authentication Server Side The EAP-SC layer modifies the Outgoing EAP-SC packets by inserting the EAP-SC Type, the Vendor-Id, the Vendor-Type fields and by setting Vendor-Type field with the transported EAP Type and adding the Length value with 8. Then the authentication server MUST send the packets to the Peer. 6 IANA considerations EAP-SC type is set to xx 7 Security Considerations 7.1 Threat Model An attacker may attack a typical EAP transaction by compromising the peer. For example, an attacker may gain access to genuine keys and credentials and share these with an unauthorized user. Or an attacker may gain access and modify cryptographic processes as they are executed on the peer platform. Security policies must be established to secure against such peer attacks. The EAP-SC type makes it possible to enforce security policies by using smartcards. This includes scenarios which require strong authentication of the end user, where the end user platform is vulnerable to direct attack, where the end user may be considered an enabling agent in the attack, or where the enforcement of end user policies is subject to legal requirements. Examples of such scenarios are: Urien & All Informational - Expires January 2006 [Page 9]
EAP Smart Card Protocol (EAP-SC) July 2005 - A service provider wanting to grant subscribers access to network based value added services - A hospital subject to medical privacy regulations that needs to assure that only authorized personnel can access patient information. - A government organization which needs to secure classified information 7.2 Smart Card Security Capabilities and Requirements Smart cards are a highly effective means of enforcing security policies. Smart cards are typically carried by one party (the end user, such as an employee or customer) but are controlled by another party (the issuer, such as an enterprise or service provider). Applications running on the Smart Card are controlled by the issuer, and serve to protect the interests of the issuer. The following sub sections describe Smart Card security capabilities and requirements for EAP-SC Authentication Methods relating to those capabilities: 7.2.1 Smart Card Technology The Smart Card consists of a microprocessor and non-volatile memory chipset enclosed in a physically tamper resistant module. This module is then embedded in a plastic card, or the module may be integrated into an alternative form factor, such as a USB device. 7.2.2 Tamper Resistant Storage and Execution Smart cards provide protective measures against physical and logical attacks against the processor and non-volatile memory. This enables the secure storage of end user cryptographic keys and user credentials, and secures execution of security sensitive operations such as encryption and digital signatures. The EAP-SC Authentication Method MUST store all secret cryptographic keys on the smart card in non-volatile memory. The EAP-SC Authentication Method MUST execute in the smart card all cryptographic functions that use stored secret cryptographic keys. The EAP-SC Authentication Method MUST NOT export any secret cryptographic keys from the smart card. 7.2.3 Multi Factor Authentication Smart cards generally require a Smart Card handler to authenticate to the Smart Card in order to access data or application functionality. This makes it possible to enforce multi factor user authentication by combining something the user has (the smart card) with something the user knows (such as PIN) or is (Biometric authentication). Urien & All Informational - Expires January 2006 [Page 10]
EAP Smart Card Protocol (EAP-SC) July 2005 The EAP Authentication Method MUST enforce the use of the user PIN or Biometric before user credentials may be accessed or used. 7.2.4 Random Number Generation Smart Cards generally contain a hardware based true random number generator independent of external or internal clocks and immune to outside interferences. The quality of the hardware generator is further enhanced by logical processing to ensure excellent statistical properties; and these properties are checked regularly on-board. The EAP Authentication Method MUST use the Smart Card Random Number Generator anywhere Random Numbers are required. 7.2.5 Cryptographic Capabilities Smart cards provide certified, built-in implementation and optimised execution of common cryptographic algorithms such as AES, DES, RSA, and ECC... The EAP Authentication Method MUST use the built-in Smart Card cryptographic capabilities for the execution of any cryptographic functionality. 7.2.6 Secure Provisioning Smart cards provide a secure method of provisioning credentials, applications and trusted network information from the issuer or service provider to the end user, and managing this information after the card has been issued. Smart cards support automated personalization (including card initialization, loading of card data and printing) enabling issuance in very large numbers. The EAP-SC Authentication method MUST implement support for pre- issuance personalization, as for example by supporting [GLOBAL PLATFORM] or similar functionality. The EAP-SC Authentication method SHOULD implement support for post-issuance card and application management. 7.2.7 Certification The processes for designing and manufacturing smart cards are subject to rigorous security controls. This makes possible the certification of Smart Card functionality and applications by standardization organizations. The EAP-SC Authentication method MUST be implemented on a Smart Card platform that has been evaluated for security by a standards organization program such as [FIPS] or [COMMON CRITERIA]. 7.3 Smart Cards and EAP Security Claims EAP-SC enhances the security of Authentication Methods by enabling the enforcement of security policies on the End User platform. The Urien & All Informational - Expires January 2006 [Page 11]
EAP Smart Card Protocol (EAP-SC) July 2005 overall security of EAP-SC is dependent on the security of the Authentication Method implemented on the Smart Card. The following section discusses certain EAP Security Claims and how they are enhanced by Smart Card security features. 7.3.1 Mutual Authentication Mutual authentication processes are generally based upon the use of random numbers. Smart Cards enhance the security of these processes by providing true random number generation. 7.3.2 Confidentiality Smart Cards improve the robustness of EAP messages encryption, by providing tamper resistant storage for the encryption keys and secure execution of the encryption algorithms. 7.3.3 Key Derivation Smart Cards improve the confidentiality of the key derivation process by providing tamper resistant storage for the master keys and secure execution of the key derivation algorithms. 7.3.4 Man-in-the-Middle Attacks Smart Cards improve security against Trojan Horse attacks by providing a logically tamper resistant environment for the full implementation of EAP methods and secure execution of the encryption algorithms. 7.3.5 Dictionary Attacks Smart Cards access is commonly protected via pin codes with a limited number of retries; permanent blocking of the device is enforced when the number of retries is exceeded. This mechanism provides enhanced protection against dictionary attacks aiming at discovering passwords. 7.3.6 Cryptographic Binding Smart Cards provides tamper resistant storage for cryptographic keys and secure execution of the tunnel creation algorithms thus enhancing the cryptographic binding process. 7.3.7 Channel Binding Smart Cards can be used as a secure out of band distribution method for channel parameters and therefore enhance the channel binding process. Urien & All Informational - Expires January 2006 [Page 12]
EAP Smart Card Protocol (EAP-SC) July 2005 7.3.8 Protection Against Rogue Networks Smart Cards facilitate the provisioning and secure storage of information about trusted parties, such as the root certificates of trusted networks. This protects the end user against rogue networks and enables the enforcement of network roaming policies. 7.3.9 Authentication Method Security The overall security of EAP-SC is dependent on the encapsulated EAP- SC Authentication Method. Weaknesses in the underlying method, such as weaknesses in integrity protection, replay protection or key strength, are detrimental to the overall security. 8 Security Claims Integrity Protection: no Replay Protection: no Confidentiality: yes (section 7.3.2) Key Derivation: yes (section 7.3.3) Key Strength: no Dictionary Attacks: yes (section 7.3.4) Fast Reconnect: no Cryptographic Binding: yes (section 7.3.6) Session Independence: no Fragmentation: no Channel Binding: yes (section 7.3.7) 9 References [RFC 3748], Extensible Authentication Protocol (EAP), B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, June 2004. [SC-EAP], draft-urien-eap-smartcard-08.txt, P.Urien, A.J. Farrugia, M.Groot, G.Pujolle, J. Abellan, February 2005 [UICC-EAP] European Telecommunications Standards Institute, ETSI TS 102.310 Extensible Authentication Protocol support in the UICC [WLAN-SIM] WLAN-SIM specification V1.0, WLAN Smart Card Consortium, October 20, 2003 [WLAN-SC] Wlan Smart Card Handler Specification, WLAN Smart Card Consortium, - in progress - [EAP-SIM] Extensible Authentication Protocol Method for GSM Subscriber Identity, IETF, April 4, 2004 [GLOBAL PLATFORM] GlobalPlatform Card Specification v2.1.1, GlobalPlatform, March 2003 Urien & All Informational - Expires January 2006 [Page 13]
EAP Smart Card Protocol (EAP-SC) July 2005 [FIPS] FIPS 140-1 and FIPS 140-2 Cryptographic Modules Validation List, National Institute of Standards [COMMON CRITERIA] Common Criteria Project [EAP-SIM-Handler] EAP-SIM Handler specification V1.1, WLAN Smart Card Consortium, August 1, 2004. [EAP-AKA] Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement, IETF, April 5, 2004 [NIST-PIV] NIST Special Publication 800-73 Draft, January 25, 2005 10 Author's Addresses Pascal Urien ENST www.enst.fr Email: Pascal.Urien@enst.fr Wouter Habraken RAAK Technologies www.raaktechnologies.com Email: whabraken@raaktechnologies.com David Flattin Oberthur Card Systems www.oberthurcs.com Email: d.flattin@oberthurcs.com Herve Ganem Axalto www.axalto.com Email: hganem@axalto.com Urien & All Informational - Expires January 2006 [Page 14]
EAP Smart Card Protocol (EAP-SC) July 2005 11 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org 12 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 14 Acknowledgment Thanks to Bertrand Ducastel, president of the WLAN consortium (www.wlansmartcard.org), for his valuable comments. Urien & All Informational - Expires January 2006 [Page 15]