Network Working Group P. Eronen
Internet-Draft H. Haverinen
Expires: August 11, 2005 Nokia
J. Arkko
Ericsson
J. Salowey
Cisco Systems
February 10, 2005
Evaluation of Cellular Extensible Authentication Protocol (EAP)
Methods agaist IEEE 802.11 requirements
draft-eronen-eap-sim-aka-80211-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note
IESG note goes here.
Eronen, et al. Expires August 11, 2005 [Page 1]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
Abstract
This document evaluates two Extensible Authentication Protocol (EAP)
methods, EAP-AKA and EAP-SIM, against the EAP method requirements for
Wireless LANs given in [802.11 REQ].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Mandatory Requirements . . . . . . . . . . . . . . . . . . 3
3.1.1 Generation of Symmetric Keying Material . . . . . . . 4
3.1.2 Key Strength . . . . . . . . . . . . . . . . . . . . . 4
3.1.3 Mutual Authentication Support . . . . . . . . . . . . 4
3.1.4 Shared State Equivalence . . . . . . . . . . . . . . . 4
3.1.5 Resistance to Dictionary Attacks . . . . . . . . . . . 6
3.1.6 Protection against Man-in-the-Middle Attacks . . . . . 6
3.1.7 Protected Ciphersuite Negotiation . . . . . . . . . . 7
3.2 Recommended Requirements . . . . . . . . . . . . . . . . . 7
3.2.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 7
3.2.2 End-User Identity Hiding . . . . . . . . . . . . . . . 7
3.3 Optional Features . . . . . . . . . . . . . . . . . . . . 8
3.3.1 Channel Binding . . . . . . . . . . . . . . . . . . . 8
3.3.2 Fast Reconnect . . . . . . . . . . . . . . . . . . . . 8
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9
8.2 Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Eronen, et al. Expires August 11, 2005 [Page 2]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
1. Introduction
The Extensible Authentication Protocol (EAP) allows different
authentication protocols to be encapsulated as EAP methods. EAP is
specified in [RFC3748]. EAP-AKA ([EAP-AKA]) is an EAP method based
on the Authentication and Key Agreement (AKA) mechanisms that are
used in 3rd generation mobile network standards Universal Mobile
Telecommunications System (UMTS) and cdma2000. EAP-SIM ([EAP-SIM])
is an EAP method based on the GSM Subscriber Identity Modules (SIM).
GSM is a 2nd generation mobile network standard.
The IEEE 802.11i MAC Security Enhancements Amendment specifies
security enhancements for IEEE 802.11 wireless LANs. The Extensible
Authentication Protocol is used in IEEE 802.11i, and [802.11 REQ]
specifies the EAP method requirements for IEEE 802.11 wireless LANs.
This document evaluates EAP-SIM and EAP-AKA against the requirements
given in [802.11 REQ].
2. Terms
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 [RFC2119].
The terms and abbreviations "EAP server", "EAP peer", "Master Session
Key (MSK)", "Extended Master Session Key (EMSK)", and the terminology
for security claims in this document are to be interpreted as
described in [RFC3748].
3. Evaluation
This section goes through the EAP method requirements given in
[802.11 REQ] and discusses the support for each feature in EAP-AKA
and EAP-SIM.
Many requirements in [802.11 REQ] refer to the security claims
defined in [RFC3748]. For EAP-AKA, the support for these claims is
stated and justified in Sections 11 and 12 of [EAP-AKA]. For
EAP-SIM, the support for the claims is stated and justified in
Sections 11 and 12 of [EAP-SIM].
3.1 Mandatory Requirements
[802.11 REQ] lists the features discussed in this section as
mandatory requirements, which MUST be supported by EAP methods
suitable for use in wireless LAN authentication.
Eronen, et al. Expires August 11, 2005 [Page 3]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
3.1.1 Generation of Symmetric Keying Material
This requirement corresponds to the to the "Key derivation" security
claim defined in [RFC3748], Section 7.2.1, which is supported by
EAP-AKA and EAP-SIM.
3.1.2 Key Strength
This requirement of [802.11 REQ] requires that the EAP method must be
capable of generating keying material with 128 bits of effective key
strength. EAP-AKA and EAP-SIM are both capable of this, so they
satisfy this requirement. For EAP-AKA, please see section 11.4 of
[EAP-AKA], and for EAP-SIM, see Section 11.5 of [EAP-SIM].
3.1.3 Mutual Authentication Support
This requirement corresponds to the to the "mutual authentication"
security claim defined in [RFC3748], Section 7.2.1, which is
supported by EAP-AKA and EAP-SIM.
3.1.4 Shared State Equivalence
This requirement states that "the shared EAP method state of the EAP
peer and server must be equivalent when the EAP method completes
successfully on both sides", and also that "both parties must be able
to distinguish this instance of the protocol from all other instances
of the protocol and they must share the same view of which state
attributes are public and which are private to the two parties
alone." EAP-AKA and EAP-SIM satisfy this requirement.
The shared state attributes, and whether each attribute is public or
private to the EAP peer and server, are summarized below.
When EAP-SIM full authentication completes successfully on both
sides, the EAP peer and EAP server share the following state
information:
o the fact that the exchange was an EAP-SIM full authentication;
public
o the last peer identity communicated in the protocol (and thereby
selected for use); public
o the ordered list of server's proposed EAP-SIM version numbers;
public
o the EAP-SIM version selected by the peer; public
o peer's NONCE_MT parameter; public
o the number of GSM authentication triplets used in the exchange, 2
or 3; public
Eronen, et al. Expires August 11, 2005 [Page 4]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
o the triplets (RAND, SRES, Kc) used in the exchange; RAND is
public, SRES and Kc are private in this protocol
o a new pseudonym username, if sent by the server, and if the peer
supports identity privacy. If the peer does not support identity
privacy, then the peer ignores this information from the exchange;
private until the first full authentication exchange where the
peer uses it.
o a re-authentication identity, if sent by the peer and if the peer
supports fast re-authentication. If the peer does not support
fast re-authentication then the peer ignores this information from
the exchange; private until the next re-authentication exchange
o Master Key; private
o Master Session Key; public to parties to which the server sends
the key
o Extended Master Session Key; private
o whether protected result indications were used; public
The EAP-SIM full authentication exchange can be distinguished from
other instances by 1) RAND challenges, and 2) NONCE_MT parameter.
When EAP-AKA full authentication completes successfully on both
sides, the EAP peer and EAP server share the following state
information:
o the fact that the exchange was an EAP-AKA full authentication
o the last peer identity communicated in the protocol (and thereby
selected for use); public
o the 3G AKA authentication vector used in the exchange (RAND, AUTN,
RES, CK, IK); RAND, AUTN, RES are public, CK and IK are private
o a new pseudonym username, if sent by the server, and if the peer
supports identity privacy. If the peer does not support identity
privacy, then the peer ignores this information from the exchange;
private until the first full authentication exchange where the
peer uses it.
o a re-authentication identity, if sent by the peer and if the peer
supports fast re-authentication. If the peer does not support
fast re-authentication then the peer ignores this information from
the exchange; private until the next re-authentication exchange
o Master Key; private
o Master Session Key; public to parties to which the server sends
the key
o Extended Master Session Key; private
o whether protected result indications were used; public
The EAP-AKA full authentication exchange can be distinguished from
other instances by 1) RAND, and 2) AUTN (or actually the 3G AKA
sequence number that is contained within the AUTN).
Eronen, et al. Expires August 11, 2005 [Page 5]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
When an EAP-AKA or EAP-SIM fast re-authentication exchange completes
successfully on both sides, the EAP peer and the EAP server share the
following state information:
o the EAP method used (EAP-AKA or EAP-SIM), which is the same method
as in full authentication; public
o the fact that the exchange was a fast re-authentication; public
o the preceding instance of full authentication, and the Master Key
derived upon the full authentication exchange; private
o the re-authentication identity used; public
o server's NONCE_S; private
o the value of the counter; private (observers may be able to guess
the value of the counter by counting the number of
re-authentication exchanges)
o a new re-authentication identity, if sent by the server. The peer
may ignore this information if the peer does not want to run fast
re-authentication again; private until the next re-authentication
exchange
o Master Session Key; public to parties to which the server sends
the key
o Extended Master Session Key; private
o whether protected result indications were used; public
The fast re-authentication exchange can be distinguished from other
instances by 1) the full authentication exchange instance 2) the
value of the counter.
3.1.5 Resistance to Dictionary Attacks
This requirement corresponds to the to the "dictionary attack
resistance" security claim defined in [RFC3748], Section 7.2.1. This
claim is only applicable to password or passphrase based protocols,
so it is not applicable to EAP-AKA or EAP-SIM that are based on
strong 128-bit shared keys.
3.1.6 Protection against Man-in-the-Middle Attacks
According to [802.11 REQ], this requirement corresponds to the
"Cryptographic binding", "Integrity protection", "Replay protection",
and "Session independence" security claims defined in [RFC3748],
Section 7.2.1.
The "Cryptographic binding" security claim is only applicable to
tunnel methods which are capable of encapsulating another EAP method
within a protected tunnel. Since EAP-AKA and EAP-SIM are not tunnel
methods, this claim is not applicable to EAP-AKA or EAP-SIM. A
tunnel method that supports cryptographic binding can encapsulate and
bind to EAP-AKA or EAP-SIM, because EAP-AKA and EAP-SIM support key
Eronen, et al. Expires August 11, 2005 [Page 6]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
derivation, which is needed in order for the binding to work.
EAP-AKA and EAP-SIM satisfy the security claims "Integrity
protection", "Replay protection" and "Session independence".
3.1.7 Protected Ciphersuite Negotiation
[802.11 REQ] requires that "if the method negotiates the ciphersuite
used to protect the EAP conversation, then it MUST support the
"Protected ciphersuite negotiation" security claim defined in
[RFC3748], Section 7.2.1." Since EAP-AKA and EAP-SIM do not negotiate
the ciphersuite, this requirement is not applicable to EAP-AKA and
EAP-SIM.
EAP-SIM supports protected EAP method version negotiation, so if a
new EAP-SIM version later introduces a different ciphersuite, then
the protected EAP method version negotiation will protect the
(implied) ciphersuite negotiation.
EAP-AKA does not support EAP method version negotiation. However, if
new extensions, such as EAP method version negotiation extensions or
ciphersuite negotiation extensions, are later introduced to the very
first messages of EAP-AKA that do not contain a message
authentication code, then EAP-AKA requires that these messages MUST
be protected with the AT_CHECKCODE attribute.
3.2 Recommended Requirements
In [802.11 REQ], the features discussed in this section are mentioned
as recommended requirements, which SHOULD be supported by EAP method
suitable for use in wireless LAN authentication.
3.2.1 Fragmentation
Fragmentation is not supported by EAP-AKA and EAP-SIM. For more
discussion, please see Section 4.
3.2.2 End-User Identity Hiding
According to [802.11 REQ], this requirement corresponds to the
"Confidentiality" security claim defined in [RFC3748], Section 7.2.1.
In [RFC3748], Confidentiality "refers to encryption of EAP messages,
including EAP Requests and Responses, and success and failure result
indications. A method making this claim MUST support identity
protection." [RFC3748] does not clearly define "Identity
protection", but in Section 7.3 identity protection is discussed as
follows: "It is possible for the identity in the identity response to
be different from the identity authenticated by the EAP method. This
Eronen, et al. Expires August 11, 2005 [Page 7]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
may be intentional in the case of identity privacy."
EAP-AKA and EAP-SIM support the security claim "Confidentiality",
except for method specific success and failure indications. EAP-AKA
and EAP-SIM support identity privacy against passive attacks via
temporary identities that are used instead of the permanent identity.
Protection against active attacks may also be implemented if the peer
and the server can maintain the temporary identities reliably and the
client follows a policy where the cleartext identity is not given out
after an initial successful authentication.
3.3 Optional Features
The features discussed in this section are listed in [802.11 REQ] as
optional features, which MAY be supported by EAP methods.
3.3.1 Channel Binding
EAP-AKA and EAP-SIM do not include the optional channel binding
feature. However, ongoing work such as [Service Identity] may
provide such support as an extension to popular EAP methods such as
EAP-TLS, EAP-SIM, or EAP-AKA.
3.3.2 Fast Reconnect
This requirement corresponds to the to the "fast reconnect" security
claim defined in [RFC3748], Section 7.2.1, which is supported by
EAP-AKA and EAP-SIM. Fast reconnect is called fast re-authentication
in the EAP-AKA and EAP-SIM specifications. Both methods satisfy this
requirement.
4. Conclusions
The support in EAP-AKA and EAP-SIM for each requirement and optional
feature listed in [802.11 REQ] is discussed in the previous section
of this document. In summary, both EAP methods satisfy all the
applicable mandatory (MUST and MUST NOT) requirements.
The methods do not satisfy the recommended (SHOULD) requirement about
EAP message fragmentation. In EAP-AKA and EAP-SIM, protocol messages
include variable-length fields that can be used to transmit Network
Access Identifiers, and the protocols can be extended with new
attributes, so in theory it is possible that the message size could
exceed the EAP Maximum Transfer Unit (MTU) of 1020 octets. However,
in practice the EAP packets transmitted in these protocols, in
particular when the identity formats specified by 3GPP are used, are
considerably smaller than the EAP MTU so the lack of fragmentation is
not a problem.
Eronen, et al. Expires August 11, 2005 [Page 8]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
The methods satisfy the second recommended (SHOULD) requirement,
"end-user identity hiding", against all passive attacks and in some
cases against active attacks. The methods support the optional
feature "fast reconnect". These versions of the methods do not
support the optional feature "channel binding".
5. IANA Considerations
This document does not require any new IANA registries or parameter
allocation by IANA.
6. Security Considerations
Security issues are discussed throughout this document.
7. Acknowledgements
The authors would like to thank Bernard Aboba and Yoshihiro Ohba for
the most valuable discussions on these protocols.
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[802.11 REQ]
Stanley, D., Walker, J. and B. Aboba, "EAP Method
Requirements for Wireless LANs",
draft-walker-ieee802-req-04 (work in progress), August
2004.
[EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication",
draft-arkko-pppext-eap-aka-15 (work in progress), December
2004.
[EAP-SIM] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for GSM Subscriber Identity Modules
(EAP-SIM)", draft-arkko-pppext-eap-sim-16 (work in
progress), December 2004.
Eronen, et al. Expires August 11, 2005 [Page 9]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
8.2 Informative References
[Service Identity]
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", draft-arkko-service-identity-auth-01 (work in
progress), October 2004.
Authors' Addresses
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Henry Haverinen
Nokia Enterprise Solutions
P.O. Box 12
FIN-40101 Jyvaskyla
Finland
EMail: henry.haverinen@nokia.com
Jari Arkko
Ericsson
FIN-02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: jari.Arkko@ericsson.com
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
USA
Phone: +1 206 256 3380
EMail: jsalowey@cisco.com
Eronen, et al. Expires August 11, 2005 [Page 10]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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.
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.
Eronen, et al. Expires August 11, 2005 [Page 11]
Internet-Draft EAP-SIM and EAP-AKA Evaluation February 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eronen, et al. Expires August 11, 2005 [Page 12]