EAP Working Group Y. Ohba
Internet-Draft Toshiba
Expires: November 12, 2005 May 11, 2005
AAA-Key Derivation with Channel Binding
draft-ohba-eap-aaakey-binding-00
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 November 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an alternative method for deriving a AAA-Key.
The method cryptographically binds EAP lower-layer parameters to the
AAA-Key without need to carry those parameters in EAP methods.
Ohba Expires November 12, 2005 [Page 1]
Internet-Draft AAA-Key Binding May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution Framework . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Key Binding Blob for Lower-Layer Parameters . . . . . . . 4
2.2 AAA-Key Derivation Algorithm . . . . . . . . . . . . . . . 4
2.3 AAA-Key Scope . . . . . . . . . . . . . . . . . . . . . . 4
2.4 AAA-Key Name . . . . . . . . . . . . . . . . . . . . . . . 4
2.5 Key Binding Procedure . . . . . . . . . . . . . . . . . . 5
3. AAA Protocol Consideration . . . . . . . . . . . . . . . . . . 6
4. Recommendations to EAP Lower-Layer . . . . . . . . . . . . . . 7
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Ohba Expires November 12, 2005 [Page 2]
Internet-Draft AAA-Key Binding May 2005
1. Introduction
EAP (Extensible Authentication Protocol) is an authentication
framework which supports multiple authentication algorithms known as
"EAP methods" [RFC3748]. EAP lower- layers use a key generated and
exported by an EAP method to bootstrap their ciphersuites. This key
is referred to as AAA-Key. A framework for the generation, transport
and usage of AAA-Key is described in [I-D.ietf-eap-keying].
Each EAP lower-layer has its own parameters that are carried at the
lower-layer. EAP lower-layer end-point identifiers are one of such
parameters. Those parameters would need to be cryptographically
bound to the AAA-Key to avoid a possible man-in-the-middle attack
which is also known as the lying NAS problem.
A mechanism that is described in [RFC3748] to create such a binding
is based on communicating lower-layer parameters over a protected
channel of an EAP method to help the EAP peer and the EAP server
detect a mismatch between the parameters exchanged over the protected
channel and the ones advertised at an unprotected lower-layer. There
have been several solutions [I-D.arkko-eap-service-identity-auth]
[I-D.tschofenig-eap-ikev2] that are based on this mechanism.
This document describes an alternate mechanism for creating a binding
between a AAA-Key and EAP lower-layer parameters without need for an
EAP method to carry the EAP lower-layer parameters.
Ohba Expires November 12, 2005 [Page 3]
Internet-Draft AAA-Key Binding May 2005
2. Solution Framework
In this solution, it is the EAP lower-layer entities that makes the
final decision as to whether the the lower-layer parameters are
successfully bound to the AAA-Key, regardless of the location of the
EAP server.
Assuming that there is not always trust relationship between EAP peer
and EAP authenticator, the EAP server with which both the EAP peer
and EAP authenticator have trust relationship needs to involve in the
process of binding the EAP lower-layer parameters to the AAA-Key.
However, the EAP server should not need to have knowledge on specific
EAP lower-layer parameters to be bound to the AAA-Key. Similarly, a
AAA protocol should not need to have knowledge on the specific EAP
lower-layer parameters to be bound to the AAA-Key.
2.1 Key Binding Blob for Lower-Layer Parameters
Each EAP lower-layer must define a blob that is an octet string
carrying lower-layer parameters that need to be bound to the AAA-Key.
Such a blob is referred to as a key-binding-blob. It is the
responsibility of each EAP lower-layer to define how the lower-layer
parameters is encoded in the key-binding-blob.
2.2 AAA-Key Derivation Algorithm
As a result of successful authentication, the EAP peer and EAP server
derives a AAA-Key from the MSK [I-D.ietf-eap-keying] exported by the
EAP method as follows.
AAA-Key = PRF(MSK, AAA-Key-name|key-binding-blob)
PRF is a pseudo random function. The definition of PRF is TBD. AAA-
Key-name is the name of the AAA-Key. The format of the name of AAA-
Key is described in Section 2.4
2.3 AAA-Key Scope
The scope of a AAA-Key is between the pair of a particular EAP peer
and a particular EAP authenticator. The AAA-Key MUST NOT be shared
among multiple EAP authenticators or multiple EAP peers.
2.4 AAA-Key Name
The name of a AAA-Key is concatenation of "AAA-Key", the EAP peer
identifier, the EAP authenticator identifier and the EAP Session-Id.
When a AAA protocol is used between the EAP authenticator and the EAP
server, the EAP peer identifier and the EAP authenticator identifier
Ohba Expires November 12, 2005 [Page 4]
Internet-Draft AAA-Key Binding May 2005
are identical to the Called-Station-Id and the Calling-Station-Id
attributes, respectively. The format of EAP peer identifier and EAP
authenticator identifier must be defined by each EAP lower-layer.
2.5 Key Binding Procedure
During an EAP authentication run, the EAP authenticator constructs a
key-binding-blob from the EAP lower-layer parameters and sends the
key-binding-blob to the EAP server. When the EAP authenticator is
acting as a pass-through authenticator, a AAA protocol would be used
for communicating the key-binding-blob to the EAP server.
Upon successful EAP authentication, the EAP peer and the EAP server
are expected to compute the AAA-Key using the above algorithm. The
computed AAA-Key is delivered from the EAP server to the EAP
authenticator.
Finally, the EAP peer and the EAP authenticator verify the possession
of the AAA-Key via a secure association protocol to establish a
secure association. For the verification process to succeed, it is
required for the EAP authenticator to have obtained the same AAA-Key
from the EAP server as the EAP peer has. This actually requires the
EAP authenticator to have sent the same key-binding-blob to the EAP
server as the one the EAP peer constructs from the lower-layer
parameters obtained via the lower-layer protocol.
Ohba Expires November 12, 2005 [Page 5]
Internet-Draft AAA-Key Binding May 2005
3. AAA Protocol Consideration
When a AAA protocol such as RADIUS [RFC2865] and Diameter [RFC3588]
is used for carrying EAP messages between an EAP authenticator and
the EAP server, the key-binding-blob is carried in a AAA protocol as
a AAA attribute. The Key-Binding-Blob attribute, which is a new
RADIUS attribute, is defined for this purpose. Since Diameter has a
backward compatibility with RADIUS, it is possible to automatically
convert a RADIUS attribute to a corresponding Diameter AVP and vise
versa.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Opaque Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD
Represents Key-Binding-Blob.
Length: >=3
Opaque Data:
Contains a key-binding-blob that carries EAP lower-layer
parameters that need to be bound to the AAA-Key.
Ohba Expires November 12, 2005 [Page 6]
Internet-Draft AAA-Key Binding May 2005
4. Recommendations to EAP Lower-Layer
Although the format of the content of a key-binding-blob is totally
up to each EAP lower-layer, there is some recommendations on
formatting.
Since there are already several AAA attributes such as Calling-
Station-Id and Called-Station-Id that carry EAP lower-layer
attributes, it is recommended to reuse the already defined format for
the attributes in a way that a key-binding-blob is formatted as an
ordered sequence of AAA attributes where each AAA attribute contains
an EAP lower-layer parameter.
To increase randomness of AAA-Key, a key-binding-blob should contain
an attribute that carries a random value. An EAP lower-layer should
exchange such a random value between the end-points of the EAP lower-
layer.
Ohba Expires November 12, 2005 [Page 7]
Internet-Draft AAA-Key Binding May 2005
5. Discussion
The solution described in this document makes EAP methods totally
agnostic to EAP lower-layers. EAP methods do not need to carry EAP
lower-layer parameters even in the form of a blob.
The solution does not require a AAA protocol entity to know the
semantics of key-binding-blobs. It just needs to carry key-binding-
blobs in a AAA protocol as opaque data.
The solution works regardless of whether an EAP authenticator is
acting as a pass-through authenticator or not.
The solution requires a change in the existing AAA-Key derivation
algorithm described in section 2.3 of [I-D.ietf-eap-keying]. This
might lead to a deployment issue.
Ohba Expires November 12, 2005 [Page 8]
Internet-Draft AAA-Key Binding May 2005
6. Security Considerations
The solution described in this document improves the security
characteristics of the EAP key management framework in that a secure
association is never established if there is a difference in EAP
lower-layer parameters recognized by the EAP peer and the EAP
authenticator. This is in contrast to existing channel binding
methods described in [I-D.arkko-eap-service-identity-auth]
[I-D.tschofenig-eap-ikev2] in which an EAP peer can still establish a
secure association even when a mismatch in EAP lower-layer parameters
is detected by the EAP peer, as the EAP peer can ignore the mismatch
and continue the EAP conversation to succeed.
Ohba Expires November 12, 2005 [Page 9]
Internet-Draft AAA-Key Binding May 2005
7. Acknowledgments
The author would like to thank Jari Arkko and Bernard Aboba for
discussing this issue on the EAP mailing list and giving insights.
Ohba Expires November 12, 2005 [Page 10]
Internet-Draft AAA-Key Binding May 2005
8. References
8.1 Normative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-06 (work in
progress), April 2005.
8.2 Informative References
[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", draft-arkko-eap-service-identity-auth-02 (work in
progress), May 2005.
[I-D.tschofenig-eap-ikev2]
Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method (EAP-
IKEv2)", draft-tschofenig-eap-ikev2-05 (work in progress),
October 2004.
Author's Address
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Ohba Expires November 12, 2005 [Page 11]
Internet-Draft AAA-Key Binding May 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ohba Expires November 12, 2005 [Page 12]