1 Pascal URIEN, IETF 63th Paris, France, 2nd August 2005 “draft-urien-eap-smartcard-type-02.txt” EAP Smart Card Protocol (EAP-SC)

2 Pascal URIEN, IETF 63th Paris, France, 2nd August 2005 Why do we need a type for smartcard ? Why not?. Existing types relative to tokens or smartcards (according to 6 Generic Token Card (RFC3748), 14 Defender Token, 15 RSA Security SecurID EAP, 18 Nokia IP smart card authentication, 28 CRYPTOCard, 30 DynamID, 32 SecurID EAP, … Prerequisite Method may be implemented by other means than smartcards. True for all methods Method is clearly defined and standardized. Examples: EAP-TLS, EAP-SIM, EAP-AKA Smartcard interface, associated with a particular method is clearly defined and standardized. Example: draft-urien-eap-smartcard-08.txt Integration of EAP methods in smartcards reduce Trojan Horse threats EAP-TLS: trusted certificate chain EAP-SIM; cancel the risk of authentication-triplet theft EAP-AKA: embedded identity management Benefits Standardization of smartcards use with EAP platform. Avoid conflicts when the host supports multiple instances of a given type (EAP- TLS, …). Smartcard may be removed from the supplicant host, it’s clearly linked to terminal user. Proposed mechanism EAP in EAP encapsulation

3 Pascal URIEN, IETF 63th Paris, France, 2nd August 2005 Expert review summary (Glen Zorn ) 1. Does the method document its security properties in sufficient manner, as required by Section 7.2 of RFC 3748? [gwz] Yes and no: although all of the required sections are present, the method in fact appears to possess no security properties of its own; those security properties that are claimed (see below) are possessed by smart cards, not by the EAP-SC method. [pu] Agree. The goal of the draft is to define an unique type for all smartcards 1a. Mechanism. Is the mechanism explained? [gwz] Yes and no: this document does not actually define an authentication mechanism, nor does it define EAP support for any particular authentication mechanism. What it does define is a method for demultiplexing EAP type packets on the peer (this does not appear to be necessary on the authenticator side). This demultiplexing method is explained adequately. [pu] Agree. Multiplexing method is obviously needed on the server side, it will be added in the next version 1c. Justifications for the claims? Is an explanation or reference provided to each of the claims? [gwz] Yes and no: the references for those claims that are made (for Confidentiality, Key Derivation, Dictionary Attacks, Cryptographic Binding and Channel Binding) are internal to the document itself and refer to (claimed) properties of smart cards in general, rather than EAP-SC per se. [pu] EAP-SC is dedicated to smartcards. 1f. Indication of vulnerabilities. Are the known vulnerabilities documented? [gwz] Much space is dedicated in this document to the praise of the security capabilities claimed by smart cards; without discussing the validity of those claims, it appears that EAP-SC itself provides no assurance or even evidence of the actual presence or usage of a smart card in the peer system. For enable, I can find no protection against a Trojan horse, for example, having access to appropriate credentials claiming to be an EAP-SC client in the absence of a smart card. [pu] Trojan horse is a threat for all methods. EAP smartcards make these attacks more difficult (example embedded EAP-TLS) Furthermore smartcard can’t be cloned and reduces the eavesdropping risk. A section could be added to the document in order to fix the smartcard handler behavior in the absence of smartcard. 4a. Does the method comply with EAP-based IANA requirements defined in Section 6 of RFC 3748? That is, if it requests the allocation of new numbers in the EAP namespace [not applicable if the numbers have already been allocated], is the type of the document and process appropriate for the desired action? [gwz] No. [pu] Disagree. We need an unique type for smartcards in order to avoid conflicts with method running either on hosts and in smartcards