Internet Engineering Task Force Francis Dupont
INTERNET DRAFT ENST Bretagne
Expires in May 2002 Maryline Laurent-Maknavicius
INT Evry
Julien Bournelle
INT Evry
November 20, 2001
AAA for mobile IPv6
<draft-dupont-mipv6-aaa-01.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. 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.
Distribution of this memo is unlimited.
Abstract
IPv6 mobility [5] has many security requirements which can be
roughly divided into security of signaling with common
correspondent nodes [6] and security between the mobile node and
its home agent. If IPsec [1] is not so usable in the first case
it remains the solution of choice in the second. Unfortunately
IPsec does not allow reasonable performance in some common
situations. One of the main problems is the lack of integration
with a modern network access service security like the one provided
by AAA [7].
draft-dupont-mipv6-aaa-01.txt [Page 1]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
This document describes a solution that allows the AAA
infrastructure to authenticate/authorize an IPv6 mobile node,
and to create credentials for securing subsequent AAA exchanges.
The original idea is that the mobile node is allowed to dynamically
establish a security association pair with its home agent during
AAA exchanges using the AAA system as a trusted third party.
For simplification purpose, it is assumed that Mobile IPv6 security
between the mobile node and the home agent is based on IPsec. Note
that the described solution is still valid for any other similar
security mechanisms selected for Mobile IPv6.
Table of Contents
1 Introduction .................................... Page 2
2 Short movement case ............................. Page 3
3 Boot in visit case .............................. Page 3
3.1 Schema ........................................ Page 3
3.2 Terminology ................................... Page 4
3.2.1 General terms ............................... Page 4
3.2.2 Messages .................................... Page 5
3.2.3 Payloads .................................... Page 5
3.3 Motivations ................................... Page 7
3.4 Security context .............................. Page 8
3.5 Protocol overview ............................. Page 9
3.6 IPsec and ISAKMP/IKE detailed example ......... Page 10
4 Security Considerations ......................... Page 11
5 Acknowledgments ................................. Page 11
6 Normative References ............................ Page 11
7 Informative References .......................... Page 12
8 Authors' Addresses .............................. Page 12
1. Introduction
Experiments with secure mobile IPv6 show that in some circumstances
performance of IKE [2] exchanges followed by mobile IPv6 signaling
(binding update and acknowledge) is not reasonable, so some
combinations with AAA were proposed.
Access to a new foreign network by a mobile node can be (and
should be!) optimized in two cases:
- when the new network is closed to the previous one (short
movements)
- when the mobile node boots in a foreign network (boot in
visit)
The last case can be unbearable because a common mobile node should
get a care-of address then do a main mode IKE exchange followed by a
quick mode IKE exchange before sending a home registration: at least
13 packets between local and home networks and at least 5 round trip
times without taking into account cryptography function computing...
draft-dupont-mipv6-aaa-01.txt [Page 2]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
This document defines the information to be exchanged between the
mobile node and the AAA attendant, but the mechanism to convey
this information is considered outside the scope of this document.
This document only assumes such a mechanism exists with the
following properties:
- the mechanism has two phases (solicit/advertise then request/
reply)
- the advertisement message contains a local challenge
- the protocol can carry AAA payloads.
For simplification purpose, it is assumed this protocol is
the IPv6 address allocation or registration one but in fact
only its network access control aspects are used.
This document assumes reasonable knowledge of mobile IPv6 [5],
DHCPv6 [9], AAA [7] and IPsec [1].
2. Short movement case
In the short movement case the previous AAAL is likely to be
far closer to the new AAAL than the AAAH, so the transfer of the
authentication credentials from the previous AAAL is a suitable
option.
Consequently, the mobile node should provide the new attendant/
AAAL server with the identity (NAI) of the previous attendant/AAAL
server and share an AAA security association with it (in order
to protect the transfer against a rogue MN).
3. Boot in visit case
3.1 Schema
+--------+ "AAA network" +--------+
| AAAL |<------------------->| AAAH |
| server | | server |
+--------+ +--------+
^ ^
| |
| |
v v
+-----------+ +---------+
| AAA | | Home |
| Attendant | | Agent |
+-----------+ +---------+
^
|
|
v
+--------+
| Mobile |
| Node |
+--------+
draft-dupont-mipv6-aaa-01.txt [Page 3]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
3.2 Terminology
3.2.1 General terms
Attendant: AAA entity which is the local AAA system entry point
and the local address provider/registry. Term from [8].
AAA client: attendant.
AAA home server (AAAH): AAA server of the home network.
AAA local server (AAAL): AAA server of the local network.
AVP (Attribute Value Pair): AAA (element of) payload.
Binding: home address/care-of address association for a mobile
node on a mobility aware IPv6 node.
Care-of address (Co@): temporary address used by a mobile node.
The care-of address is allocated or registered by a local
entity which is assumed for simplicity in this document
to be the same than the attendant.
Home address (H@): fixed address used by a mobile node.
The home address belongs to the home network and is in
general well known by the mobile node even if the protocol
described here supports home address allocation.
Home agent (HA): router on the home network which forwards
traffic at the destination of the home address to the
mobile node.
Mobile Node (MN): node using mobile IPv6 [5] mechanisms.
Network Access Identifier (NAI): [2] mobile user identifier
which is compatible with user_FQDN identities of IKE.
We assume NAI can be used to identify any entity involved
here even if some of them are nodes and not users.
Security Association (SA): a security connection which affords
security services to some traffic between peers.
This notion is shared between IPsec, ISAKMP [4] and AAA
over different forms.
draft-dupont-mipv6-aaa-01.txt [Page 4]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
3.2.2 Messages
(in alphabetical order)
AA (Attendant Advertisement) : second message between the
attendant and the mobile node. It is sent by the attendant
and carries a local challenge issued or transmitted by
the attendant.
AHA (AA-HA-Answer): third AAA message from the HA to the AAAH.
AHR (AA-HA-Request): second AAA message from the AAAH to the HA.
AMA (AA-MN-Answer): AAA message from the AAAH to the attendant.
This is the final AAA message.
AMR (AA-MN-Request): AAA message from the attendant to the AAAH.
This is the first AAA message.
AReq (Attendant Request): third message between the attendant
and the mobile node. It is sent by the mobile node
in order to ask for the allocation or the registration
of local/care-of address(es).
This message is loosely authenticated by the local
challenge repeated from the AA.
ARep (Attendant Reply): forth/last message between the attendant
and the mobile node. It is sent by the attendant.
We assume that in general the mobile node must wait
for this message before sending a home registration
(because this message validates the care-of address).
AS (Attendant Solicit): first message between the attendant
and the mobile node. It is sent by the mobile node
and its purpose is to discover or to select an attendant.
3.2.3 Payloads
aaa_key: MN issued keying material (algorithm, secret and
lifetime for encryption).
BA (binding acknowledge): mobile IPv6 message which gives
the result of a binding update reception.
BU (binding update): mobile IPv6 message which creates or
updates a binding. Home registrations are a special
case of BUs and they must be acknowledged.
draft-dupont-mipv6-aaa-01.txt [Page 5]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
attendant_key: MN issued keying material for the security
exchange between the attendant and the MN.
(For instance for DHCP delayed authentication [3]
it should include algorithm, secret and lifetime)
CR (MN Credential): AAA credential which is used by the AAAH
to authenticate the MN. The CR is bound to the AMR content,
we suggest using something like a RSA signature.
SecuParam_I: Security Association establishment elements
from initiator/MN. In the ISAKMP/IKE example, this should
include HASH_I, SA, Ni, KE, [IDci, IDcr] ISAKMP-like
payloads for the HA.
SecuParam_R: Security Association establishment elements
from responder/HA. In the ISAKMP/IKE example, this should
include HASH_R, SA, Nr, KE, [IDci, IDcr] ISAKMP-like
payloads for the MN. The HASH_R must include the initiator
nonce (Ni) as for IKE [2].
LC (Local Challenge): challenge issued by the attendant.
It provides a local liveliness proof of the MN, loose
local authentication and a randomness source for AAA
authentication.
NAI (MN NAI): (called ID in [8]) mobile node identity.
This is used by the AAAL in order to find the AAAH.
(The attendant may use it as an unique client
identifier too).
pub_key: public key of the AAAH.
RPI (Replay Protection Indicator): time-stamp or nonce used
between the MN and the AAAH in order to ensure replay
protection. See [8] section 3.3 for more details.
H@ (Home Address): MN home address, this will be in AHR/AHA
and either in AMR (if the MN knows it) or AMA (if the
AAAH allocates it).
HA@ (Home Agent Address): HA address, this will be in AHR/AHA
and either in AMR (if the MN knows it) or AMA (if the
AAAH provides it). The home agent discovery mechanism
should not be used from the MN because AAAH allocation
is more flexible and faster.
RC (Result Code): AAA result code (in AAA answers).
draft-dupont-mipv6-aaa-01.txt [Page 6]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
3.3 Motivations
The MN provides some credentials to the attendant which gives
them to the AAAL which forwards them to the AAAH. The AAAH checks
them and sends back the result to the AAAL and then the attendant.
The basic idea is to use this exchange in order to send
information to the HA.
In increasing "aggressiveness" order the possibilities are:
- send a pre-shared key (poor option for security) or
public key (hard to make secure) or certificates
(but they can be already stored in the home network or agent).
- build an ISAKMP security association (i.e. fake a IKE phase one)
as it is proposed with Kerberos in KINK [10].
- build an IPsec SA pair (i.e. fake a IKE phase two) in order
to protect the BU/BA exchange. This is realized by the
protocol described in this document.
- piggy-back the BU/BA exchange in AAA.
The last idea (from [8] and [11]) has too many problems:
- mobile IPv6 needs a strong anti-replay mechanism (as explained
in [5] section 13.1 the BU/BA sequence number provides only
ordering).
- if an AAA mechanism is used in place of IPsec in all
circumstances, in some cases it will be a big waste in
efficiency (i.e. this is too drastic): the performance issue
of IPsec/IKE is in SA establishment only.
- the MN may get its care-of address(es) only at the
end of the attendant/AAA exchange, thus it cannot provide
it/them at the beginning.
- from a security point of view, to have a secret key between
*only* the MN and the HA is far better than to ensure security
by AAA servers. It can be reused in order to protect the tunnel
between the MN and the HA by ESP too.
draft-dupont-mipv6-aaa-01.txt [Page 7]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
3.4 Security context
This document makes many assumptions about security context,
i.e. security services that should be available so used.
Here is a list of those assumptions with their consequences:
- AAA connections are supposed to be protected (i.e. protected
(by other tools) payloads are protected against entities
that should not need to know what is in).
- the attendant is in charge of providing a good local
challenge which is the source of randomness for the
MN credentials (CR).
- the security of the protocol used between the mobile node
and the attendant is not addressed by this document but
the attendant_key ensures delayed authentication as defined
for DHCP [3] for instance.
- the MN has the proof of identity of AAAH using its public key
for aaa_key encryption.
- the attendant_key secret proves a communication from the AAAH
to the attendant (i.e. it can replace a reverse challenge).
- as a result of KE (i.e. Diffie-Hellman) payload exchange through
SecuParam_*, the AAAH server does not know the shared secret
between MN and HA. So KEs are not really optional in this first
release of the protocol in the IKE/ISAKMP example: the fake
phase 2 is with PFS.
- there is no proof of MN liveliness as the one ensured by the IKE
phase 2 third message. This does not seem to be a problem?
This document does not strongly defined the layout of SecuParam_*
payloads. As an example, this document describes an ISAKMP-like
layout but some others are possible as discussed for KINK [10]
and (a better source of ideas which has exactly the same problem
in a very similar context) for HIP [12].
draft-dupont-mipv6-aaa-01.txt [Page 8]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
3.5 Protocol overview
The overall protocol is depicted below:
MN attendant AAAL AAAH HA
| | | | |
| AS | | | |
|----------> | | | |
| | | | |
| AA | | | |
|<--------------| | | |
| | | | |
| AReq | | | |
|-------------->| AMR | | |
| |-------------------------->| AMR | |
| | |----- >| AHR |
| | | |---------->|
| | | | |
| | | | AHA |
| | | AMA |<----------|
| | AMA |<------| |
| ARep |<--------------------------| | |
|<--------------| | | |
| | | | |
| BU | | | |
|-------------------------------------------------------------->|
| | | | |
| | | | BA |
|<--------------------------------------------------------------|
| | | | |
Notation:
[XX] = optional element (XX)
{XX}xxx = protected element (XX) using the xxx_key keying material
Content of messages:
AS: Attendant Solicit (likely a multicast IPv6 packet)
AA: Attendant Advertisement with LC (challenge issued or
transmitted by the attendant)
draft-dupont-mipv6-aaa-01.txt [Page 9]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
AReq: Attendant Request with:
LC (local challenge)
NAI (MN identity)
(then in an AAA opaque option)
RPI AAA replay protection indicator
[H@] home address (will be allocated by AAAH if none)
[HA@] home agent address (will be allocated by AAAH if none)
{aaa_key}pub keying material for protection of AAA messages
{attendant_key}aaa
{SecuParam_I}aaa Security Association establishment elements for HA
CR MN authenticator (signature of the AVP set)
AMR: same content than the previous IPv6 packet (translated to AAA)
AHR: [H@], SecuParam_I
AHA: SecuParam_R
AMA: AAA answer with:
RC result code (validity of AMR CR)
attendant_key local secret between the MN and the attendant
RPI new replay protection indicator
[H@] home address, if not in AMR
[HA@] home agent address, if not in AMR
{SecuParam_R}aaa copied from AHA
ARep: Attendant Reply protected by the attendant_key shared
secret with:
[Co@] care-of address, allocated/registered by the attendant
(then in an AAA opaque option)
RPI copied from AMA
[H@] copied from AMA
[HA@] copied from AMA
{SecuParam_R}aaa copied from AMA
3.6 IPsec and ISAKMP/IKE detailed example
This section provides the detailed layout of SecuParam_* with
the associated keying material as an example.
There is no real phase 1 so the phase 1 like parameters must be
agreed before. SA payloads must negotiate AH SAs with replay
protection as required by mobile IPv6. The identity payloads
provide in fact only the IPv6 protocol to protect (there is an
open issue about this for mobile IPv6): port is not relevant and
address identities for H@ and HA@ can be assumed. HIP [12]
should be considered as a good example of how to specialize IKE
mechanisms to this kind of context (i.e. when HIP will be well
known it should be used as the basis of this section).
draft-dupont-mipv6-aaa-01.txt [Page 10]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
In [2] notations, secret materials are (unvalidated proposal):
SKEYID = prf(Ni_b | Nr_b, g^xy)
HASH_R = prf(SKEYID, Ni_b | SecuParam_R)
KEYMAT = prf(SKEYID, g^xy | protocol | SPI | Ni_b | Nr_b)
If the H@ and the HA@ are known by the MN it can reserve
(i.e. create in the larval state) a SA (i.e. a SPI) for
SecuParam_I. This is harder when one or both are not known
but this protocol deals with the booting case...
4. Security Considerations
This protocol provides as aggressive as possible integration
of AAA into secure mobile IPv6 in the "boot in visit case"
without too many infringements to security...
Obviously a deep security review is needed: we request comments!
5. Acknowledgments
The seminal work was done by AAA for IPv6 network access
document [8]. The lack of a concrete proposal for mobile IPv6
in this document was the reason to develop this protocol.
We would like to thank Olivier Charles (France Telecom R&D)
for his continuous encouragements. The following persons
listed in the alphabetical order have taken part into this
document: Julien Bournelle (INT Evry), Francis Dupont (ENST
Bretagne), Maryline Laurent-Maknavicius (INT Evry).
6. Normative References
[1] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[2] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[3] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[4] D. Maughan, M. Schertler, M. Schneider, J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
draft-dupont-mipv6-aaa-01.txt [Page 11]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
7. Informative References
[5] D. Johnson, C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-14.txt, work in progress,
July 2001.
[6] A. Mankin & all, "Threat Models introduced by Mobile IPv6 and
Requirements for Security in Mobile IPv6",
draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, work in
progress, November 2001.
[7] S. Glass, T. Hiller, S. Jacobs, C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements",
RFC 2977, October 2000.
[8] P. Flykt, C. Perkins, T. Eklund, "AAA for IPv6 Network Access",
draft-perkins-aaav6-04.txt, work in progress, July 2001.
[9] J. Bound, M. Carney, C. Perkins, R. Droms, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)",
draft-ietf-dhc-dhcpv6-20.txt, work in progress, October 2001.
[10] T. Kivinen, "Kerberized Internet Negotiation of Keys (KINK)",
draft-ietf-kink-kink-01.txt , work in progress, July 2001.
[11] S. Faccin, F. Le, B. Patil, C. Perkins, "Diameter Mobile
IPv6 Application", draft-le-aaa-diameter-mobileipv6-00.txt,
work in progress, July 2001.
[12] R. Moskowitz, "Host Identity Payload And Protocol",
draft-moskowitz-hip-04.txt, work in progress, July 2001.
8. Authors' Addresses
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
BP 78
35512 Cesson-Sevigne Cedex
FRANCE
Fax: +33 2 99 12 70 30
EMail: Francis.Dupont@enst-bretagne.fr
Maryline Laurent-Maknavicius
INT Evry
9, rue Charles Fourier
91011 Evry Cedex
FRANCE
Fax: +33 1 60 76 47 11
EMail: Maryline.Maknavicius@int-evry.fr
draft-dupont-mipv6-aaa-01.txt [Page 12]
INTERNET-DRAFT AAA for mobile IPv6 November 2001
Julien Bournelle
INT Evry
9, rue Charles Fourier
91011 Evry Cedex
FRANCE
Fax: +33 1 60 76 47 11
EMail: Julien.Bournelle@int-evry.fr
Expire in 6 months (May 21, 2002)