idnits 2.17.1 draft-urien-eap-smartcard-type-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 716. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 738), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([EAP-AKA], [RFC3748], [EAP-TLS], [EAP-SIM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3748' is mentioned on line 307, but not defined == Missing Reference: 'EAP-TLS' is mentioned on line 287, but not defined == Missing Reference: 'ISO 7816' is mentioned on line 167, but not defined == Missing Reference: 'EAP-PEAP' is mentioned on line 289, but not defined == Missing Reference: 'EAP-TTLS' is mentioned on line 289, but not defined -- Looks like a reference, but probably isn't: '7' on line 329 -- Looks like a reference, but probably isn't: '0' on line 329 == Unused Reference: 'GLOBAL PLATFORM' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'EAP-SIM-Handler' is defined on line 672, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-urien-eap-smartcard-09 ** Downref: Normative reference to an Informational draft: draft-urien-eap-smartcard (ref. 'SC-EAP') -- Possible downref: Non-RFC (?) normative reference: ref. 'UICC-EAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'WLAN-SIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'WLAN-SC' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAP-SIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'GLOBAL PLATFORM' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'COMMON CRITERIA' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAP-SIM-Handler' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAP-AKA' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-PIV' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft P.Urien 3 Document: draft-urien-eap-smartcard-type-03.txt ENST 4 W.Habraken 5 RAAK Technologies 6 D. Flattin 7 Oberthur Card Systems 8 H. Ganem 9 Axalto 10 Expires: April 2006 12 EAP Smart Card Protocol (EAP-SC) 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April, 2006. 39 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 42 EAP Smart Card Protocol (EAP-SC) October 2005 44 1 Abstract 46 The EAP Smart Card Protocol (EAP-SC) defines an EAP Method and 47 Multiplexing model for the support of Smart Card based 48 authentication methods. EAP-SC provides a uniform framework for 49 interfacing with Smart Cards within the EAP [RFC3748] context. EAP- 50 SC provides for encapsulation of other EAP methods (such as [EAP- 51 TLS], [EAP-SIM] and [EAP-AKA]). 53 Smart Cards are hardware security devices that are widely used in 54 data and voice networks to authenticate users and devices, and to 55 enforce security policies on the client platform. 57 EAP-SC enhances the security of authentication methods by enabling 58 the use of Smart Cards for the secure provisioning and storage of 59 keys and credentials, and the secure execution of security sensitive 60 functions. In addition, EAP-SC provides security requirements for 61 the support of Smart Card based Authentication Methods that ensure a 62 uniform level of security complementary to the underlying 63 authentication method. 65 EAP Smart Card Protocol (EAP-SC) October 2005 67 Table of Contents 69 1 Abstract........................................................2 70 2 Terminology.....................................................4 71 3 Motivations.....................................................4 72 4 Architecture....................................................5 73 4.1 EAP Methods and Smart Cards................................5 74 4.2 The EAP-SC Supplicant Multiplexing Model...................6 75 4.3 The EAP-SC Authenticator multiplexing model................6 76 4.4 Smart Card Support.........................................7 77 5 Protocol Overview...............................................7 78 5.1 EAP-SC Packets.............................................7 79 5.2 EAP Packet Handling at the Peer Side.......................8 80 5.2.1 Incoming EAP Packet Handling at the Peer Side.........9 81 5.2.2 Outgoing EAP Packet Handling at the Peer Side.........9 82 5.3 EAP Packet Handling at the Authentication Server Side......9 83 5.3.1 Incoming EAP Packet Handling at the Authentication 84 Server Side.................................................9 85 5.3.2 Outgoing EAP Packet Handling at the Authentication 86 Server Side.................................................9 87 6 IANA considerations.............................................9 88 7 Security Considerations.........................................9 89 7.1 Threat Model..............................................10 90 7.2 Smart Card Security Capabilities and Requirements.........10 91 7.2.1 Smart Card Technology................................11 92 7.2.2 Tamper Resistant Storage and Execution...............11 93 7.2.3 Multi Factor Authentication..........................11 94 7.2.4 Random Number Generation.............................11 95 7.2.5 Cryptographic Capabilities...........................11 96 7.2.6 Secure Provisioning..................................12 97 7.2.7 Certification........................................12 98 7.3 Smart Cards and EAP Security Claims.......................12 99 7.3.1 Mutual Authentication................................12 100 7.3.2 Confidentiality......................................12 101 7.3.3 Key Derivation.......................................12 102 7.3.4 Man-in-the-Middle Attacks............................13 103 7.3.5 Dictionary Attacks...................................13 104 7.3.6 Cryptographic Binding................................13 105 7.3.7 Channel Binding......................................13 106 7.3.8 Protection Against Rogue Networks....................13 107 7.3.9 Authentication Method Security.......................13 108 8 Security Claims................................................13 109 9 References.....................................................14 110 10 Author's Addresses..........................................14 111 11 Intellectual Property Statement.............................16 112 12 Disclaimer of Validity......................................16 113 13 Copyright Statement.........................................16 114 14 Acknowledgment..............................................16 115 EAP Smart Card Protocol (EAP-SC) October 2005 117 2 Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC-2119. 123 EAP Smart Card 124 A Smart Card that supports an EAP authentication method on the smart 125 card, such as a smart card conforming to [SC-EAP] or [UICC-EAP]. 127 Smart Card EAP packet [SC EAP packet] 128 An RFC3748 compliant EAP method packet to be managed by an EAP Smart 129 Card. 131 EAP-SC Authentication Method 132 An Authentication Method implemented on a Smart Card within the 133 framework of EAP-SC, typically an EAP Authentication Method such as 134 EAP-TLS. 136 3 Motivations 138 Smart Cards are generally considered as the most secure computing 139 platforms. 141 As an illustration NIST [NIST-PIV] recently issued a draft about the 142 Personal Identity Verification (PIV) integrated circuit card. 144 Smart Cards establish a security association between cardholder and 145 embedded application by means of authentication algorithms. The 146 verification of a biometric reading acquired from the individual 147 against a biometric template stored on the card is an example of 148 such an authentication protocol. 150 Smart cards can also be used for a secure implementation of EAP 151 methods or their critical sub parts (Private Keys,). One card MAY 152 holds implementations of several such methods corresponding to 153 distinct EAP types. 155 On the other hand, distinct implementations of the same EAP 156 protocol, resorting or not to the use of a smart card, MAY coexist 157 on the same computer. A mechanism is needed to select a particular 158 implementation. 160 The main benefit of this draft is to define a unique "Umbrella EAP- 161 Type" to be used for all implementations of EAP protocols involving 162 a smart card. This leads also to the definition of a multiplexing 163 Model enabling the selection and execution of specific EAP protocols 164 implemented within a single smart card. 166 Smartcards are standardized by multiple international committee, 167 like [ISO 7816] or [GSM 11.11] and several works are in progress in 168 EAP Smart Card Protocol (EAP-SC) October 2005 170 order to introduce components [SC-EAP], [WLAN-SIM] dedicated to 171 [IEEE 802.1x] supplicants. 173 As we mentioned it before, smartcard is linked to its bearer by 174 means of multiple mechanisms (PIN, biometric protocols); by nature 175 it�s used for human�s authentication, that MAY conflict with 176 identical EAP methods (EAP-TLS, ...) dealing with system (computer) 177 authentication. 179 We believe that there is a need for defining an unique type for 180 smartcards that doesn�t conflict with any other method 181 implementations. As an illustration smartcard authentication 182 mechanisms (PIN, biometric...) could by managed as proposed in 183 [WLAN-SC]. 185 4 Architecture 187 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 188 | Smart Card | | EAP method | 189 |...Type=X....| | Type=X | 190 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 191 ! ! 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | EAP method | EAP method| | EAP method | EAP method| 194 |Type = EAP-SC| Type = Y | |Type = EAP-SC| Type = Y | 195 | V | | | ^ | | 196 +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ 197 | ! | | ! | 198 | EAP ! Peer Layer | | EAP ! Auth. Layer | 199 | ! | | ! | 200 +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ 201 | ! | | ! | 202 | EAP ! Layer | | EAP ! Layer | 203 | ! | | ! | 204 +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ 205 | ! | | ! | 206 | Lower ! Layer | | Lower ! Layer | 207 | ! | | ! | 208 +-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+ 209 ! ! 210 ! Peer ! Authentication Server 211 +------------>---------------+ 213 Figure 1: The Smart Card in the EAP Multiplexing Model 215 4.1 EAP Methods and Smart Cards 217 According to [RFC3748], EAP methods implement the authentication 218 algorithms, handle fragmentation and receive and transmit EAP 219 messages via the EAP Peer and Authentication Server layers. 221 EAP Smart Card Protocol (EAP-SC) October 2005 223 When an EAP Method uses a Smart Card, a Smart Card Handler is 224 required to manage communication between the EAP Peer Layer and the 225 Smart Card, and to handle any required user interface and card 226 management functions. 228 Within the EAP multiplexing model, the overall EAP Method 229 functionality is split between the Smart Card Handler and the Smart 230 Card functions or applications. 232 4.2 The EAP-SC Supplicant Multiplexing Model 234 The EAP-SC Multiplexing model addresses the fact that Smart Cards 235 can be removed and multiple Smart Cards can be used with a peer. In 236 addition, many types of Smart Card types may be supported, and each 237 Smart Card type may support one or multiple authentication methods 238 and credentials. For this reason, EAP-SC must query the Smart Card 239 and determine the type of card and application before initiating the 240 EAP transaction. 242 The EAP-SC model consists of three layers. 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | EAP-SC Handling method | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | EAP-TLS | EAP-SIM | Other | 248 | Smart Card | Smart Card | Smart Card | 249 | Handler | Handler | Handler | 250 +-+-+-+-!-+-+-+-+-+-+-+-!-+-+-+-!-+-+-+-!-+-+-+-! 251 ! ! ! Smart Card 252 ! ! ! Packets 253 +-+-!-+-+-+-!-+-+-+-!-+-+-+-!-+-+-+-!-+-+-+-!-+-+ 254 | Smart Card A | Smart Card B | Smart Card C | 255 | | | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 2: EAP-SC Multiplexing Model 260 The EAP-SC handling layer receives and sends EAP packets, selects a 261 Smart Card handler, and passes packets to the Smart Card handler. 263 The EAP Smart Card Handler layer handles the interface to the smart 264 card, as well as any EAP Method specific functions that are not 265 handled in the smart card. 267 The Smart Card executes security sensitive Authentication Method 268 functions in conjunction with the EAP Smart Card Handler. 270 4.3 The EAP-SC Authenticator multiplexing model 272 On the authenticator side the EAP-SC method acts as a multiplexing 273 layer that delivers the following services 274 EAP Smart Card Protocol (EAP-SC) October 2005 276 - EAP requests issued by a particular method, whose type is X (see 277 figure 1), are encapsulated in EAP-SC packets, according to rules 278 detailed in section 5.1 279 - EAP responses, whose type is EAP-SC (see figure 1) are converted 280 to standard EAP messages whose type is X, according to rules defined 281 in section 5.1. Converted messages are then directed toward the 282 appropriate method. 284 4.4 Smart Card Support 286 The EAP-SC method MUST be compatible with [SC-EAP] and [UICC-EAP] 287 type Smart Cards that implement [EAP-TLS]. The EAP-SC method MAY 288 support smart cards supporting [EAP-SIM], [WLAN-SIM], [EAP-AKA], 289 [EAP-PEAP], [EAP-TTLS]. 290 EAP-SC MUST NOT support any Smart Card based EAP Method that does 291 not meet the security requirements in section 7. 293 5 Protocol Overview 295 5.1 EAP-SC Packets 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Code | Identifier | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type = EAP-SC | EAP-SC Payload 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3: Format of EAP-SC packet 307 A packet is sent to the EAP-SC Handler when its Type [RFC3748] is 308 equal to the EAP-SC value. 310 The EAP-SC payload is the same format as the Expanded Type described 311 in section 5.7 of [RFC 3748]. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Vendor-Id | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Vendor-Type | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Vendor-Data 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 4: EAP-SC Payload packet format 325 - Vendor-Id, three bytes set to zero, Reserved for Future Use 326 EAP Smart Card Protocol (EAP-SC) October 2005 328 - Vendor-Type, four bytes. The first three significant bytes are 329 null, the least significant byte (Vendor-Type[7,0]) represents the 330 EAP-Type to be processed by the Smart Card. 332 - Vendor-Data, represents the EAP method packet (without the Code, 333 Identifier and Length fields) to be processed by the EAP Smart Card 334 [SC-EAP] or [UICC-EAP]. 336 The complete EAP-SC packet structure with its transported EAP method 337 packet or Smart Card EAP packet is as follow. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Code | Identifier |Length=SC EAP packet Length + 8| 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type = EAP-SC | Vendor-Id = zero | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Vendor-Type = SC EAP packet Type | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Vendor-Data = 349 | SC EAP packet | SC EAP packet Payload 350 | Type | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 5: EAP-SC EAP Packet encoding 355 - The Code field MUST be identical to the transported Smart Card EAP 356 packet Code. 358 - The Identifier MUST be identical to the transported Smart Card EAP 359 packed Identifier. 361 - The Length field MUST be equal to the transported Smart Card EAP 362 packet Length plus 8. 364 - The Type field MUST be set to EAP-SC Type. 366 - The Vendor-Id field MUST be set to zero. 368 - The Vendor-Type field MUST be set to zero for the 3 most 369 significant bytes and set to the transported Smart Card EAP packet 370 Type for the last significant byte. 372 - The Vendor-Data field MUST contains the transported Smart Card EAP 373 packed Type and Payload. 375 5.2 EAP Packet Handling at the Peer Side 376 EAP Smart Card Protocol (EAP-SC) October 2005 378 5.2.1 Incoming EAP Packet Handling at the Peer Side 380 The EAP-SC layer rebuilds the transported EAP method packets to be 381 processed by the Smart Card. 383 The EAP-SC layer modifies the incoming EAP-SC packets by removing 384 the EAP-SC Type, the Vendor-Id and the Vendor-Type fields and by 385 subtracting the Length field by 8. Then the EAP message is forwarded 386 to the appropriate Smart Card Handler, such as [WLAN-SC]. 388 5.2.2 Outgoing EAP Packet Handling at the Peer Side 390 The EAP-SC layer builds the EAP-SC EAP packet from the Smart Card 391 EAP packet to transport. 393 The EAP-SC layer modifies the Smart Card EAP packets by inserting 394 the EAP-SC Type, the Vendor-Id, the Vendor-Type fields and by 395 setting Vendor-Type field with the transported Smart Card EAP Type 396 and adding the Length value with 8. Then, packets are sent to the 397 Authentication Server. 399 5.3 EAP Packet Handling at the Authentication Server Side 401 5.3.1 Incoming EAP Packet Handling at the Authentication Server Side 403 The EAP-SC layer modifies the Incoming EAP-SC packets by removing 404 the EAP-SC Type, the Vendor-Id and the Vendor-Type fields and by 405 subtracting the Length field by 8. Then, the EAP packets MUST be 406 processed by the Authentication Server. 408 5.3.2 Outgoing EAP Packet Handling at the Authentication Server Side 410 The EAP-SC layer modifies the Outgoing EAP-SC packets by inserting 411 the EAP-SC Type, the Vendor-Id, the Vendor-Type fields and by 412 setting Vendor-Type field with the transported EAP Type and adding 413 the Length value with 8. Then the authentication server MUST send 414 the packets to the Peer. 416 6 IANA considerations 418 EAP-SC type is set to xx 420 7 Security Considerations 422 The EAP-SC protocol by itself doesn�t modify the security claims of 423 a particular method, because it only provides a transparent 424 encapsulation in a single type. 426 EAP Smart Card Protocol (EAP-SC) October 2005 428 But EAP-SC greatly facilitates the use of smartcards in EAP 429 sessions, and avoid conflicts with classical software 430 implementations. 432 They are two basic assumptions about smartcards, first they are very 433 difficult to clone, and second it is quite impossible to steal 434 secret embedded information, like cryptographic keys. 436 As a consequence a software clone of smartcard could not work, 437 because this should require to get secret credentials stored in the 438 tamper resistant device. 440 7.1 Threat Model 442 An attacker may attack a typical EAP transaction by compromising the 443 peer. For example, an attacker may gain access to genuine keys and 444 credentials and share these with an unauthorized user. Or an 445 attacker may gain access and modify cryptographic processes as they 446 are executed on the peer platform. 448 Security policies must be established to secure against such peer 449 attacks. The EAP-SC type makes it possible to enforce security 450 policies by using smartcards. 452 This includes scenarios which require strong authentication of the 453 end user, where the end user platform is vulnerable to direct 454 attack, where the end user may be considered an enabling agent in 455 the attack, or where the enforcement of end user policies is subject 456 to legal requirements. Examples of such scenarios are: 457 - A service provider wanting to grant subscribers access to network 458 based value added services 459 - A hospital subject to medical privacy regulations that needs to 460 assure that only authorized personnel can access patient 461 information. 462 - A government organization which needs to secure classified 463 information 465 7.2 Smart Card Security Capabilities and Requirements 467 Smart cards are a highly effective means of enforcing security 468 policies. Smart cards are typically carried by one party (the end 469 user, such as an employee or customer) but are controlled by another 470 party (the issuer, such as an enterprise or service provider). 471 Applications running on the Smart Card are controlled by the issuer, 472 and serve to protect the interests of the issuer. 474 The following sub sections describe Smart Card security capabilities 475 and requirements for EAP-SC Authentication Methods relating to those 476 capabilities: 478 EAP Smart Card Protocol (EAP-SC) October 2005 480 7.2.1 Smart Card Technology 481 The Smart Card consists of a microprocessor and non-volatile memory 482 chipset enclosed in a physically tamper resistant module. This 483 module is then embedded in a plastic card, or the module may be 484 integrated into an alternative form factor, such as a USB device. 486 7.2.2 Tamper Resistant Storage and Execution 487 Smart cards provide protective measures against physical and logical 488 attacks against the processor and non-volatile memory. This enables 489 the secure storage of end user cryptographic keys and user 490 credentials, and secures execution of security sensitive operations 491 such as encryption and digital signatures. 493 The EAP-SC Authentication Method MUST store all secret cryptographic 494 keys on the smart card in non-volatile memory. The EAP-SC 495 Authentication Method MUST execute in the smart card all 496 cryptographic functions that use stored secret cryptographic keys. 497 The EAP-SC Authentication Method MUST NOT export any secret 498 cryptographic keys from the smart card. 500 7.2.3 Multi Factor Authentication 501 Smart cards generally require a Smart Card handler to authenticate 502 to the Smart Card in order to access data or application 503 functionality. This makes it possible to enforce multi factor user 504 authentication by combining something the user has (the smart card) 505 with something the user knows (such as PIN) or is (Biometric 506 authentication). 508 The EAP Authentication Method MUST enforce the use of the user PIN 509 or Biometric before user credentials may be accessed or used. 511 7.2.4 Random Number Generation 512 Smart Cards generally contain a hardware based true random number 513 generator independent of external or internal clocks and immune to 514 outside interferences. The quality of the hardware generator is 515 further enhanced by logical processing to ensure excellent 516 statistical properties; and these properties are checked regularly 517 on-board. 519 The EAP Authentication Method MUST use the Smart Card Random Number 520 Generator anywhere Random Numbers are required. 522 7.2.5 Cryptographic Capabilities 523 Smart cards provide certified, built-in implementation and optimised 524 execution of common cryptographic algorithms such as AES, DES, RSA, 525 and ECC... 527 The EAP Authentication Method MUST use the built-in Smart Card 528 cryptographic capabilities for the execution of any cryptographic 529 functionality. 531 EAP Smart Card Protocol (EAP-SC) October 2005 533 7.2.6 Secure Provisioning 534 Smart cards provide a secure method of provisioning credentials, 535 applications and trusted network information from the issuer or 536 service provider to the end user, and managing this information 537 after the card has been issued. Smart cards support automated 538 personalization (including card initialization, loading of card data 539 and printing) enabling issuance in very large numbers. 541 The EAP-SC Authentication method MUST implement support for pre- 542 issuance personalization, as for example by supporting [GLOBAL 543 PLATFORM] or similar functionality. The EAP-SC Authentication method 544 SHOULD implement support for post-issuance card and application 545 management. 547 7.2.7 Certification 548 The processes for designing and manufacturing smart cards are 549 subject to rigorous security controls. This makes possible the 550 certification of Smart Card functionality and applications by 551 standardization organizations. 553 The EAP-SC Authentication method MUST be implemented on a Smart Card 554 platform that has been evaluated for security by a standards 555 organization program such as [FIPS] or [COMMON CRITERIA]. 557 7.3 Smart Cards and EAP Security Claims 559 EAP-SC enhances the security of Authentication Methods by enabling 560 the enforcement of security policies on the End User platform. The 561 overall security of EAP-SC is dependent on the security of the 562 Authentication Method implemented on the Smart Card. 564 The following section discusses certain EAP Security Claims and how 565 they are enhanced by Smart Card security features. 567 7.3.1 Mutual Authentication 569 Mutual authentication processes are generally based upon the use of 570 random numbers. Smart Cards enhance the security of these processes 571 by providing true random number generation. 573 7.3.2 Confidentiality 575 Smart Cards improve the robustness of EAP messages encryption, by 576 providing tamper resistant storage for the encryption keys and 577 secure execution of the encryption algorithms. 579 7.3.3 Key Derivation 581 Smart Cards improve the confidentiality of the key derivation 582 process by providing tamper resistant storage for the master keys 583 and secure execution of the key derivation algorithms. 585 EAP Smart Card Protocol (EAP-SC) October 2005 587 7.3.4 Man-in-the-Middle Attacks 589 Smart Cards improve security against Trojan Horse attacks by 590 providing a logically tamper resistant environment for the full 591 implementation of EAP methods and secure execution of the encryption 592 algorithms. 594 7.3.5 Dictionary Attacks 596 Smart Cards access is commonly protected via pin codes with a 597 limited number of retries; permanent blocking of the device is 598 enforced when the number of retries is exceeded. This mechanism 599 provides enhanced protection against dictionary attacks aiming at 600 discovering passwords. 602 7.3.6 Cryptographic Binding 604 Smart Cards provides tamper resistant storage for cryptographic keys 605 and secure execution of the tunnel creation algorithms thus 606 enhancing the cryptographic binding process. 608 7.3.7 Channel Binding 610 Smart Cards can be used as a secure out of band distribution method 611 for channel parameters and therefore enhance the channel binding 612 process. 614 7.3.8 Protection Against Rogue Networks 616 Smart Cards facilitate the provisioning and secure storage of 617 information about trusted parties, such as the root certificates of 618 trusted networks. This protects the end user against rogue networks 619 and enables the enforcement of network roaming policies. 621 7.3.9 Authentication Method Security 623 The overall security of EAP-SC is dependent on the encapsulated EAP- 624 SC Authentication Method. Weaknesses in the underlying method, such 625 as weaknesses in integrity protection, replay protection or key 626 strength, are detrimental to the overall security. 628 8 Security Claims 630 Integrity Protection: no 631 Replay Protection: no 632 Confidentiality: yes (section 7.3.2) 633 Key Derivation: yes (section 7.3.3) 634 Key Strength: no 635 Dictionary Attacks: yes (section 7.3.4) 636 Fast Reconnect: no 637 EAP Smart Card Protocol (EAP-SC) October 2005 639 Cryptographic Binding: yes (section 7.3.6) 640 Session Independence: no 641 Fragmentation: no 642 Channel Binding: yes (section 7.3.7) 644 9 References 646 [RFC 3748], Extensible Authentication Protocol (EAP), B. Aboba, L. 647 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, June 2004. 649 [SC-EAP], draft-urien-eap-smartcard-09.txt, P.Urien, A.J. Farrugia, 650 M.Groot, G.Pujolle, J. Abellan, October 2005 652 [UICC-EAP] European Telecommunications Standards Institute, ETSI TS 653 102.310 Extensible Authentication Protocol support in the UICC 655 [WLAN-SIM] WLAN-SIM specification V1.0, WLAN Smart Card Consortium, 656 October 20, 2003 658 [WLAN-SC] Wlan Smart Card Handler Specification, WLAN Smart Card 659 Consortium, - in progress - 661 [EAP-SIM] Extensible Authentication Protocol Method for GSM 662 Subscriber Identity, IETF, April 4, 2004 664 [GLOBAL PLATFORM] GlobalPlatform Card Specification v2.1.1, 665 GlobalPlatform, March 2003 667 [FIPS] FIPS 140-1 and FIPS 140-2 Cryptographic Modules Validation 668 List, National Institute of Standards 670 [COMMON CRITERIA] Common Criteria Project 672 [EAP-SIM-Handler] EAP-SIM Handler specification V1.1, WLAN Smart 673 Card Consortium, August 1, 2004. 675 [EAP-AKA] Extensible Authentication Protocol Method for UMTS 676 Authentication and Key Agreement, IETF, April 5, 2004 678 [NIST-PIV] NIST Special Publication 800-73 Draft, January 25, 2005 680 10 Author's Addresses 682 Pascal Urien 683 ENST 684 www.enst.fr Email: Pascal.Urien@enst.fr 686 Wouter Habraken 687 RAAK Technologies 688 www.raaktechnologies.com Email: whabraken@raaktechnologies.com 689 EAP Smart Card Protocol (EAP-SC) October 2005 691 David Flattin 692 Oberthur Card Systems 693 www.oberthurcs.com Email: d.flattin@oberthurcs.com 695 Herve Ganem 696 Axalto 697 www.axalto.com Email: hganem@axalto.com 698 EAP Smart Card Protocol (EAP-SC) October 2005 700 11 Intellectual Property Statement 702 The IETF takes no position regarding the validity or scope of any 703 Intellectual Property Rights or other rights that might be claimed 704 to pertain to the implementation or use of the technology described 705 in this document or the extent to which any license under such 706 rights might or might not be available; nor does it represent that 707 it has made any independent effort to identify any such rights. 708 Information on the procedures with respect to rights in RFC 709 documents can be found in BCP 78 and BCP 79. 711 Copies of IPR disclosures made to the IETF Secretariat and any 712 assurances of licenses to be made available, or the result of an 713 attempt made to obtain a general license or permission for the use 714 of such proprietary rights by implementers or users of this 715 specification can be obtained from the IETF on-line IPR repository 716 at http://www.ietf.org/ipr. 718 The IETF invites any interested party to bring to its attention any 719 copyrights, patents or patent applications, or other proprietary 720 rights that may cover technology that may be required to implement 721 this standard. Please address the information to the IETF at ietf- 722 ipr@ietf.org 724 12 Disclaimer of Validity 726 This document and the information contained herein are provided on 727 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 728 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 729 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 730 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 731 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 13 Copyright Statement 736 Copyright (C) The Internet Society (2004). This document is subject 737 to the rights, licenses and restrictions contained in BCP 78, and 738 except as set forth therein, the authors retain all their rights. 740 14 Acknowledgment 741 Thanks to Bertrand Ducastel, president of the WLAN consortium 742 (www.wlansmartcard.org), for his valuable comments.