Internet DRAFT - draft-kwon-aaa-nemo
draft-kwon-aaa-nemo
NEMO Working Group T. Kwon
Internet-Draft S. Baek
Expires: January 12, 2006 S. Pack
Y. Choi
Seoul National University
July 11, 2005
AAA for NEMO
draft-kwon-aaa-nemo-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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The purpose of this paper is to describe an AAA protocol designed for
NEMO services. The proposed AAA protocol retains the NEMO mobility
transparency in the NEMO basic support protocol, while providing all
the required AAA functionalities for mobile network nodes. In
addition, the proposed AAA protocol reduces authentication latency by
localizing AAA process.
Kwon, et al. Expires January 12, 2006 [Page 1]
Internet-Draft AAA for NEMO July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3
2.1 General Terms . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Payloads . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Model and Assumption . . . . . . . . . . . . . . . . . . . 5
4. AAA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 MR Authentication . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Inter-Domain AAA Procedure . . . . . . . . . . . . . . 7
4.1.2 Intra-Domain AAA Procedure . . . . . . . . . . . . . . 9
4.2 VMN Authentication . . . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 15
Kwon, et al. Expires January 12, 2006 [Page 2]
Internet-Draft AAA for NEMO July 2005
1. Introduction
According to NEMO terminologies [1], a mobile network (NEMO) is
defined as a network whose point of attachment to the Internet varies
as it moves about. A NEMO consists of mobile routers (MRs) and
mobile network nodes (MNNs). Each NEMO has a home network to which
its home address belongs. When a NEMO is in its home network, the
NEMO is identified by its home address (HoA). On the other hand, the
NEMO configures a care-of-address (CoA) on the egress link when the
NEMO is away from the home network. At the same time, on the ingress
link, the MNNs of the NEMO configures CoAs, which are derived from
the subnet prefix (i.e. NEMO prefix) in the home network. This NEMO
prefix remains assigned to the NEMO while it is away from the home
network. The assigned NEMO prefix is registered with the home agent
(HA) by the NEMO basic support protocol [2].
To make NEMO services feasible in public wireless Internet, well-
defined authentication, authorization, and accounting (AAA) protocols
should be accompanied. However, to the best of our knowledge, no
specific AAA protocols have been proposed for NEMO support. Even if
a number of AAA protocols have been proposed for host mobility, all
of them are based on per-node AAA operations. Therefore, it cannot
directly applied to NEMO environments containing both local fixed
nodes (LFNs) and visiting mobile nodes (VMNs). In this document, we
propose a novel AAA protocol that provides efficient AAA procedures
in NEMO environments.
2. Terms and Abbreviations
2.1 General Terms
Attendent : An AAA entity which is the local AAA system entry point.
The attendant extracts identification and authorization data sent by
the MR or the VMN and forwards them to AAAL in order to request
authentication.
AAAH : AAA server of the home network.
AAAL : AAA server of the foreign network.
MR : mobile router.
AR : access router.
VMN : visiting mobile node. A VMN is temporarily attached to the
MR's subnet by obtaining its CoA from the NEMO prefix.
LFN : local fixed node. This belongs to the mobile network and is
Kwon, et al. Expires January 12, 2006 [Page 3]
Internet-Draft AAA for NEMO July 2005
unable to change its point of attachment.
MNN : mobile network node. MNNs such as VMN and LFN are nodes in a
NEMO.
MN : mobile node [4].
2.2 Payloads
LC (local challenge) : a challenge issued by the attendant. This is
a random number for authentication procedures.
NAI (network access identifier) : identitiy of MR or VMN. MRs and
VMNs are identified by their network access identifiers.
RPI (replay protection indicator) : Either a timestamp or a random
number can be used as an RPI.
H@ : Home Address
HA@ : Home Agent Address
SA (security association) : a relationship between a sender and a
receiver that afforcd security services to the traffic carried
between peers.
key_aaa : an AAA key in the pre-shared SA between an MR and an AAAH
CR (Credential) : an AAA credential which is used by the AAAH to
authenticate the MR or the VMN. The MR or VMN encrypts the LC using
the key in the pre-defined SA with its AAAH. The encrypted value is
called as a credential.
CR_L (Local Credential) : an AAA credential which is used by the AAAL
to authenticate the MR. The MR encrypts the LC using the key_local.
The encrypted value is called as a local credential.
key_local : a dynamic key in the temporal SA between an MR and an
AAAL server
key_home : a dynamic key in the temporal SA between and an MR and its
HA
SP_LOCAL : security parameters to establish an temporal SA between an
MR and an AAAL
SP_HOME : security parameters to establish an temporal SA between an
MR and its HA
Kwon, et al. Expires January 12, 2006 [Page 4]
Internet-Draft AAA for NEMO July 2005
2.3 Messages
In this section, the fields of the new proposed messages are
detailed.
Attendant Solicit (AS) : An IPv6 router solicitation message with the
extended AAA option
Attendant Advertisement (AA) : An IPv6 router advertisement message
with extended AAA option
Athentication Request (AReq) : NAI, RPI, H@, HA@, LC, CR
Authentication Reply (ARep) :NAI, RPI, H@, HA@, SP_HOME, SP_LOCAL
AA-Mobile-Router-Request (AMR) : NAI, RPI, H@, HA@, LC, CR
AA-Mobile-Router-Answer (AMA) : NAI, RPI, H@, HA@, SP_LOCAL,
SP_HOME
AA-Home-Agent-Request (AHR) : NAI, RPI, H@, SP_HOME
AA-Home-Agent-Answer (AHA) : NAI, H@
AA-Mobile-Router-Local-Request (AMLR) : NAI, RPI, H@, HA@, LC, CR_L
AA-Mobile-Router-Local-Answer (AMLA) : NAI, RPI, H@, HA@
3. The Model and Assumption
In this section, the AAA architecture for NEMO services is introduced
with basic assumptions and concepts such as SA and challenge/response
authentication.
Kwon, et al. Expires January 12, 2006 [Page 5]
Internet-Draft AAA for NEMO July 2005
Foreign Domain Home Domain of MR Home Domain of VMN
+--------+ "AAA network" +--------+ "AAA network" +--------+
| AAAL |<------------------->| AAAH |<------------------->| AAAH |
| server | | server | | server |
+--------+ +--------+ +--------+
^ ^ ^
| | |
| | |
v v v
+-----------+ +---------+ +---------+
| AAA | | Home | | Home |
| Attendant | | Agent | | Agent |
+-----------+ +---------+ +---------+
^
|
|
v
+--------+
| Mobile |
| Router |
+--------+
^
|
|
v
+----------+
| Visiting |
| Mobile |
| Node |
+----------+
Figure 1. NEMO AAA Architecture
Figure 1 illustrates a reference architecture for AAA in NEMO
environments, which is similar to that of Mobile IPv6 [4,5]. The AAA
architecture is based on the DIAMETER protocol [3].
The AAA architecture consists of multiple autonomous wireless
networks, each of which is called a domain. Each domain has an AAAH
server and/or an AAAL server in order to authenticate any node in a
DIAMETER-compliant manner. The AAAH server of the MR has the profile
of the MR and it shares a long-term key with the MR. Likewise, the
AAAH server of the VMN shares a long-term key with the VMN. The AAAL
server takes charge of an AAA procedure for a visiting NEMO (VMNs and
MRs). We assume that the AAAL server also serves as the home AAA
server for an AR by keeping a long-term key. The trust relationship
between the AAAH server of the MR and the AAAL server of the visited
network is maintained through the DIAMETER protocol. When the NEMO
Kwon, et al. Expires January 12, 2006 [Page 6]
Internet-Draft AAA for NEMO July 2005
changes its point of attachment, the MR needs to be authenticated and
authorized before it accesses the same foreign network (intra-domain
handoff) or a new foreign network (inter-domain handoff). To
accomplish this, the MR and AR authenticate each other through a
mutual authentication procedure that involves both the AAAH server of
the MR and the AAAL server of the AR. An attendant (which is the
same as the AAA client) is an entity that requests authentication
procedures to the AAA system. In Mobile IPv6 networks, ARs normally
act as the attendants for an MN [4]. In our protocol, the AR serves
as an attendant for the MR's authentication, while the MR serves as
an attendant for VMN's authentication. In the latter case, the MR
broadcasts attendant advertisement messages and receives
authentication request messages from VMNs within the NEMO.
Regarding SAs, it is assumed that the MR's AAAH and the VMN's AAAH
have a pre-established SA. In addition, it is assumed that the MR
and LFNs have already authenticated each other by some mechanism,
which is out of the scope of this document.
4. AAA Protocol
4.1 MR Authentication
4.1.1 Inter-Domain AAA Procedure
When a NEMO enters a new foreign network domain, an inter-domain AAA
procedure is initiated. Since the MR does not have any SA with the
AAAL server in the foreign network domain, it should be authenticated
with its AAAH server located in its home network domain. The message
flows for the inter-domain AAA procedure are depicted in figure 2.
Kwon, et al. Expires January 12, 2006 [Page 7]
Internet-Draft AAA for NEMO July 2005
MR attendant(AR) AAAL AAAH HA
| | | | |
| AS | | | |
|-------------->| | | |
| | | | |
| AA | | | |
|<--------------| | | |
| | | | |
| AReq | | | |
|-------------->| AMR | | |
| |-------------------------->| AMR | |
| | |----- >| AHR |
| | | |---------->|
| | | | |
| | | | AHA |
| | | AMA |<----------|
| | AMA |<------| |
| ARep |<--------------------------| | |
|<--------------| | | |
| | | | |
Figure 2. AAA procedures of MR : inter-domain handoff.
1) The MR sends an Attendant Solicit (AS) message to the attendant,
i.e. AR.
2) As a response to the AS message, the AR sends an Attendant
Advertisement (AA) message including an LC. Even without the AS
message, the AR broadcasts AA messages periodically.
3) The MR encrypts the received LC value using the long-term SA with
its AAAH server and makes a CR, which is used for the MR's AAAH
server to authenticate the MR. Then, the MR sends an AReq message
that contains the LC and CR to the attendant. The AReq message also
contains the NAI for the AAAL server to identify MR's home domain and
the RPI for the MR to protect from replay attack.
4) When the attendant (AR) receives the AReq message, the attendant
converts it into an AMR message, which is a new DIAMETER message.
And then, the attendant sends the AMR message to the AAAL server in
the foreign domain.
5) The AAAL server detects that it cannot authenticate the MR locally
by checking the NAI field and hence forwards the AMR message to the
MR's AAAH. When the AAAH server receives the AMR message, it
decrypts the CR using the pre-established SA and compares the result
with the LC value. If these two values are identical, the MR is
Kwon, et al. Expires January 12, 2006 [Page 8]
Internet-Draft AAA for NEMO July 2005
successfully authenticated. Then, the AAAH server constructs key
materials to make two dynamic keys: one is a key_local (to be
explained later) for intra-domain AAA procedures in the foreign
domain and the other is a key_home to make a secure bi-directional
tunnel between the MR and the MR's HA. For the construction of
key_local and key_home at the MR, SP_HOME and SP_LOCAL are also
generated. These security parameters are encrypted using the long-
term key between the MR and AAAH server to avoid the possibility of
exposure to other network entities. If there is no HA address in the
AMR message, the AAAH server will assign an HA for the MR.
6) The AAAH server informs the HA of the MR's NAI and SP_HOME by the
AHR message.
7) The HA constructs key_home by using SP_HOME and replies with an
AHA message for confirmation.
8) The AMA message is used for the AAAH server to notify the AAAL
server of the AAA result. When the AAAL server receives the AMA
message with authentication approval, the AAAL server decrypts the
message using the long-term key with the AAAH server, records the
MR's NAI, and constructs key_local.
9) The AAAL server will relay the same AMA message from the AAAH
server except for the SP_LOCAL to the attendant.
10) When receiving the AMA message, the attendant learns that the MR
is authenticated and grants the MR's network access. In addition,
the attendant informs the MR of the result by the ARep message
containing SP_HOME, SP_LOCAL, home agent address, etc.
4.1.2 Intra-Domain AAA Procedure
While a NEMO changes its point of attachment within the same foreign
domain, we propose that the MR be authenticated through a localized
AAA procedure with the AAAL server in the foreign network without any
interaction with the MR's AAAH server. That is, the AAAL of the
foreign network can authenticate the MR by the key_local.
Kwon, et al. Expires January 12, 2006 [Page 9]
Internet-Draft AAA for NEMO July 2005
MR attendant(AR) AAAL
| | |
| AS | |
|-------------->| |
| | |
| AA | |
|<--------------| |
| | |
| AReq | |
|-------------->| AMLR |
| |-------------------------->|
| | |
| | |
| | |
| | |
| | |
| | AMLA |
| ARep |<--------------------------|
|<--------------| |
| | |
Figure 3. AAA procedures of an MR : intra-domain handoff.
Figure 3 illustrates the intra-domain AAA procedure. As a response
to the AA message, the VMN sends the AReq message containing CR_L,
which is different from CR used in the inter-domain AAA procedure.
CR_L is an authentication code generated from the key_local. The
attendant constructs an AMLR DIAMETER message and sends it to the
AAAL server. When the AAAL server receives the AMLR message, the
AAAL server authenticates the MR by using key_local that is already
stored at the AAAL server and informs the attendant of the result by
the AMLA message. Then, the attendant will relay the result by the
ARep message.
4.2 VMN Authentication
A VMN is a visiting MN that accesses the Internet through an MR in a
NEMO. According to the NEMO basic support protocol [2], the VMN does
not need to know whether its new router is the AR or the MR.
Therefore, the AAA scheme for VMNs should be also transparent to this
issue. In our AAA protocol, the MR serves as an attendant for VMNs
and the MR's AAAH server serves as an AAAL server. Accordingly, the
VMN will deem the MR to be in the MR's home network.
Kwon, et al. Expires January 12, 2006 [Page 10]
Internet-Draft AAA for NEMO July 2005
VMN attendant(MR) HA_MR AAAH_MR AAAH_VMN HA_VMN
| | | | | |
| AS | | | | |
|-------------->| | | | |
| | | | | |
| AA | | | | |
|<--------------| | | | |
| | | | | |
| AReq | | | | |
|-------------->| AMR | | | |
| |--------------|----- >| | |
| | | | AMR | |
| | | |---------->| |
| | | | | AHR |
| | | | |----------->|
| | | | | |
| | | | |<-----------|
| | | | AMA | AHA |
| | | |<----------| |
| | AMA | | | |
| ARep |<-------------|-------| | |
|<--------------| | | | |
| | | | | |
Figure 4. Authentication of a VMN
Figure 4 illustrates message flows for the AAA procedure when a VMN
is attached to a NEMO. As mentioned above, the MR acts as an
attendant. Hence, the MR broadcasts AA messages periodically or
responds to an AS message from the VMN with an AS message. The VMN
creates CR using the shared SA with its AAAH server VMN and sends an
AReq message to the MR. Then, the MR converts the AReq message into
a DIAMETER message, AMR, and sends it to the MR's AAAH server AAAH_MR
through a secured bi-directional tunnel. When AAAH_MR receives the
AMR message, it relays the AMR message to AAAH_VMN that has a shared
SA and requests the AAA procedure for the VMN . The AAAH_VMN
authenticates the VMN. During this steps, the key_home, key_local,
SP_HOME, and SP_LOCAL are created similarly to the inter-domain AAA
procedure of the MR.
While a NEMO is roaming in a foreign network, VMNs within the NEMO do
not need to know that the NEMO changes its point of attachment.
Thus, VMNs do not have to register their locations to their HAs when
the NEMO hands off. This mobility transparency is the key advantage
of the NEMO basic support protocol [2]. While keeping the mobility
transparency, the AAAL server of the foreign network cannot detect
the existence of VMNs. Even if the mobility transparency is
beneficial since it reduces the registration traffic, it makes it
Kwon, et al. Expires January 12, 2006 [Page 11]
Internet-Draft AAA for NEMO July 2005
hard for the AAAL server to account the network usages of VMNs. We
propose that the AAAL server in the foreign domain be able to account
the total network usage of the NEMO (not individual VMNs) and then
this collective accounting information is sent to the MR's AAAH
server. Also, the MR's AAAH server maintains the accounting
information for the MR as well as individual VMNs. In NEMO basic
support [2], all packets destined to MNNs are tunneled at the MR's
HA, so that the MR's HA can keep track of individual LFNs and VMNs.
We assume that the MR's HA will report this information to the AAAH
server. Consequently, the MR's AAAH server can differentiate the
accounting information for MRs and VMNs. In addition, we assume that
the MR's AAAH server and the VMN's AAAH server have a trust
relationship and a shared SA. Therefore, the accounting information
collected at the MR's AAAH server is securely transferred to the
VMN's AAAH server.
The mobility transparency causes another problem, which is how to
authorize VMNs to use the NEMO's network service when the NEMO moves
to a foreign domain that has a different billing policy. To solve
this problem, an MR sends an AA message requesting re-authentication
of VMNs. From the AA message, the VMN determines whether it performs
a new AAA procedure or not. In this paper, we assume that each
network domain can have a different policy, so that the VMN performs
an AAA procedure per inter-domain handoff.
5. References
[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-03 (work in progress),
February 2005.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Franck, F. and C. Perkins, "Diameter Mobile IPv6 Application",
draft-le-aaa-diameter-mobileipv6-04 (work in progress),
November 2004.
Kwon, et al. Expires January 12, 2006 [Page 12]
Internet-Draft AAA for NEMO July 2005
Authors' Addresses
Taekyoung Kwon
Seoul National University
Multimedia and Mobile Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9105
Fax: +82-872-2045
Email: tkkwon@snu.ac.kr
URI: http://mmlab.snu.ac.kr/~tk/
Sungmin baek
Seoul National University
Multimedia and Mobile Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9147
Fax: +82-872-2045
Email: smbaek@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~smbaek/
Sangheon Pack
Seoul National University
Multimedia and Mobile Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-1832
Fax: +82-872-2045
Email: shpack@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~shpack/
Kwon, et al. Expires January 12, 2006 [Page 13]
Internet-Draft AAA for NEMO July 2005
Yanghee Choi
Seoul National University
Multimedia and Mobile Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-7303
Fax: +82-872-2045
Email: yhchoi@snu.ac.kr
URI: http://mmlab.snu.ac.kr/~yhchoi/
Kwon, et al. Expires January 12, 2006 [Page 14]
Internet-Draft AAA for NEMO July 2005
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.
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 (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kwon, et al. Expires January 12, 2006 [Page 15]
