Network Working Group D. Harkins
Internet-Draft Tropos Networks
Expires: September 5, 2007 Y. Ohba
Toshiba
M. Nakhjiri
Huawei
R. Lopez
Univ. of Murcia
March 4, 2007
Problem Statement and Requirements on a 3-Party Key Distribution
Protocol for Handover Keying
draft-ohba-hokey-3party-keydist-ps-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 September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Harkins, et al. Expires September 5, 2007 [Page 1]
Internet-Draft 3-Party Key Dist. Problem Statement March 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. Solution Framework for HOKEY 3-Party Key Distribution
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Candidate 3-Party Key Distribution Protocols . . . . . . . 9
4.3.1. Kerberos Protocol . . . . . . . . . . . . . . . . . . 9
4.3.2. ISO/IEC 11770-2 Key Establishment Mechanism 10 . . . . 9
4.3.3. An Improved Provably Secure 3PKD protocol . . . . . . 10
4.3.4. Dan Harkins' protocol (tentative) . . . . . . . . . . 10
4.4. Candidate Key Distribution Transport Protocols . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Protocols not being considered as candidates due
to known flaws . . . . . . . . . . . . . . . . . . . 16
Appendix A.1. Otway-Rees . . . . . . . . . . . . . . . . . . . . . 16
Appendix A.2. Wide Mouth Frog . . . . . . . . . . . . . . . . . . 16
Appendix A.3. Needham-Schroeder Shared Key Protocol . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Harkins, et al. Expires September 5, 2007 [Page 2]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
1. Introduction
This is my time tabe for the week:
Monday to Friday working
Saturday and Sunday working
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 derivation
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 September 5, 2007 [Page 3]
Internet-Draft 3-Party Key Dist. Problem Statement March 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 perform 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 September 5, 2007 [Page 4]
Internet-Draft 3-Party Key Dist. Problem Statement March 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 September 5, 2007 [Page 5]
Internet-Draft 3-Party Key Dist. Problem Statement March 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 September 5, 2007 [Page 6]
Internet-Draft 3-Party Key Dist. Problem Statement March 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. Validation of credential source -- 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. Verification of identity -- 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.
9. Replay protection -- replay attacks MUST NOT effect the key
distribution protocol.
Harkins, et al. Expires September 5, 2007 [Page 7]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
4. Solution Framework for HOKEY 3-Party Key Distribution Protocol
Following, we present two different main cases that need to be
considered in the handover keying problem.
4.1. Use Cases
Use Case 1 principals: EAP peer, HOKEY server and EAP server
In this scenario, the HOKEY server is not co-located with the EAP
server. That is, the EAP server and HOKEY server are considered
as two completely different parties. The 3-Party Key Distribution
protocol is aimed for distributing a shared key Kab between the
HOKEY peer and HOKEY server where the EAP server is acting as
server distributing the session key Kab.
Use Case 2 principals: EAP peer, authenticator and HOKEY server
In this scenario, the HOKEY peer and the HOKEY server already owns
a shared secret Kas (e.g. the HOKEY server is the EAP server).
The 3-Party Key Distribution protocol is aimed for distributing a
shared key Kab between the HOKEY peer and the authenticator where
the HOKEY server is acting as server distributing the Kab. Note
that when HOKEY peer and HOKEY server do not share any key, Case 1
needs to be performed before going through Case 2.
4.2. Notation
A: HOKEY client in both Use Cases 1 and 2
B: HOKEY server in Use Case 1 or Authenticator in Use Case 2
S: EAP server in Use Case 1 or HOKEY server in Use Case 2
{X}K: X encrypted with key K
[X]K: Message Authentication Code of X with key K.
H(x): Digest produced from a one-way hash function given x as input
x|y: Concatenation of x and y
Kas: A symmetric key shared between A and S
Kbs: A symmetric key shared between B and S
Kab: A symmetric key to be shared between A and B
L : Key lifetime for Kab
Tx : Timestamp generated by the party X
Nx : Nonce provided by the party X
Harkins, et al. Expires September 5, 2007 [Page 8]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
4.3. Candidate 3-Party Key Distribution Protocols
We present a set of candidate 3-Party Key Distribution protocols that
may be considered suitable for deploying a handover keying solution.
Note that there are other protocols that may be well considered as
candidates [prot-auth]. Note also that, in this version of document
no verification has been made as to whether the candidate protocols
satisfy the requirements listed in Section 3.
It is assumed for all candidate protocols that when Kab is encrypted
in a message, authorization attributes associated with Kab are also
encrypted together. However, the authorization attributes are not
shown in the diagram of each candidate protocol.
4.3.1. Kerberos Protocol
1) A->S: A, B
2) S->A: {Ts, L, Kab, B, {Ts, L, Kab, A}Kbs}Kas
3) A->B: {Ts, L, Kab, A}Kbs, {A, Ta}Kab
4) B->A: {Ta+1}Kab
Kerberos protocol is based on Needham-Schroeder protocol but
following the recommendations given by Denning and Sacco [ds-time].
That is, they use timestamps to avoid replay attacks. Additionally,
S includes a lifetime L associated to the distributed key Kab. The
last message 4 allows mutual authentication between A and B and it is
optional. In Kerberos v5, Ta+1 in the 4-th message is replaced with
Ta and other information [RFC4120].
Additionally, Kerberos allows the client A to obtain an initial
ticket to access a Ticket Granting Service (TGS) without requiring
the user to re-entry the password. That initial ticket allows the
client A to start a Kerberos negotiation with TGS to obtain another
ticket for accessing the service B.
By using this approach, Kerberos also allows a cross-realm operation
where A can recover a ticket from a remote TGS (in A's Home Domain)
to access a local TGS (in the visited domain).
However, Kerberos requires time synchronization among the three
parties.
4.3.2. ISO/IEC 11770-2 Key Establishment Mechanism 10
1) A->S: {Ta,B}Kas
2) S->A: {Ts,Kab,B}Kas
3) S->B: {Ts',Kab,A}Kbs
Harkins, et al. Expires September 5, 2007 [Page 9]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
This protocol has an interesting feature because it allows S to
verify the authenticity and freshness of the first message before
starting the key distribution process. The protocol requires that
time synchronization among the three entities.
4.3.3. An Improved Provably Secure 3PKD protocol
1) A->B: Na
2) B->S: Na,Nb
3a) S->A: {Kab}Kas,[A,B,Na,Nb,Ns,{Kab}Kas]Kas,Nb
3b) S->B: {Kab}Kbs,[A,B,Na,Nb,Ns,{Kab}Kbs]Kbs
The original protocol 3PKD was proposed by Bellare and Rogaway in
[3pkd]. However, Choo et al. presented a small modification to the
protocol by adding the value Nb and a nonce generated by the server S
(Ns) which avoids A and B to accept two different session keys (e.g.
Kab, Kab') for the same session [3pkd-choo].
Basically, with the inclusion of Ns, the protocol defines as session
formed by the 3-tuple (Na,Nb,Ns). However as we may see the protocol
does not consider mutual authentication.
4.3.4. Dan Harkins' protocol (tentative)
1) A->B: A, {A, B, Na}Kas
2) B->S: A, B, {Nb}Kbs, {A, B, Na}Kas
3) S->B: {Na, Nt, B}Kas, {A, Na, Nb, Nt, Kab}Kbs
4) B->A: {Na, Nt, B}Kas, H(Na|Nt)
In this protocol, A and B derive Kab from Kas using the same key
derivation function. Therefore, there is no need to carry Kab in
message 4.
4.4. Candidate Key Distribution Transport Protocols
The protocols presented in Section 4.3 are independent on the
protocol used to transport the different messages exchanged among the
the principals.
Several alternatives are identified as transport protocols for a
3-party key distribution protocol. This version of document does not
make any recommendation on a specific transport protocol.
o Lower-layer specific transport (e.g., new link-layer management
frames and new AAA attributes). The HOKEY scope limits the
definition of the lower-layer to an IP protocol
Harkins, et al. Expires September 5, 2007 [Page 10]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
o New EAP Code
o New EAP Method
Harkins, et al. Expires September 5, 2007 [Page 11]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
5. 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 September 5, 2007 [Page 12]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
6. IANA Considerations
There are no IANA related issues in this document.
Harkins, et al. Expires September 5, 2007 [Page 13]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
7. Acknowledgments
Harkins, et al. Expires September 5, 2007 [Page 14]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[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.
[prot-auth]
Boyd, C. and A. Mathuria, "Protocols for Authentication
and Key Establishment", September 2003.
[ds-time] Denning, D. and G. Sacco, "Timestamps in key distribution
protocols", Communications of the ACM pages 533-536,
August 1981.
[3pkd] Bellare, M. and P. Rogaway, "Provably Secure Session Key
Distribution: The Three Party Case", Advances of
Cryptology - Crypto 1993 pages 110-125, August 1981.
[3pkd-choo]
Choo, R. and Y. Hitchock, "Security Requirements for Key
Establishment Proof Models: Revisiting Bellare-Rogaway and
Jeong-Katz-Lee Protocols", ACISP 2005 pages 429-442,
August 1981.
[or-attack]
Boyd, C. and W. Mao, "On a Limitation of BAN Logic",
Advances in Cryptology: Eurocrypt 93 pages 240-247,
May 1993.
Harkins, et al. Expires September 5, 2007 [Page 15]
Internet-Draft 3-Party Key Dist. Problem Statement March 2007
Appendix A. Protocols not being considered as candidates due to known
flaws
Following we present a set of protocols which have recognized flaws
but they serve as basis to other protocols.
Appendix A.1. Otway-Rees
1) A->B: M, A, B, {M, A, B, Na}Kas
2) B->S: M, A, B, {M, A, B, Na}Kas,{M, A, B, Nb}Kbs
3) S->B: M,{Na, Kab}Kas, {Nb, Kab}Kbs
4) B->A: M,{Na, Kab}Kas
The protocol adds a value M as session number but has a flaw. In
fact, a replay attack is possible by malicious intruder which can end
up with arranging different keys for A and B [or-attack].
Appendix A.2. Wide Mouth Frog
1) A->S: A,{Ta, Kab, B}Kas
2) S->B: {Ts, Kab, A}Kbs
This simple protocol shows a flaw where an attacker may force to B to
accept an old session key Kab by sending and updated message 2 (with
a new Ts) [prot-auth].
Appendix A.3. Needham-Schroeder Shared Key Protocol
1) A->S: A, B, Na
2) S->A: {Na, Kab, B, {Kab, A}Kbs}Kas
3) A->B: {Kab, A}Kbs
4) B->A: {Nb}Kab
5) A->B: {Nb-1}Kab
This protocol has a flaw where an attacker can launch a replay attack
when Kab is compromized. The attacker can use the same Kab for
different sessions.
Harkins, et al. Expires September 5, 2007 [Page 16]
Internet-Draft 3-Party Key Dist. Problem Statement March 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
Rafael Marin Lopez
Faculty of Computer Science
University of Murcia
Murcia 30100
Spain
Phone: +34968398501
Email: rafa@dif.um.es
Harkins, et al. Expires September 5, 2007 [Page 17]
Internet-Draft 3-Party Key Dist. Problem Statement March 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 September 5, 2007 [Page 18]