One document matched: draft-ohba-hokey-3party-keydist-ps-00.txt
Network Working Group D. Harkins
Internet-Draft Tropos Networks
Expires: August 30, 2007 Y. Ohba
Toshiba
M. Nakhjiri
Huawei
February 26, 2007
Problem Statement and Requirements on a 3-Party Key Distribution
Protocol for Handover Keying
draft-ohba-hokey-3party-keydist-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 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Harkins, et al. Expires August 30, 2007 [Page 1]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
Abstract
The HOKEY WG is developing solutions for optimizations as well as
security key hierarchy specifications for handovers. The key
derivation specifications all draw from a trust relationship that is
created as a result of a "2-party" EAP authentication between a peer
and a backend server, while distributing the resulting keys to third
parties other than the peer and the backend server. This document
describes problem statement and requirements on a three-party key
distribution protocol for handover keyings.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Harkins, et al. Expires August 30, 2007 [Page 2]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
1. Introduction
The HOKEY (Handover Keying) WG is specifying solutions for secure
handover optimization relating to EAP (Extensible Authentication
Protocol) [RFC3748]. The optimization solutions under considerations
can for instance be categorized based on timing: The authentication
and key management may occur before handoff, or alternatively,
authentication and key management can occur as part of the handoff.
Furthermore, HOKEY is specifying key derivation mechanisms that can
be applied to generic use cases. All of these key derviation
mechanisms have one thing in common; from security standpoint, the
solutions have one thing in common: they draw from a trust
relationship that is created as a result of a "2-party" EAP
authentication between a peer and a backend server. On the other
hand, the key management solutions are distributing the resulting
keys to the third parties other than the initial peer and the backend
server. This means the key distribution mechanism and protocol,
unlike the initial authentication, involves 3 parties.
This document describes problem statement and requirements on such
three-party key distribution protocols used for handover and other
keying applications.
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].
Harkins, et al. Expires August 30, 2007 [Page 3]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
2. Problem Statement
Network access authentication and authorization services have been
based on two-party trust model (long term credentials established
between a backend AAA server and an end client) under the assumption
that the access client and the authentication server (EAP/AAA server)
mutually authenticate, using a two-party protocol. Initially a
network point of presence (e.g. a dial up modem up) performed the
role of authentication server end-client and thus this point of
presence was denoted as Network Access Server (NAS). This was a
truely two party protocol.
Eventually authentication and authorization services were then
extended to be more scalable by separating the authentication
database from the NAS. In the extended model, credentials of access
clients are moved from the NAS to a centralized authentication server
and a AAA (Authentication, Authorization and Accounting) protocol is
used for communication between the NAS and the authentication server.
This extension was designed to be transparent to the access clients.
Now the NAS and authentication server are no longer one. The network
point of presence typically provides conditional connectivity to the
end client while the client and the backend server perfrom the
authentication.
+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP |------------------------------| EAP/AAA |
| Peer | | Server |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+-+
| NAS |
+-+-+-+-+
Not a party in EAP authentication
Figure 1: 2-party authentication between EAP peer and EAP server
The NAS (Network Access Server) has no part in determining the result
of the authentication and thus this transparency is frequently argued
[GZ]: the original two-party trust model remains the same. That is,
even though there are three distinct entities in this transaction the
two-party trust model can still be used.
When the EAP authentication framework is extended to also perform key
management, the initial two parties (the peer and the EAP server)
both calculate the so called Master Session Key (MSK) and Extended
Master Session Key (EMSK) based on the recently acquired state
resulting from a successful EAP authentication. However, given that
the NAS had no part in the EAP authentication, it cannot generate the
Harkins, et al. Expires August 30, 2007 [Page 4]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
same keying material. On the other hand, the goal of the EAP keying
framework is to bootstrap a security association for the peer
connectivity to the network through the very same NAS. This means
either of the two initial parties must transfer the keying material
resulted from the EAP authentication to the NAS. Given the
assumption that the NAS is a trusted part of the network controlled
by the Authentication server, it is typically the authentication
server that distributes the keying material resulted from the EAP
authentication to the NAS. Thus the key distribution mechanism
governing the network connectivity security bootstrapping is now a
true 3-party mechanism.
+-+-+-+-+ +-+-+-+-+-+
| | shared MSK, EMSK | |
| EAP |------------------------------| EAP/AAA |
| Peer |\ /| Server |
+-+-+-+-+ \ / +-+-+-+-+-+
\--------+-+-+-+-+ ------/
| NAS | transported key
+-+-+-+-+
Figure 2: 3-party key distribution involving the NAS
Problems with using a two-party trust model on this transaction have
been noted [RFC3748] and are generally referred to as a problem with
"Channel Binding". Basically the access peer infers the identity of
the authenticator but has no direct indication of the identity of the
entity to whom the authentication server transmitted the keying
material. In other words, in an unintended situation, when a NAS is
impersonating another NAS, the peer and the authentication server may
have two different view of the NAS identity. A comprehensive
solution to this problem has not been attempted, though, since the
fallout from an attack is contained. The key sent by the
authentication server to the NAS-- the MSK (Master Session Key)--
will be the same whether the NAS impersonates another NAS or not
[I-D.ietf-eap-keying]. A re-authentication between the access client
and the authentication server (possibly as part a handoff from one
NAS to another) can somewhat limit exposure of the problem, however,
it does not solve the problem completely, since potentially the lying
NAS can impersonate the new NAS as well. This although difficult
from the access link side, can be easier from the network side, when
for instance a compromised AAA proxy is on the path between both of
the NASes and the authentication server, and can observe both the EAP
signaling and the AAA signaling carrying the keying material.
Handover keying involves transmission of other keying material in a
protocol involving three parties-- the access peer, a HOKEY server
Harkins, et al. Expires August 30, 2007 [Page 5]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
and an authenticator to which a handover will be performed. In a
roaming scenario, the three main parties are: the access peer, the
HOKEY server in a home domain, and a HOKEY server in a visited
domain. The problem seems to stem from the fact that the transferred
keying material is not properly scoped and the key scope is not
properly enforced. Keying material with a specific scope (intended
parties to share the key) will be made available to another entity,
and problems arise when the peer does not have a direct indication of
the identity of that entity. An impersonation attack could result in
keying material for one scope bound to one entity being delivered to
another entity outside that scope. Obviously, the two-party trust
model is not applicable to the handover keying case.
Harkins, et al. Expires August 30, 2007 [Page 6]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
3. Requirements
Basic requirements on a 3-party key distribution protocol for
handover keying is listed below.
1. Confidentiality -- disclosure of the keying material to passive
and active attackers of the key distribution protocol MUST NOT be
possible.
2. Integrity protection -- it MUST be possible to detect tampering
of a network access credential.
3. Message authentication -- the recipient of a network access
credential MUST be able to prove who it came from and for what
context the credential was delivered.
4. Validation of authorization -- the scope (intended users) of the
network access credential MUST be distributed as part of the
credential and MUST be protected to the same degree as the
credential itself. The context (life time, labels, intended
usage, etc) of the network access credentials MUST be distributed
as part of the credentials and MUST be protected to the same
degree.
5. Resilience -- It MUST NOT be possible for an active attacker to
consent of the client.
6. Peer consent -- Either the credential MUST NOT be distributed
without the consent of the client or it MUST be unusable without
the consent of the client.
7. Peer Entity Authentication -- Identities of the three parties
involved MUST be confirmed by all three parties.
8. Agreement by all parties -- If the protocol successfully
completes all three parties MUST agree on the keying material
disclosed and the identity of the entity to whom the keying
material was disclosed.
Harkins, et al. Expires August 30, 2007 [Page 7]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
4. Security Considerations
This memo discusses basic requirements to secure the distribution of
keying material in HOKEY. Security requirements are placed on the
key distribution protocol itself and not on the transport used to
distribute the keying material. A compliant implementation SHOULD be
able to run over any transport.
Harkins, et al. Expires August 30, 2007 [Page 8]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
5. IANA Considerations
There are no IANA related issues in this document.
Harkins, et al. Expires August 30, 2007 [Page 9]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
6. Acknowledgments
Harkins, et al. Expires August 30, 2007 [Page 10]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[GZ] Zorn, G., "Email communication on HOKEY mailing list",
February 2007.
[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-18 (work in
progress), February 2007.
Harkins, et al. Expires August 30, 2007 [Page 11]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
Authors' Addresses
Dan Harkins
Tropos Networks
555 Del Rey avenue
Sunnyvale, CA 94085
USA
Phone: +1 408 470 7372
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Madjid Nakhjiri
Huawei USA
Harkins, et al. Expires August 30, 2007 [Page 12]
Internet-Draft 3-Party Key Dist. Problem Statement February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Harkins, et al. Expires August 30, 2007 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 01:08:02 |