Network Working Group Y. Ohba
Internet-Draft Toshiba
Expires: August 25, 2008 R. Lopez
University of Murcia
February 22, 2008
An EAP Method for Key Distribution Exchange for Handover Re-
authentication
draft-ohba-eap-kde-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 August 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes an EAP method used for carrying KDE (Key
Distribution Exchange) protocol for handover re-authentication. This
method carries HOKEY KDE messages. This EAP method is designed to
work with stand-alone authenticators.
Ohba & Lopez Expires August 25, 2008 [Page 1]
Internet-Draft EAP-KDE February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 4
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Bootstrapping EAP-KDE . . . . . . . . . . . . . . . . . . . . 5
5. Per-Authenticator Key, IK and CK . . . . . . . . . . . . . . . 6
6. EAP Method Attributes . . . . . . . . . . . . . . . . . . . . 7
6.1. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Server ID . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Ohba & Lopez Expires August 25, 2008 [Page 2]
Internet-Draft EAP-KDE February 2008
1. Introduction
KDE (Key Distribution Exchange) is a three-party key distribution
protocol designed for handover keying [I-D.ietf-hokey-key-mgm].
EAP-KDE is an EAP method designed for carrying KDE over EAP. This
EAP method is designed to work with stand-alone authenticators. EAP-
KDE has the following characteristics that may achieve the goals in
designing the EAP re-authentication and key management protocol
[I-D.ietf-hokey-reauth-ps].
No modification to lower layer
Since the KDE messages are encapsulated in an EAP method, no
modification to existing EAP lower layer is required.
No modification to EAP
Since the KDE messages encapsulated in an EAP method, no
modification to EAP [RFC3748] is required.
Minimum modification to AAA protocols
For this EAP method to work, some KDE messages need be exchanged
outside this EAP method between an authenticator and a KDE server.
Such KDE messages are carried over AAA protocols. Specifically,
one new AAA attribute is needed to carry KDE messages over
existing AAA protocols between an authenticator and a KDE server.
One roundtrip beyond access network
EAP-KDE requires one AAA roundtrip between authenticator and AAA
server.
Channel Binding
Since KDE cryptographically binds a session key and associated
attributes to the identity of an authenticator, EAP-KDE provides
Channel Binding property.
As observed, EAP-KDE provides the same number of roundtrips (1) as
ERP [I-D.ietf-hokey-erx] between an authenticator and an a re-
authentication server without modifying EAP.
EAP-KDE creates a new usage of KDE to distribute a per-authenticator
key from a HOKEY server to an authenticator. Therefore, EAP-KDE can
be also considered as an alternative to ERP [I-D.ietf-hokey-erx].
Ohba & Lopez Expires August 25, 2008 [Page 3]
Internet-Draft EAP-KDE February 2008
This EAP method is intended to be used for intra-domain handover
optimization in a AAA domain. A full EAP authentication with any EAP
method is still needed for initial entry of the domain.
It should be noted that a similar method-based mechanism with use of
stand-alone authenticator may be applicable to carry other
authentication and key management protocols such as Kerberos to
achieve the same goals.
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 [RFC2119].
2.1. Protocol Operation
EAP-KDE works with a stand-alone EAP authenticator that is an EAP
authenticator co-located with an EAP server supporting this EAP
method. In this protocol, an EAP peer is a KDE peer, and an EAP
authenticator is a KDE third party. The KDE server may reside in the
home AAA domain or visited AAA domain.
It is assumed that a Kps (a shared key between the peer and KDE
server) has been established using the bootstrapping mechanism
described in Section 4.
The authenticator that supports EAP-KDE method starts with the EAP-
KDE method when a peer attaches to it by sending an EAP-Request/KDE
carrying a KDE message 0 (KDE0). If the peer does not support the
method or it needs to go through a complete EAP authentication sends
a EAP-NAK. Then the authenticator can start the EAP Request/Identity
to the peer to perform a full EAP authentication using other EAP
method. On the contrary, if the peer supports EAP-KDE and wishes to
run it, it answers with EAP-Response/KDE containing a KDE message 1
(KDE1).
Once the authenticator receives KDE1, it sends a KDE message 2 (KDE2)
to the KDE server over a AAA protocol and waits for a KDE message 3
(KDE3) from the KDE server, and send an EAP-Request/KDE with a KDE
message 4 (KDE4) after receiving the KDE3. The AAA message carrying
the KDE3 also carries authorization data used for network access.
The peer returns an EAP-Request/KDE with an empty Payload in response
to the KDE3. The authenticator returns an EAP-Success. (NOTE:
Failure case is TBD.)
Ohba & Lopez Expires August 25, 2008 [Page 4]
Internet-Draft EAP-KDE February 2008
Peer Authenticator/Server KDE Server/AAA Server
<-- EAP-Request/KDE{KDE0}
--> EAP-Response/KDE{KDE1} --> AAA{KDE2}
<-- EAP-Request/KDE{KDE4} <-- AAA{KDE3, authorization data}
--> EAP-Response/KDE{}
<-- EAP-Success
Figure 1: EAP-KDE Call Flow
3. Message Format
The Code, Identifier, Length, and Type fields are described in
[RFC3748]. The EAP Type for this EAP method is [to be assigned by
IANA]. The Payload-Type field contains the type of Payload. The
optional Payload field contains data specific to Payload-Type
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 | Payload-Type | Payload (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: Message Format
Payload-Type Payload Data
0 Empty
1 KDE message
4. Bootstrapping EAP-KDE
EAP-KDE requires that the following parameters are bootstrapped from
a full EAP authentication with any EAP method that generates EMSK.
o The identity of the KDE server (KDE-SERVER-ID)
o Kps, the secret key shared between peer and the KDE server (KDE-
SERVER-KEY)
KDE-SERVER-ID is statically or dynamically configured on the peer.
DNS or DHCP may be used for dynamically discovering the
KDE-SERVER-ID.
Kps (KDE-SERVER-KEY) is derived from EMSK (EAP Master Session Key) as
Ohba & Lopez Expires August 25, 2008 [Page 5]
Internet-Draft EAP-KDE February 2008
a USRK (Usage Specific Root Key) [I-D.ietf-hokey-emsk-hierarchy] as
follows, where USRK denotes the USRK key derivation function defined
in [I-D.ietf-hokey-emsk-hierarchy] where the key label, optional data
and key length are specified in the first, second and third
parameter, respectively.
Kps = USRK(key-label="kde-boot-key@ietf.org", op-data=KDE-SERVER-ID, length).
The name of the Kps (Kps-Name) is the USRK name of this key.
The KDE server may reside in the home domain or visited domain. If
the KDE server resides in the home domain, it is assumed that the KDE
server is implemented on the same node as the EAP server for the
initial EAP authentication. Hence, no protocol is needed for
distributing the KDE-SERVER-KEY. If the KDE server resides in the
visited domain, it is implemented on a AAA proxy server in the
visited domain. The KDE-SERVER-KEY is distributed from the home
domain using HOKEY KDE over UDP. Also, the AAA proxy is expected to
store the authorization data obtained from the home AAA server during
the full EAP authentication performed at the time of initial entry of
the visited domain so that the authorization data is associated with
the KDE-SERVER-KEY and subsequent EAP-KDE runs once EAP-KDE is
bootstrapped in the visited domain.
5. Per-Authenticator Key, IK and CK
Kpt, the session key established between the peer and authenticator
is derived from Kps as follows, where KDF denotes a key derivation
function defined in [I-D.ietf-hokey-emsk-hierarchy] and length
denotes the length of the derived key. The default PRF is used for
derivation of Kpt. The key-label is
"kde-per-authenticator-key@ietf.org". The op-data is SEQps of KDE in
network byte order.
Kpt = KDF(Kps, key-label + "\0" + op-data + length).
key-label: "kde-per-authenticator-key@ietf.org"
op-data: SEQps
The name of the Kpt (Kpt-Name) is defined as SHA-1-64(Kps-Name + key-
label + op-data) where where SHA-1-64 is the first 64-octet of SHA-1.
IK and CK, the integrity key and encryption key to protect KDE1 and
KDE4 between the peer and KDE server, respectively, are derived using
the Kps as the KDRK.
Ohba & Lopez Expires August 25, 2008 [Page 6]
Internet-Draft EAP-KDE February 2008
6. EAP Method Attributes
6.1. MSK and EMSK
A set of 64-octet MSK and 64-octet EMSK to be exported from EAP-KDE
is derived from Kpt, the KDE session key established between the peer
and stand-alone authenticator as follows. MSK is the first 64-octet
of Kpt. EMSK is the next 64-octet of Kpt. The length of Kpt MUST be
at least 128-octet.
6.2. Server ID
TID (Third party identifier) of KDE is used as the Server ID of this
EAP method.
7. Security Considerations
The EAP-KDE method transports KDE protocol describe in
[I-D.ietf-hokey-key-mgm]. The KDE protocol is a 3-party key
distribution protocol. The security of EAP-KDE mainly depends on the
security of KDE protocol. Security Claims for this EAP method is
provided below.
Auth. mechanism: Pre-shared keys.
Ciphersuite negotiation: No
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: No
Key derivation: Yes
Key strength: min(128, Kpt strength)
Dictionary attack prot.: N/A
Fast reconnect: Yes
Crypt. binding: N/A
Session independence: Yes
Fragmentation: TBD
Channel binding: Yes
Protected ciphersuite negotiation
EAP-KDE does not support ciphercuite negotiation.
Mutual authentication
EAP-KDE transports KDE protocol which provides peer authentication
in KDE0 message and server authentication in message KDE4.
Ohba & Lopez Expires August 25, 2008 [Page 7]
Internet-Draft EAP-KDE February 2008
Integrity protection
EAP-KDE is a mere carrier of KDE protocol, which is integrity
protected. Therefore, this property is applied to the Payload
field but not to the whole EAP message.
Replay protection
KDE protocol transported by EAP-KDE provides replay protection.
Additionally, peer receives a success result indication when
receiving KDE4 message.
Confidentiality
EAP-KDE does not provide confidentiality.
Key derivation
EAP-KDE derives a MSK (64 bytes) and EMSK (64 bytes) from session
key Kpt distributed by KDE.
Key strength
The distributed key Kpt shall have at least 128 octets. From that
key, EAP-KDE derives 64 bytes MSK and 64 bytes EMSK. (see
Section 6.1). The key strength of exported keying material
depends on the strength of Kpt.
Dictionary attack resistance
No password authentication is used.
Fast reconnect
EAP-KDE use KDE protocol that provides a fast reconnect feature by
itself. In fact, KDE uses the cryptographic material exported
from a previous full EAP authentication.
Cryptographic binding
Since EAP-KDE does not tunnel another EAP method, it does not
implement cryptographic binding.
Session independence
Each time EAP-KDE is performed a new fresh per-authenticator key
(Kpt) is derived. Since MSK and EMSK are derived from the new
Kpt, they shall be also fresh keys.
Ohba & Lopez Expires August 25, 2008 [Page 8]
Internet-Draft EAP-KDE February 2008
Fragmentation
TBD.
Channel binding
Since KDE is a three-party key distribution protocol it
cryptographically binds a session key and associated attributes to
the identity of an authenticator, EAP-KDE provides this property.
8. IANA consideration
EAP-KDE requires a new EAP Type value assigned by IANA.
EAP-KDE requires a new namespace for EAP-KDE Payload-Type field
managed by IANA. This document uses two Payload-Type values 0
(Empty) and 1 (KDE message).
EAP-KDE requires a new KDE Key Type values 3 (EAP-KDE KDE Server Key)
and 4 (EAP-KDE Per-Authenticator Key) assigned by IANA.
EAP-KDE requires two new USRK key label values
"kde-boot-key@ietf.org" and "kde-per-authenticator-key@ietf.org"
assigned by IANA.
9. Acknowledgements
TBD.
10. References
10.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.
[I-D.ietf-hokey-key-mgm]
Nakhjiri, M. and Y. Ohba, "Derivation, delivery and
management of EAP based keys for handover and re-
authentication", draft-ietf-hokey-key-mgm-02 (work in
progress), January 2008.
Ohba & Lopez Expires August 25, 2008 [Page 9]
Internet-Draft EAP-KDE February 2008
[I-D.ietf-hokey-emsk-hierarchy]
Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)",
draft-ietf-hokey-emsk-hierarchy-03 (work in progress),
January 2008.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
10.2. Informative references
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[I-D.ietf-hokey-reauth-ps]
Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-authentication Problem
Statement", draft-ietf-hokey-reauth-ps-08 (work in
progress), February 2008.
[I-D.ietf-hokey-erx]
Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
authentication Protocol (ERP)", draft-ietf-hokey-erx-11
(work in progress), February 2008.
Authors' Addresses
Yoshihiro Ohba
Toshiba
Email: yohba@tari.toshiba.com
Rafael Marin Lopez
University of Murcia
Email: rafa@um.es
Ohba & Lopez Expires August 25, 2008 [Page 10]
Internet-Draft EAP-KDE February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ohba & Lopez Expires August 25, 2008 [Page 11]