Internet DRAFT - draft-ohba-eap-aaakey-binding
draft-ohba-eap-aaakey-binding
EAP Working Group Y. Ohba
Internet-Draft Toshiba
Expires: December 3, 2005 M. Yanagiya
NTT
Jun 2005
AAA-Key Derivation with Lower-Layer Parameter Binding
draft-ohba-eap-aaakey-binding-01
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 December 3, 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 & Yanagiya Expires December 3, 2005 [Page 1]
Internet-Draft AAA-Key Binding Jun 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Specification of Requirements . . . . . . . . . . . . . . 3
2. Problem Description . . . . . . . . . . . . . . . . . . . . 4
3. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Trust Relationship . . . . . . . . . . . . . . . . . . . . 5
3.2 Securty Association . . . . . . . . . . . . . . . . . . . 5
4. Solution Framework . . . . . . . . . . . . . . . . . . . . . 7
4.1 Key Binding Blob for Lower-Layer Parameters . . . . . . . 7
4.2 AAA-Key Derivation Algorithm . . . . . . . . . . . . . . . 7
4.3 AAA-Key Scope . . . . . . . . . . . . . . . . . . . . . . 7
4.4 AAA-Key Name . . . . . . . . . . . . . . . . . . . . . . . 7
4.5 Key Binding Procedure . . . . . . . . . . . . . . . . . . 8
5. Validating Key Binding Blob . . . . . . . . . . . . . . . . 9
6. AAA Protocol Consideration . . . . . . . . . . . . . . . . . 10
7. Co-existence with Legacy AAA-Key Derivation Algorithm . . . 12
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1 Normative References . . . . . . . . . . . . . . . . . . 16
11.2 Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 18
Ohba & Yanagiya Expires December 3, 2005 [Page 2]
Internet-Draft AAA-Key Binding Jun 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 possible security flaws.
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.
1.1 Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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].
Ohba & Yanagiya Expires December 3, 2005 [Page 3]
Internet-Draft AAA-Key Binding Jun 2005
2. Problem Description
When an authentication and authorization procedure for a network
access service succeeds using EAP with an EAP authentication method
that is capable of generating a Master Session Key (MSK), a AAA-Key
is derived from the MSK and transferred from the EAP server and the
EAP authenticator [I-D.ietf-eap-keying] for use by the EAP lower
layer to further derive keys used for protecting the lower layer.
However, if the AAA-Key is not bound to EAP lower layer parameters,
the key may be used for a different context of the EAP lower layer or
even for a different EAP lower layer. Detailed examples on this
problem is described in section 2 of [I-D.arkko-eap-service-identity-
auth].
The problem has been originally known as channel binding problem
[RFC3748] [I-D.ietf-eap-keying]. However, the solution that is
suggested in those documents is to use EAP methods that can carry EAP
lower layer parameters and expecting the EAP server and EAP peer to
validate them by comparing with the EAP lower layer parameters
carried via the EAP lower layer protocol between the EAP peer and EAP
authenticator or a AAA protocol between the EAP authenticator or the
EAP server. The solution, however, requires each EAP method to carry
EAP lower layer parameters, which is not actually needed for a
standalone EAP authenticator while binding the EAP lower layer
parameters to the AAA-Key is still somehow needed for both standalone
and pass-through EAP authenticators. This leads to a need for a more
generic key binding mechanism that does not require any change in
existing EAP methods and can work with both standalone and pass-
through EAP authenticators in the same way.
Ohba & Yanagiya Expires December 3, 2005 [Page 4]
Internet-Draft AAA-Key Binding Jun 2005
3. Prerequisites
There are following prerequisites for the solution proposed in this
document to work.
3.1 Trust Relationship
In this document, trust relationship is characterized with a "trust
level" to cover a wide range of scenarios including roaming
scenarios. A full level of trust relationship between two or more
entities is defined where each entity trusts whatever other entities
claim. There are following prerequisites with regard to trust
relationship between an EAP peer, an EAP authenticator and an EAP
server involving in an EAP conversation.
o There is a full level of trust relationship between the EAP peer
and the EAP server.
o There is a trust relationship between the EAP server and the EAP
authenticator. The trust level between them may vary depending on
the deployment. For example, if they are implemented on the same
physical box, it is highly likely that there is a full level of
trust relationship between them. On the other hand, if they are
implemented on different physical boxes belonging to different
service providers, there may not be a full level of trust
relationship between them, even if there is some sort of roaming
agreement between the service providers. In this case, the EAP
server does not always trust what the EAP authenticator claims.
o There is a trust relationship between the EAP peer and the EAP
authenticator, but most likely the trust relationship is not a
full level. The level of the trust relationship is high enough
for the EAP peer to use the AAA-Key in the service provided by the
EAP lower-layer.
3.2 Securty Association
In general, a security association is a relationship established
between two or more entities to enable them to protect data they
exchange [RFC2828]. A security association needs to be established
between such entities unless the underlying communication path is
already protected by some other mechanism. The following security
associations needs to be established prior to execute EAP.
o A security association between the EAP peer and the EAP server in
order to establish an MSK (Master Session Key) [I-D.ietf-eap-
keying].
Ohba & Yanagiya Expires December 3, 2005 [Page 5]
Internet-Draft AAA-Key Binding Jun 2005
o A security association between the EAP authenticator and the EAP
server in case an untrusted third party may interfere the
communication between them.
Ohba & Yanagiya Expires December 3, 2005 [Page 6]
Internet-Draft AAA-Key Binding Jun 2005
4. Solution Framework
In the proposed solution, it is the EAP lower-layer entities that
make 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. To this end, the EAP server that has a trust
relationship with both the EAP peer and the EAP authenticator needs
to involve in the process of binding the EAP lower-layer parameters
to the AAA-Key. The proposed solution, however, does not require EAP
and EAP methods to carry EAP lower-layer parameters. The proposed
solution is designed such that the AAA-Key derivation algorithm is
agnostic to specific EAP lower-layer parameters.
4.1 Key Binding Blob for Lower-Layer Parameters
Each EAP lower-layer must define a blob that is an octet-string used
for carrying lower-layer parameters that need to be bound to the AAA-
Key. Such a blob is referred to as a "key-binding-blob". A key-
binding-blob contains parameters that persist long-term such as the
identification of the EAP authenticator. It is the responsibility of
each EAP lower-layer to define how the EAP lower-layer parameters are
encoded in the blob.
When the EAP authenticator and the EAP server are implemented in
different physical boxes, a key-binding-blob is carried in a AAA
protocol as described in Section 6.
4.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 = KDF(MSK, AAA-Key-name|key-binding-blob)
KDF is a key derivation function. The definition of KDF is TBD.
AAA-Key-name is the name of the AAA-Key. The format of the name of
AAA-Key is described in Section 4.4
4.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.
4.4 AAA-Key Name
TBD.
Ohba & Yanagiya Expires December 3, 2005 [Page 7]
Internet-Draft AAA-Key Binding Jun 2005
4.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.
Depending on the level of the trust relationship between the EAP
authenticator and EAP server, the EAP server MAY validate the key-
binding-blob as described in Section 5 and the authentication
procedure MUST fail when the validation fails.
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 & Yanagiya Expires December 3, 2005 [Page 8]
Internet-Draft AAA-Key Binding Jun 2005
5. Validating Key Binding Blob
As described in Section 3.1, the level of trust relationship between
an EAP authenticator and an EAP server may vary depending on the
deployment. When there is a full level of trust relationship between
the EAP authenticator and EAP server, the EAP server can trust
information sent by the EAP authenticator and thus it is not
necessary for the EAP server to verify the EAP lower-layer parameters
encoded in the key-binding-blob.
On the other hand, when there is not a full level of trust
relationship between the EAP authenticator and EAP server, the EAP
server may not fully trust information sent by the EAP authenticator
and thus it would need to verify the EAP lower-layer parameters
encoded in the key-binding-blob. The verification of the key-
binding-blob can be performed based on simple string comparison with
the expected value that may be pre-configured on the EAP server,
meaning that the EAP server would need to know the structure and
semantics of the key-binding-blob when the key-binding-blob is pre-
configured. However, the EAP server can still be agnostic to the
structure and semantics of the key-binding-blob during the execution
of the verification procedure.
Ohba & Yanagiya Expires December 3, 2005 [Page 9]
Internet-Draft AAA-Key Binding Jun 2005
6. 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, a key-binding-blob is carried in a AAA protocol. 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
one or more RADIUS Key-Binding-Blob attribute to a corresponding
Diameter AVP and vise versa. The Key-Binding-Blob attribute MUST NOT
be modified by an intermediary AAA node such as a AAA proxy.
Considering that the maximum size of a RADIUS attribute value is 253
octets and that the size of the key-binding-blob can exceed 253
octets, the Key-Binding-Blob attribute is defined to allow
fragmentation in the following way.
When the size of the key-binding-blob is X octets (X>0) and RADIUS is
used for carrying the key-binding-blob, the key-binding-blob is split
into (X div 253) octet-strings, where each octet-string is carried in
a separate RADIUS Key-Binding-Blob attribute with a distinct fragment
identifier (Fragment ID) which starts from zero (0) and incremented
by one (1). A Key-Binding-Blob attribute also has a flag (L-flag) to
indicate the last fragment. The L-flag MUST be set for a Key-
Binding-Blob attribute carrying the last fragment, otherwise it MUST
be unset.
When Diameter is used for carrying the key-binding-blob, the entire
key-binding-blob is carried in a single Key-Binding-Blob AVP, with
the L-flag set and the Fragment ID set to zero (0).
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 |L| Fragment ID | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD
Represents Key-Binding-Blob.
Length: >=4
L(ast flagment):
Ohba & Yanagiya Expires December 3, 2005 [Page 10]
Internet-Draft AAA-Key Binding Jun 2005
Indicates whether this is the last fragment. If there is only one
fragment, the L-flag MUST be set.
Fragment ID:
Fragment identifier used for identifying a fragment of a key-
binding-blob. The identifier starts from zero (0) and incremented
by one (1).
String:
Contains a fragment of a key-binding-blob.
Ohba & Yanagiya Expires December 3, 2005 [Page 11]
Internet-Draft AAA-Key Binding Jun 2005
7. Co-existence with Legacy AAA-Key Derivation Algorithm
The following consideration is needed in order to interwork with EAP
lower layers that use the legacy AAA-Key derivation algorithm (i.e.,
AAA-Key=MSK(0,63) [I-D.ietf-eap-keying]) instead of the algorithm
described in Section 4.2.
An EAP authenticator for an EAP lower layer using the legacy AAA-Key
derivation algorithm is allowed to not send a key-binding-blob to the
EAP server. If an EAP authenticator does not send a key-binding-blob
to the EAP server, and the EAP server is configured to use the legacy
AAA-Key derivation algorithm for the EAP authenticator, a AAA-Key is
derived based on the algorithm described in [I-D.ietf-eap-keying].
If an EAP authenticator does not send a key-binding-blob to the EAP
server and the EAP server is configured to use the AAA-Key derivation
algorithm described in Section 4.2 for the EAP authenticator, the
authentication procedure MUST fail. If an EAP authenticator sends a
key-binding-blob to the EAP server and the EAP server is configured
to use the legacy AAA-Key derivation algorithm for the EAP
authenticator, the authentication procedure MUST fail.
Ohba & Yanagiya Expires December 3, 2005 [Page 12]
Internet-Draft AAA-Key Binding Jun 2005
8. 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 the the EAP server to know about the
structure and the semantics of the key-binding-blob during the
execution of the EAP authentication. However, the EAP server may
need to identify at least the type of the EAP lower layer in order to
avoid the situation where the EAP authenticator sends a key-binding-
blob for an EAP lower layer that is different from what is expected
by the EAP server, but the content of the key-binding-blob happens to
match the expected value. How the EAP lower layer type information
is carried from the EAP authenticator to the EAP peer (e.g., carrying
it in the key-binding-blob or in the AAA-Key-name or by some other
means) is an open issue.
The solution works regardless of whether an EAP authenticator is
acting as a pass-through authenticator or not.
Although the solution requires a change in the AAA-Key derivation
algorithm described in section 2.3 of [I-D.ietf-eap-keying], the
solution can co-exist with the legacy AAA-Key derivation algorithm as
described in Section 7.
Ohba & Yanagiya Expires December 3, 2005 [Page 13]
Internet-Draft AAA-Key Binding Jun 2005
9. 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 parameter 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 & Yanagiya Expires December 3, 2005 [Page 14]
Internet-Draft AAA-Key Binding Jun 2005
10. Acknowledgments
The authors would like to thank Jari Arkko and Bernard Aboba for
discussing this issue on the EAP mailing list and giving insights.
The authors would like to thank Rafa Marin Lopez and Julien Bournelle
for reviewing the document.
Ohba & Yanagiya Expires December 3, 2005 [Page 15]
Internet-Draft AAA-Key Binding Jun 2005
11. References
11.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
11.2 Informative References
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000.
[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., "EAP IKEv2 Method (EAP-IKEv2)",
draft-tschofenig-eap-ikev2-06 (work in progress),
May 2005.
Ohba & Yanagiya Expires December 3, 2005 [Page 16]
Internet-Draft AAA-Key Binding Jun 2005
Authors' Addresses
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Mayumi Yanagiya
NTT Network service systems laboratories, NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
Email: yanagiya.mayumi@lab.ntt.co.jp
Ohba & Yanagiya Expires December 3, 2005 [Page 17]
Internet-Draft AAA-Key Binding Jun 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 & Yanagiya Expires December 3, 2005 [Page 18]
