Internet DRAFT - draft-chowdhury-hoakey-amsk-ps
draft-chowdhury-hoakey-amsk-ps
Network Working Group K. Chowdhury
Internet-Draft Starent Networks
Expires: August 9, 2006 J. Bournelle
GET/INT
M. Nakhjiri
Motorola
February 5, 2006
Problem Statement for the AMSK
draft-chowdhury-hoakey-amsk-ps-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 August 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Network operators offer multiple services ranging from basic network
access level service to application level service. Each of these
services require independent authentication and authorization steps.
Depending on the number of services and the scale of these networks,
the need for multiple levels of authentication and authorization
Chowdhury, et al. Expires August 9, 2006 [Page 1]
Internet-Draft AMSK PS February 2006
phases not only makes the operation complex, but it increases network
load and session setup latency. This document summarizes the related
problem scenarios. The goal is to address these problem scenarios
with a solution based on the EAP keying framework.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. EAP Keying Framework . . . . . . . . . . . . . . . . . . . . . 4
4. The Application Master Session Key . . . . . . . . . . . . . . 4
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
6. Example Deployment Scenarios . . . . . . . . . . . . . . . . . 5
6.1 The Scenario Without a Key Holder . . . . . . . . . . . . 5
6.2 The Scenario Withh a Key Holder . . . . . . . . . . . . . 6
7. Security considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Chowdhury, et al. Expires August 9, 2006 [Page 2]
Internet-Draft AMSK PS February 2006
1. Terminology
The keywords "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].
Most of the terms used in this document are extracted from the EAP
Keying Framework Document [I-D.ietf-eap-keying] and the AAA-Key based
keying for Wireless Handover Problem Statement Document
[I-D.nakhjiri-aaa-hokey-ps]. The terms used in this document are
(re-)stated below for better readability:
AAA server: The entity that is the main point of trust and
authorization in the user's administrative domain. It maintains
peer information and possibly keying information. The AAA server
relies on the EAP server to authenticate its clients and to obtain
keying materials.
EAP server: The EAP server terminates the EAP authentication method
with the EAP client through a pass-through authenticator and can
derive Master Session Key (MSK, EMSK, AMSK) as defined in
[I-D.ietf-eap-keying].
Key Holder: This entity is the one that holds root key/s for key
derivation process. This entity may need to have AAA client
functionality if it receives keying material form a AAA server.
Mobile Node (MN) (peer): The entity that queries for network access
and for IP-based services. It acts as an EAP peer functionality
as described in [RFC3748] and [I-D.ietf-eap-keying].
2. Introduction
EAP is being adopted as a generic authentication framework by
different SDOs like 3GPP2 and WiMAX. In general EAP is used to
authenticate the device and the user for network access service.
Beyond that, EAP may also be used to setup security associations for
various services ranging from mobility services to application level
services. Often this involves multiple EAP transactions with
different EAP authenticators.
The goal of this document is to define the problem with the need to
run EAP several times to obtain services. The intent is also to show
that the EAP keying framework may be leveraged to standardize a key
derivation and distribution scheme for multiple service agents in a
network.
Chowdhury, et al. Expires August 9, 2006 [Page 3]
Internet-Draft AMSK PS February 2006
3. EAP Keying Framework
The EAP server authenticates the EAP peer based on long term
credentials. Some of the EAP authentication methods are able to
derive some keying materials from these credentials. The document
[I-D.ietf-eap-keying] explains the EAP keying management framework.
It details the generation, the transport and the usage of the keying
materials generated by EAP methods.
Specifically, the EAP method used at EAP peer and server derives the
Master Session Key (MSK) and the Extended Master Session Key (EMSK).
Please refer to [I-D.ietf-eap-keying] for more details.
4. The Application Master Session Key
The current EAP Key management framework does not explain the purpose
of the EMSK. However, the document [aboba-keying-exts] proposes to
use it to derive Application Master Session Keys (AMSKs). These
AMSKs could be used for extended use.
The idea behind AMSK is that the AAA server requests the EAP AMSK key
derivation function (KDF) to derive an AMSK per specific application.
An AMSK is then derived from the EMSK, an application data label,
optional application data and output length. This key is then
exported to the AAA layer.
AMSK = KDF(EMSK, key label, optional application data, length)
This root AMSK is thus available both at the EAP peer and at the EAP/
AAA server.
5. Problem Statement
In a typical IP network, the users may access various services
offered by the operator. Each of these services normally require
authentication and authorization steps. Hence multiple runs of EAP
is very likely in today's networks. In most of the cases, the EAP is
run between the same peer and EAP server via the same AAA server.
Even same root key is be used often times for these EAP transactions.
This increases network load unnecessarily and it also increases
session setup delay.
The EAP-keying framework could be enhanced to derive shared secrets
(keys) for the service access based on a single EAP transaction
during the network access authentication and authorization.
Here is an example scenario with network, mobility and service access
(via SIP) as an illustration of the problem:
Chowdhury, et al. Expires August 9, 2006 [Page 4]
Internet-Draft AMSK PS February 2006
+------+ +------+ +------+ +------+ +------+
| MN/ | | AN | | HA | | SIP- | | AAA/ |
| EAPP | | | | | |Server| | EAPS |
+------+ +------+ +------+ +------+ +------+
| | | | |
|<---net-access------------------------------------------------>| EAP-1
| | | | |
| | | | |
| | | | |
|<----mobility access/IKE----->|<------------------------------>| EAP-2
| | | | |
| | | | |
| | | | |
|<--------Service Registration/IPsec-SA------->|<-------------->| EAP-3
Figure 1: Example Service Access Scenario
As seen in (cf. Figure 1), the MN (EAPP: EAP Peer) has to perform
multiple EAP transactions with the EAPS: EAP Server to establish SA
between it and the various authenticators in the IP network. In a
large network, these authenticators may all be located in the same
administrative domain. However, there is no mechanism defined today
that will allow integration of these authentication steps via a
single EAP exchange.
Considering this example, the first EAP authentication (EAP-1) could
be used to derive some keying materials for the others services. For
example, EAP-1 could be used to derive and distribute a master
session key: (x)MSK to a Key Holder in the network [I-D.nakhjiri-aaa-
hokey-ps] and later used to establish SAs for various applications/
services the MN wants to access.
6. Example Deployment Scenarios
Operators deploy networks to offer multiple services. However, there
is no framework in place that will allow the operators to offer
single-sign-on type of access to their users for the services based
on user profile. The need for multiple EAP transactions to
authenticate and authorize each service access one-by-one not only
slows down the service access process, but also increase signaling
overhead on the network and degrade user experience.
6.1 The Scenario Without a Key Holder
A possible scenario would be that the AAA server (collocated with
the EAP server), based on the user's profiles, determines the
services to which the MN may access (e.g. Mobile IPv6, NEMO, SIP,
Chowdhury, et al. Expires August 9, 2006 [Page 5]
Internet-Draft AMSK PS February 2006
etc). From this, it may proactively or reactively derive and
distributes keys to the service nodes. These keys being derivated
from AMSKs.
This model is shown below:
+------------+
| EAPS/ |
| AAA |
+------------+
^ ^ ^
/ | \
key-1 / key-2| \key-3
/ | \
V V V
Service Service Service
Node-1 Node-2 Node-3
Figure 2: Service Key Provisioning without a Key Holder
In the proactive case, the AAA/EAP server derives and distributes
keys to Service Nodes in the access network. These Services Nodes
provide various services to the user. When a Service Node receives
service (or registration) request from the MN, it can process the
request without having to fetch the associated key(s) from the AAA/
EAP server.
In the reactive case, upon receiving service requests from the MN the
Service Node contact the AAA/EAP server in order to get the key to be
used to process the service request from the MN. For this, it sends
a message containing its identity, the service requested and an
identifier for the MN. Others information may also be needed.
In either case, the MN must derive and hold the same key(s)
corresponding to each Service.
6.2 The Scenario Withh a Key Holder
An EAP pass-through authenticator is typically an edge device that
may not be trusted enough for caching master keys for a lot of
network applications that may have agents in both the visited network
(including authenticator) and the home network (including AAA
server). The authenticator may not be allowed to cache keys either
(per EAP-keying requirements). For this reason, the document
[I-D.nakhjiri-aaa-hokey-ps] introduces the entity Key Holder (KH)
that will have proper trust relationship and secure channels running
Chowdhury, et al. Expires August 9, 2006 [Page 6]
Internet-Draft AMSK PS February 2006
into and out of it for transport, caching, and management of keys.
In this section, we show how this entity could be used instead of
direct interaction with the AAA/EAP server.
The key holder holds the AMSKs received during the network access by
the user. These AMSKs are sent by the AAA server to the Key Holder.
The key holder can either distribute the (derived) keys to the
appropriate service nodes or it can wait for the service nodes to
request for the specific keys. This possible model is shown below:
+-------+
| EAPS/ |
| AAA |
+-------+
|
| (SID1-AMSK1,
| SID2-AMSK2,
| SID3-AMSK3)
|
V
+-------------+
| KH |
+-------------+
^ ^ ^
/ | \
key-1 / key-2| \key-3
/ | \
V V V
Service Service Service
Node-1 Node-2 Node-3
Figure 3: scenario-1: Service Key Provisioning using a Key Holder
In the Proactive scenario, the Key Holder receives keys to be used
with corresponding services (SID1-AMSK1, SID2-AMSK2 and SID3-AMSK3)
from the AAA /EAP server. In this example the KH distributes these
three keys (or keys derived from the AMSKs) to the service nodes
corresponding to the services all at the same time.
In the reactive scenario, the user attempts to access (e.g. Mobile
IP registration) a service. The Service node makes a request for a
shared secret from the Key Holder. In the request, the service node
Chowdhury, et al. Expires August 9, 2006 [Page 7]
Internet-Draft AMSK PS February 2006
includes the Service Identifier (SID) and other relevant information
(TBD). The KH returns the appropriate key(s) to the service node.
Note that unlike in the proactive mode, these transactions take place
at different times based on the service initiation by the user.
7. Security considerations
The solution framework must address all the security issues related
to:
1. Transportation of the keys and/or keying material between the
required entities must be secure (confidentiality, integrity
protection, authentication).
2. The distributed keys and keying materials must have associated
lifetimes. The lifetime of key-0 must be longer than that of the
derived keys (key-x).
3. The solution must include provisions for re-keying the derived
keys. The solution must also address transport issues after re-
keying.
8. IANA Considerations
None
9. Acknowledgements
TBD
10. Informative References
[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-09 (work in
progress), January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work
in progress), January 2006.
[aboba-keying-exts]
Chowdhury, et al. Expires August 9, 2006 [Page 8]
Internet-Draft AMSK PS February 2006
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Extensions",
draft-aboba-eap-keying-extns-00.txt (expired), April 2005.
Authors' Addresses
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury MA 01876
US
Email: kchowdhury@starentnetworks.com
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
Madjid Nakhjiri
Motorola
Email: Madjid.nakhjiri@motorola.com
Chowdhury, et al. Expires August 9, 2006 [Page 9]
Internet-Draft AMSK PS February 2006
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 (2006). 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.
Chowdhury, et al. Expires August 9, 2006 [Page 10]
Internet-Draft AMSK PS February 2006
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chowdhury, et al. Expires August 9, 2006 [Page 11]
