Internet DRAFT - draft-urien-eap-smartcard-type
draft-urien-eap-smartcard-type
Internet Draft P.Urien
Document: draft-urien-eap-smartcard-type-03.txt ENST
W.Habraken
RAAK Technologies
D. Flattin
Oberthur Card Systems
H. Ganem
Axalto
Expires: April 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 April, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Urien & All Informational - Expires April 2006 [Page 1]
EAP Smart Card Protocol (EAP-SC) October 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 April 2006 [Page 2]
EAP Smart Card Protocol (EAP-SC) October 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 Supplicant Multiplexing Model...................6
4.3 The EAP-SC Authenticator multiplexing model................6
4.4 Smart Card Support.........................................7
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.........9
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..............................................10
7.2 Smart Card Security Capabilities and Requirements.........10
7.2.1 Smart Card Technology................................11
7.2.2 Tamper Resistant Storage and Execution...............11
7.2.3 Multi Factor Authentication..........................11
7.2.4 Random Number Generation.............................11
7.2.5 Cryptographic Capabilities...........................11
7.2.6 Secure Provisioning..................................12
7.2.7 Certification........................................12
7.3 Smart Cards and EAP Security Claims.......................12
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............................13
7.3.5 Dictionary Attacks...................................13
7.3.6 Cryptographic Binding................................13
7.3.7 Channel Binding......................................13
7.3.8 Protection Against Rogue Networks....................13
7.3.9 Authentication Method Security.......................13
8 Security Claims................................................13
9 References.....................................................14
10 Author's Addresses..........................................14
11 Intellectual Property Statement.............................16
12 Disclaimer of Validity......................................16
13 Copyright Statement.........................................16
14 Acknowledgment..............................................16
Urien & All Informational - Expires April 2006 [Page 3]
EAP Smart Card Protocol (EAP-SC) October 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 April 2006 [Page 4]
EAP Smart Card Protocol (EAP-SC) October 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 Card | | EAP method |
|...Type=X....| | Type=X |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 April 2006 [Page 5]
EAP Smart Card Protocol (EAP-SC) October 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 Supplicant 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 The EAP-SC Authenticator multiplexing model
On the authenticator side the EAP-SC method acts as a multiplexing
layer that delivers the following services
Urien & All Informational - Expires April 2006 [Page 6]
EAP Smart Card Protocol (EAP-SC) October 2005
- EAP requests issued by a particular method, whose type is X (see
figure 1), are encapsulated in EAP-SC packets, according to rules
detailed in section 5.1
- EAP responses, whose type is EAP-SC (see figure 1) are converted
to standard EAP messages whose type is X, according to rules defined
in section 5.1. Converted messages are then directed toward the
appropriate method.
4.4 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
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
Urien & All Informational - Expires April 2006 [Page 7]
EAP Smart Card Protocol (EAP-SC) October 2005
- 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.
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
Urien & All Informational - Expires April 2006 [Page 8]
EAP Smart Card Protocol (EAP-SC) October 2005
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].
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
The EAP-SC protocol by itself doesn’t modify the security claims of
a particular method, because it only provides a transparent
encapsulation in a single type.
Urien & All Informational - Expires April 2006 [Page 9]
EAP Smart Card Protocol (EAP-SC) October 2005
But EAP-SC greatly facilitates the use of smartcards in EAP
sessions, and avoid conflicts with classical software
implementations.
They are two basic assumptions about smartcards, first they are very
difficult to clone, and second it is quite impossible to steal
secret embedded information, like cryptographic keys.
As a consequence a software clone of smartcard could not work,
because this should require to get secret credentials stored in the
tamper resistant device.
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:
- 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:
Urien & All Informational - Expires April 2006 [Page 10]
EAP Smart Card Protocol (EAP-SC) October 2005
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).
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.
Urien & All Informational - Expires April 2006 [Page 11]
EAP Smart Card Protocol (EAP-SC) October 2005
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
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.
Urien & All Informational - Expires April 2006 [Page 12]
EAP Smart Card Protocol (EAP-SC) October 2005
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.
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
Urien & All Informational - Expires April 2006 [Page 13]
EAP Smart Card Protocol (EAP-SC) October 2005
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-09.txt, P.Urien, A.J. Farrugia,
M.Groot, G.Pujolle, J. Abellan, October 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
[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
Urien & All Informational - Expires April 2006 [Page 14]
EAP Smart Card Protocol (EAP-SC) October 2005
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 April 2006 [Page 15]
EAP Smart Card Protocol (EAP-SC) October 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 (2004). 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 April 2006 [Page 16]
