HOKEYP BOF Z. Cao
Internet-Draft Peking University
Intended status: Standards Track H. Deng
Expires: April 4, 2007 Y. Ma
Hitachi (China)
Oct 2006
Security Association Derivation between Access Nodes
draft-cao-hokeyp-sa-derivation-00.txt
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 April 4, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Cao, et al. Expires April 4, 2007 [Page 1]
Internet-Draft SA Derivation Oct 2006
Abstract
This document specifies a mechanism to establish Security
Associations (SAs) between Access Nodes in the handover keying
architecture. The proposed mechanism negotiates the SA with the help
of existing SAs between Access Nodes and Access Domain Controller,
and between Access Domain Controller and AAA server as well.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Scenario One: within one Access Domain . . . . . . . . . . 5
3.2. Scenario Two: across different Access Domains . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11
6.2. Informative Reference . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Cao, et al. Expires April 4, 2007 [Page 2]
Internet-Draft SA Derivation Oct 2006
1. Introduction
The handover keying problem statement document [I.D.aaa-hokey-ps]
gives a problem statement for handover keying and intends to provides
the first insight into developing a comprehensive handover keying
solutions deals with various types of handovers within IETF. In
addition, it specifies a wireless handover keying architecture in
which various security association (SA) between entities are
described. But it leaves behind the problem of investigating the
possible trust relationship between the Access Nodes (ANs). This SA
will be important when ANs are transmiting certain security
information with each other such as what is specified in
[I-D.handover-keys-aaa].
In this document, we specify a mechanism to derive security
associations between the Access Nodes. The SAs between ANs that
belong to the same Access Domain are negotiated with the help of
Access Domain Controller (ADC), while the SAs between ANs that belong
to different Access Domain are negotiated with the help of both the
ADC and AAA server.
Cao, et al. Expires April 4, 2007 [Page 3]
Internet-Draft SA Derivation Oct 2006
2. 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 [RFC2119].
The following new terminology and abbreviations are introduced in
this document and all the other general mobility related terms as
defined in [I-D.ietf-eap-keying] and [I.D.aaa-hokey-ps]
Access Node (AN)
The access node is the entity (layer 2 or layer 3) residing at the
edge of network and is responsible for providing access link to
the peer. Multiple Access Nodes MAY be grouped under one Access
Domain Controller.
Cao, et al. Expires April 4, 2007 [Page 4]
Internet-Draft SA Derivation Oct 2006
3. Proposed Solution
To establish a security association between ANs, one AN initiates a
Diffie-Hellman key exchange procedure with the other one. Because
the ANs do not have pre-shared secrets or other credentials to
authenticate the DH public values in order to defend against the MITM
attack, we need the help of other entities in the architecture to
protect the DH public values. The security associations between the
AN and ADC and between the ADC and AAA server can be suitable to take
this responsibility.
The proposed solution will be specified respectively in two different
scenarios:
o Scenario One: ANs reside in the same Access Domain.
o Scenario Two: ANs reside in different Access Domains.
The protocol operations in these two scenarios will be described in
the following two subsections in details.
3.1. Scenario One: within one Access Domain
In this scenario, AN1 and AN2 are under the control of the same
Access Domain Controller (ADC), e.g. ADC1. AN1 initiates the
Diffie-Hellman procedure by sending a SA request (SAReq) message to
the ADC1. SAReq message contain the identifier of AN1 and AN2, the
ciphersuites supported by AN1, the DH public value of AN1 (g^i), and
a nonce value (Ni). Further more, SAReq message is authenticated and
encrypted by the existing SA between AN1 and ADC1.
On receiving the SAReq message from AN1, ADC1 decrypts and
authenticates the message. Successful authentication leads ADC1 to
send an SA request delegation message (SAReq-Dele) to AN2, which is
authenticated and encrypted of the raw content of SAReq by the
existing SA between ADC1 adn AN2.
AN2 decrypts and authenticates the SAReq-Dele message, from which it
knows that AN1 wants to establish a SA with itself. Then AN2
construct a SA response message (SAResp) containing the identifier of
AN2 and AN1, a chosen ciphersuite support by AN2, the DH public value
of AN2 (g^r), and a nonce value (Nr). This message is authenticated
and encrypted by the existing SA between AN2 and ADC1.
After decrypting and authenticating the SAResp message from AN2, ADC1
construct and send a SA response delegation message (SAResp-Dele) to
AN1, which is authenticated and encrypted with the existing SA
between ADC1 and AN1.
Cao, et al. Expires April 4, 2007 [Page 5]
Internet-Draft SA Derivation Oct 2006
Completing the DH public value exchange, AN1 and AN2 will be able to
derive the shared key Ks and use it to secure subsequent
communications between them.
When AN1 validates the SAResp-Dele message, it confirms AN2 by
sending a SA-Conf message to AN2, including the nonce value generated
by AN2 (Nr) to avoid potential Denial of Service attacks, and this
message is authenticated with the newly derived shared key Ks.
The shared key Ks is computed as follows:
Ks = prf(g^ir, Ni|Nr)
AN1 ADC1 AN2
| SAReq | |
|---------------->| SAReq-Dele |
| |---------------->|
| | |
| | SAResp |
| |<----------------|
| SAResp-Dele | |
|<----------------| |
| | |
| SA-Conf |
|---------------------------------->|
|<=========SA Establishment========>|
Figure 1: Protocol Operations when ANs reside in the same AD
3.2. Scenario Two: across different Access Domains
When the ANs who want to establish a security association reside in
different ADCs, it further needs the help of AAA server to complete
the Diffie-Hellman procedure in a secure manner.
AN1 initiates the Diffie-Hellman procedure by sending a SAReq message
to ADC1, including the identifier of AN1, AN2, the ciphersuits
supported by the AN1, and the DH public value of AN1 (g^i), and a
nonce value (Ni). This message is authenticated and encrypted with
the existing SA between AN1 and ADC1.
Then ADC1, AAA server and ADC2 take turns to delegate the SAReq
message to AN2 in the end. SAReq-Dele1, SAReq-Dele2 and SAReq-Dele3
are authenticated and encrypted with the existing SAs between ADC1
and AAA, AAA and ADC2, ADC2 and AN2.
Cao, et al. Expires April 4, 2007 [Page 6]
Internet-Draft SA Derivation Oct 2006
On receiving and successfully authenticating the SAReq message
delegated by ADC2, AN2 constructs and sends out a SA Response
(SAResp) message including the identifier of AN2, AN1, and a chosen
ciphersuite supported by AN2, its DH public value (g^r) and a nonce
value (Nr). The SAResp message is delegated by ADC2, AAA, and ADC1
in the reversed direction of SAReq message. When AN1 receives the
SAResp message delegated by ADC1, it decrypts and authenticates that
message using the existing SA between AN1 and ADC1.
Completing the DH public value exchage, AN1 and AN2 are able to
derive the shared key Ks and use it to secure subsequent
communications between them.
When AN1 validates the SAResp-Dele2 message, it confirms AN2 by
sending a SA-Conf message to AN2, including the nonce value generated
by AN2 (Nr) to avoid potential Denial of Service attacks, and this
message is authenticated with the newly derived shared key Ks.
The shared key Ks is computed as follows:
Ks = prf(g^ir, Ni|Nr)
AN1 ADC1 AAA ADC2 AN2
| SAReq | | | |
|----------->| SAReq-Dele1 | | |
| |------------>| SAReq-Dele2| |
| | |----------->| SAReq-Dele3|
| | | |----------->|
| | | | |
| | | | SAResp |
| | |SAResp-Dele1|<-----------|
| |SAResp-Dele2 |<-----------| |
|SAResp-Dele3|<------------| | |
|<-----------| | | |
| | | | |
| SA-Conf |
|--------------------------------------------------->|
|<================ SA Establishement ===============>|
Figure 2: Protocol Operations when ANs reside in the same AD
Given that there is a security association between ADCs, the
procedure of AN SA establishment can be redured to six messages
without the help of AAA server. We neglect the details here for they
Cao, et al. Expires April 4, 2007 [Page 7]
Internet-Draft SA Derivation Oct 2006
are very similar to what has been elaborated above.
Note that although the handover keying problem statement document
[I.D.aaa-hokey-ps] does not point out the SA between ADCs, we assert
that these SAs MAY exist in the realistic development. If necessary,
we can establish the SA between ADCs with the help of the SA between
ADC and AAA server, take advantage of the similar mechanism proposed
in this document.
AN1 ADC1 ADC2 AN2
| SAReq | | |
|----------->| SAReq-Dele1 | |
| |------------>| SAReq-Dele2|
| | |----------->|
| | | |
| | | |
| | | SAResp |
| |SAResp-Dele1 |<-----------|
|SAResp-Dele2|<------------| |
|<-----------| | |
| | | |
| SA-Conf |
|-------------------------------------->|
|<======== SA Establishement ==========>|
Figure 3: Protocol Operations simplified with SA between ADCs
Cao, et al. Expires April 4, 2007 [Page 8]
Internet-Draft SA Derivation Oct 2006
4. Security Considerations
The suggested proposal does not create nor enhance any new and/or
existing threats. In particular, launching a man-in-the middle
attack against the protocol is not possible as long as the attacker
is not able to compromise the SA between AN and ADC, or the SA
between ADC and AAA Server.
The confidentiality and authenticity of the tranported message is
protected by encrypting the message and computing a authenticator
based on the existing SAs. Since attackers can not spoof the SA
request and SA response message with correct authenticators, denial
of service attacks towards the ANs by cheating them into Diffie-
Hellman computation are not possible.
The suggested proposal DOES NOT guard against compromise of the
Access Domain Controll or AAA Server. If the corresponding ADC or
AAA in SA delegation is compromised, the man-in-the-middle attack can
be launched for the Diffie-Hellman exchange.
Cao, et al. Expires April 4, 2007 [Page 9]
Internet-Draft SA Derivation Oct 2006
5. IANA Considerations
This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
Cao, et al. Expires April 4, 2007 [Page 10]
Internet-Draft SA Derivation Oct 2006
6. References
6.1. Normative Reference
[I.D.aaa-hokey-ps]
Nakhjiri, M., Parthasarathy, M., and al. et, "AAA based
Keying for Wireless Handovers: Problem Statement",
May 2005, <draft-nakhjiri-aaa-hokey-ps-02.txt (work in
progress)>.
6.2. Informative Reference
[I-D.handover-keys-aaa]
Narayanan, V., Venkitaraman, N., and et. al, "Handover
Keys Using AAA",
<draft-vidya-mipshop-handover-keys-aaa-03.txt (work in
progress)>.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", <draft-ietf-eap-keying-13.txt (work
in progress)>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Cao, et al. Expires April 4, 2007 [Page 11]
Internet-Draft SA Derivation Oct 2006
Authors' Addresses
Zhen Cao
Peking University
No.1 Science Building Room 1534
5 Yi He Yuan Lu
Hai Dian District
Beijing 100871
China
Email: caozhen@pku.edu.cn
Hui Deng
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Yuanchen Ma
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: ycma@hitachi.cn
Cao, et al. Expires April 4, 2007 [Page 12]
Internet-Draft SA Derivation Oct 2006
Full 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.
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.
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).
Cao, et al. Expires April 4, 2007 [Page 13]