One document matched: draft-ietf-mip6-ikev2-ipsec-01.txt
Differences from draft-ietf-mip6-ikev2-ipsec-00.txt
MIP6 Working Group V. Devarapalli
Internet-Draft Nokia
Expires: August 24, 2005 February 20, 2005
Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
draft-ietf-mip6-ikev2-ipsec-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes Mobile IPv6 operation with the revised IPsec
architecture and IKEv2.
Devarapalli Expires August 24, 2005 [Page 1]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. What is applicable from RFC 3776? . . . . . . . . . . . . . . 5
3.1 Packet Formats . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Home Agent Requirements . . . . . . . . . . . . . . . 5
3.2.2 Mobile Node Requirements . . . . . . . . . . . . . . . 6
4. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 7
4.1 Binding Update and Acknowledgements . . . . . . . . . . . 7
4.2 Return Routabililty Messages . . . . . . . . . . . . . . . 8
4.3 Mobile Prefix Discovery Messages . . . . . . . . . . . . . 9
4.4 Payload Packets . . . . . . . . . . . . . . . . . . . . . 10
5. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 11
5.1 Security Policy Database Entries . . . . . . . . . . . . . 11
5.1.1 Binding Updates and Acknowledgements . . . . . . . . . 11
5.1.2 Return Routability Messages . . . . . . . . . . . . . 12
5.1.3 Mobile Prefix Discovery Messages . . . . . . . . . . . 13
5.1.4 Payload Packets . . . . . . . . . . . . . . . . . . . 13
5.2 Security Association negotiation using IKEv2 . . . . . . . 14
6. The use of EAP authentication . . . . . . . . . . . . . . . . 17
7. Dynamic Home Address Configuration . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1 Normative References . . . . . . . . . . . . . . . . . . . 24
11.2 Informative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 26
Devarapalli Expires August 24, 2005 [Page 2]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
1. Introduction
RFC 3776 describes how IPsec [11] is used with Mobile IPv6 [2] to
protect the signaling messages. It also illustrates examples of
Security Policy Database and Security Association Database entries
that can be used to protect Mobile IPv6 signaling messages.
The IPsec architecture has been revised [5]. Among the many changes,
the list of selectors has been expanded to included the Mobility
Header message type. This has an impact on how security policies and
security associations are configured for protecting mobility header
messages. It becomes easier to differentiate between the various
Mobility Header messages based on the type value instead of checking
if a particular mobility header message is being sent on a tunnel
interface between the mobile node and the home agent, as it was in
RFC 3776. The revised IPsec architecture specification also includes
ICMP message type and code as selectors. This makes it possible to
protect Mobile Prefix Discovery messages without applying the same
security associations to all ICMPv6 messages.
This document discusses new requirements for the Home Agent and the
mobile node to use the revised IPsec architecture and IKEv2.
Section 3.2 lists the requirements. Section 3 describes the
differences with RFC 3776. Section 4 describes the required Security
Policy Database (SPD) and Security Association Database (SAD)
entries.
The Internet Key Exchange (IKE) has also been substantially revised
and simplified [4]. This document describes how IKEv2 can be used to
setup security associations for Mobile IPv6.
The use of EAP within IKEv2 is allowed to authenticate the mobile
node to the Home Agent. This is described in Section 6. A method
for dynamically configuring a home address from the Home Agent using
the Configuration Payload in IKEv2 is described in Section 7.
Devarapalli Expires August 24, 2005 [Page 3]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
2. Terminology
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 [1].
Devarapalli Expires August 24, 2005 [Page 4]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
3. What is applicable from RFC 3776?
3.1 Packet Formats
The mobile node and the Home Agent must support the packet formats as
defined in Section 3 of RFC 3776. This document does not update the
packet formats described in RFC 3776.
3.2 Requirements
The mobile node and the Home Agent MUST support the requirements
listed in Section 4 of RFC 3776 with the following exceptions.
o It is not required to configure security policies per interface in
order to protect return routability signaling messages. Since the
Mobility Header message type is a selector, it is easy to
differentiate HoTi and HoT messages from other Mobility Header
messages.
o It is necessary to avoid a condition where a mobile node could use
its security association to send a Binding Update on behalf of
another mobile node. With manual IPsec configuration, the Home
Agent MUST be able to verify that a security association was
created for a particular home address. With dynamic keying, it
should be possible for the Home Agent to verify that the identity
presented in the IKE_AUTH exchange is allowed to create security
associations for a particular home address.
o The mobile node should use its Care-of Address as source address
in protocol exchanges, when using dynamic keying. However, the
security associations MUST be created for the home address of the
mobile node.
o The mobile node and the Home Agent MUST create security
associations based on the home address, so that the security
associations survive change in Care-of Address. When using IKEv2
as the key exchange protocol, the home address should be carried
in the TSi payload during the CREATE_CHILD_SA exchange [4].
3.2.1 Home Agent Requirements
This section describes additional requirements on the Home Agent.
o The Home Agent MUST support Mobility Header message type as an
IPsec selector.
Devarapalli Expires August 24, 2005 [Page 5]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
o The Home Agent MUST support ICMPv6 message type as an IPsec
selector.
o The Home Agent MUST be able to distinguish between HoTi messages
sent to itself, when it is acting as a Correspondent Node, from
those sent to Correspondent Nodes when it is acting as a Home
Agent, based on the destination address of the packet.
o The Home Agent MAY use the Peer Authorization Database (PAD) [5]
to store per-mobile node state. The PAD entry for a mobile node
can contain a shared key, public key or a trust anchor to verify
the mobile node's certificate for authenticating the mobile node.
o The Home Agent MAY support remote configuration of home address as
described in Section 7. When the Home Agent receives a
configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDR, it
must reply with a valid home address for the mobile node. The
Home Agent could pick a home address from a local database or from
a DHCPv6 server on the home link.
o The Home Agent MAY support authentication using EAP in IKEv2 as
described in Section 2.16 of [4].
3.2.2 Mobile Node Requirements
This section describes additional requirements on the mobile node.
o The mobile node MUST support Mobility Header message type as an
IPsec selector.
o The mobile node MUST support ICMPv6 message type as an IPsec
selector.
o The mobile node MAY support EAP as an authentication mechanism
when using IKEv2 to setup security associations for protecting
Mobile IPv6 signaling messages.
o The mobile node MAY support the mechanism described in Section 7
to dynamically configure a home address.
Devarapalli Expires August 24, 2005 [Page 6]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
4. Manual Configuration
This section describes the SPD and SAD entries that can be used to
protect Mobile IPv6 signaling messages.
For the examples described in this document, a mobile node with home
address, "home_address_1", a Home Agent with address, "home_agent_1"
and a user of the mobile node with identity "user_1" are assumed. If
the home address of the mobile node changes, the SPD and SAD entries
need to re-created or updated for the new home address.
4.1 Binding Update and Acknowledgements
The following are the SPD and SAD entries on the mobile node and the
Home Agent to protect Binding Updates and Acknowledgements.
Devarapalli Expires August 24, 2005 [Page 7]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
mobile node SPD-S:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH & mh_type = BU
Then use SA SA1
mobile node SPD-I:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH & mh_type = BAck
Then use SA SA2
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH & mh_type = BU
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH & mh_type = BAck
home agent SPD-S:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH & mh_type = BAck
Then use SA SA2
home agent SPD-I:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH & mh_type = BU
Then use SA SA1
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH & mh_type = BAck
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH & mh_type = BU
4.2 Return Routabililty Messages
The following are the SPD and SAD entries on the mobile node and the
Home Agent to protect Return Routability messages.
Devarapalli Expires August 24, 2005 [Page 8]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
mobile node SPD-S:
- IF source = home_address_1 & destination = any &
proto = MH & mh_type = HoTi
Then use SA SA3
mobile node SPD-I:
- IF destination = home_address_1 & source = any &
proto = MH & mh_type = HoT
Then use SA SA4
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH &
mh_type = HoTi
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH &
mh_type = HoT
home agent SPD-S:
- IF destination = home_address_1 & source = any &
proto = MH & mh_type = HoT
Then use SA SA4
home agent SPD-I:
- IF source = home_address_1 & destination = any &
proto = MH & mh_type = HoTi
Then use SA SA3
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH &
mh_type = HoT
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH &
mh_type = HoTi
4.3 Mobile Prefix Discovery Messages
The following are the SPD and SAD entries used to protect Mobile
Prefix Discovery messages.
Devarapalli Expires August 24, 2005 [Page 9]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
mobile node SPD-S:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
Then use SA SA5.
mobile node SPD-I:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
Then use SA SA6
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
home agent SPD-S:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
Then use SA SA6
home agent SPD-I:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
Then use SA SA5
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
4.4 Payload Packets
Payload traffic tunneled through the Home Agent can be protected by
IPsec, if required. The mobile node and the Home Agent use ESP in
tunnel mode to protect the tunneled traffic. The SPD and SAD entries
shown in Section 5.2.4 of [3] are applicable here.
Devarapalli Expires August 24, 2005 [Page 10]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
5. Dynamic Configuration
This section describes the use of IKEv2 to setup the required
security associations.
5.1 Security Policy Database Entries
The following sections describe the security policy entries on the
mobile node and the Home Agent. In the examples shown below, the
identity of the user of the mobile node is assumed to be user_1, the
home address of the mobile node is assumed to be home_address_1 and
the IPv6 address of the Home Agent is assumed to be home_agent_1.
5.1.1 Binding Updates and Acknowledgements
The following are the SPD entries on the mobile node and the Home
Agent for protecting Binding Updates and Acknowledgements.
mobile node SPD-S:
- IF destination = home_agent_1 & proto = MH & mh_type = BU
Then use SA ESP transport mode
IDi = user_1, IDr = home_agent_1,
TSi = home_address_1
mobile node SPD-I:
- IF source = home_agent_1 & proto = MH & mh_type = BAck
Then use SA ESP transport mode
IDi = user_1, IDr = home_agent_1,
TSi = home_address_1
home agent SPD-S:
- IF source = home_agent_1 & proto = MH & mh_type = BAck
Then use SA ESP transport mode
IDr = user_1, IDi = home_agent_1,
TSr = home_address_1
home agent SPD-I:
- IF destination = home_agent_1 & proto = MH & mh_type = BU
Then use SA ESP transport mode
IDr = user_1, IDi = home_agent_1,
TSr = home_address_1
In the examples shown above, the home address of the mobile node
might not be available all the time. When the mobile node acquires a
new home address, it must add the address to the corresponding SPD
entries.
The Mobility Header type is negotiated by placing it in the most
Devarapalli Expires August 24, 2005 [Page 11]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
significant eight bits of the 16 bit local "port" selector during
IKEv2 exchange. For more details, refer to [5]. The TSi and TSr
payloads in the above examples will contain many other selectors
apart from home_address_1. For the sake of brevity, they are not
shown here.
5.1.2 Return Routability Messages
The following are the SPD entries on the mobile node and the Home
Agent for protecting the Return Routability messages.
mobile node SPD-S:
- IF proto = MH & mh_type = HoTi
Then use SA ESP tunnel mode
IDi = user_1,
outer src addr = coa
outer dst addr = home_agent_1,
inner src addr = home_address_1
mobile node SPD-I:
- IF destination = home_address_1 & proto = MH & mh_type = HoT
Then use SA ESP tunnel mode
IDi = user_1,
outer src addr = home_agent_1,
outer dst addr = coa,
home agent SPD-S:
- IF proto = MH & mh_type = HoT
Then use SA ESP tunnel mode
IDr = user_1,
outer src addr = home_agent_1,
outer dst addr = coa,
inner dst addr = home_address_1
home agent SPD-I:
- IF proto = MH & mh_type = HoTi
Then use SA ESP tunnel mode
IDr = user_1,
outer src addr = coa,
outer dst addr = home_agent_1,
inner src addr = home_address_1
When the mobile node's Care-of Address changes the SPD entries on
both the mobile node and the Home Agent must be updated. The Home
Agent knows about the change in Care-of Address of the mobile node
when it receives a Binding Update from the mobile node.
Devarapalli Expires August 24, 2005 [Page 12]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
5.1.3 Mobile Prefix Discovery Messages
The following are the SPD entries on the mobile node and the Home
Agent for protecting Mobile Prefix Discovery messages.
mobile node SPD-S:
- IF destination = home_agent_1 & proto = ICMPv6 &
icmp6_type = MPS
Then use SA ESP transport mode
IDi = user_1, IDr = home_agent_1,
TSi = home_address_1
mobile node SPD-I:
- IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA
Then use SA ESP transport mode
IDi = user_1, IDr = home_agent_1,
TSi = home_address_1
home agent SPD-S:
- IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA
Then use SA ESP transport mode
IDr = user_1, IDi = home_agent_1,
TSr = home_address_1
home agent SPD-I:
- IF destination = home_agent_1 & proto = ICMPv6 &
icmp6_type = MPS
Then use SA ESP transport mode
IDr = user_1, IDi = home_agent_1,
TSr = home_address_1
In the examples shown above, the home address of the mobile node
might not be available all the time. When the mobile node acquires a
new home address, it must add the address to the corresponding SPD
entries.
The TSi and TSr payloads in the above examples will contain many
other selectors apart from home_address_1. For brevity, they are not
show here.
5.1.4 Payload Packets
The following are the SPD entries on the mobile node and the Home
Agent if payload traffic exchanged between the mobile node and its
Correspondent Node needs to be protected. The SPD entries are
similar to the entries for protecting Return Routability messages and
have lower priority than the above SPD entries.
Devarapalli Expires August 24, 2005 [Page 13]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
mobile node SPD-S:
- IF interface = IPv6 tunnel to home_agent_1 &
proto = X
Then use SA ESP tunnel mode
IDi = user_1,
outer src addr = coa
outer dst addr = home_agent_1,
inner src addr = home_address_1
mobile node SPD-I:
- IF destination = home_address_1 & proto = X &
source = any_cn
Then use SA ESP tunnel mode
IDi = user_1,
outer src addr = home_agent_1,
outer dst addr = coa,
home agent SPD-S:
- IF interface = IPv6 tunnel to home_address_1 &
proto = X
Then use SA ESP tunnel mode
IDr = user_1,
outer src addr = home_agent_1,
outer dst addr = coa,
inner dst addr = home_address_1
home agent SPD-I:
- IF interface = IPv6 tunnel to home_address_1 &
proto = X
Then use SA ESP tunnel mode
IDr = user_1,
outer src addr = coa,
outer dst addr = home_agent_1,
inner src addr = home_address_1
5.2 Security Association negotiation using IKEv2
Mobile IPv6 signaling messages are typically initiated by the mobile
node. The mobile node sends a Binding Update to the Home Agent
whenever it moves and acquires a new Care-of Address.
The mobile node initiates an IKEv2 protocol exchange if the required
security associations are not present. The default mechanism used
for mutual authentication is a shared secret between the mobile node
and the Home Agent. The Home Agent uses the identity of the mobile
node to identify the corresponding shared secret. If public key
based mechanism is used, the Home Agent and the mobile node use their
Devarapalli Expires August 24, 2005 [Page 14]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
private keys to generate the AUTH payload. The mobile node and the
Home Agent should use CERTREQ and CERT payloads if the identities
need to be verified. If the mobile node is configured with the Home
Agent information including the public key that corresponds to the
Home Agent, then the mobile node MAY exclude the CERTREQ payload in
message 3. Similarly, the Home Agent MAY exclude the CERTREQ payload
in message 2, if it is configured with the mobile node information.
If a shared secret is being used, the mobile node uses the shared
secret to generate the AUTH payload in the IKE_AUTH exchange. If the
mobile node is using a public key based mechanism, then it uses its
private key to generate the AUTH payload in the IKE_AUTH exchange.
Mobile Node Home Agent
----------- ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr}
-->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The mobile node MUST always includes its identity in the IDi payload
in the IKE_AUTH exchange. The mobile node could use the following
different types of identities to identity itself to the Home Agent.
o Home Address - The mobile node could use its statically configured
home address as its identity. In this case the ID Type field is
set to ID_IPV6_ADDR.
o FQDN - The mobile node can use a Fully Qualified Domain Name as
the identifier and set the ID Type field to ID_FQDN.
o RFC 822 identifier - If the mobile node uses a RFC 822 identifier
[9], it sets the ID Type field to ID_RFC822_ADDR.
After the IKE_AUTH exchange completes, the mobile node and the Home
Agent initiate CREATE_CHILD_SA exchanges to negotiate security
associations for protecting Binding Update/Binding Ack messages,
Return Routability signaling, Mobile Prefix Discovery messages and
optionally payload traffic. The CREATE_CHILD_SA exchanges are
protected by the security association created during the IKE_AUTH
exchange.
It is important that the security associations are created based on
the home address of the mobile node, so that the security
Devarapalli Expires August 24, 2005 [Page 15]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
associations survive Care-of Address change. The mobile node MUST
set the TSi (Traffic Selector-initiator) payload to its home address
in the CREATE_CHILD_SA exchange in order to create the security
associations for the home address.
Mobile Node Home Agent
----------- ----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}
Devarapalli Expires August 24, 2005 [Page 16]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
6. The use of EAP authentication
In addition to using public key signatures and shared secrets, EAP
[10] can be used with IKEv2 for authenticating the mobile node to the
Home Agent.
The mobile node indicates that it wants to use EAP by including the
IDi payload but leaving out the AUTH payload in the first message
during the IKE_AUTH exchange. The Home Agent then includes an EAP
payload if it is willing to use an extensible authentication method.
Security associations are not created until the subsequent IKE_AUTH
exchange after successful EAP authentication. The use of EAP adds at
least two round trips to the IKE negotiation.
Mobile Node Home Agent
------------ ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr}-->
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP }
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi,
TSr}
Some EAP methods generate a shared key on the mobile node and the
Home Agent once the EAP authentication succeeds. In this case, the
shared key is used to generate the AUTH payloads in the subsequent
messages. The shared key, if used to generate the AUTH payloads,
MUST NOT be used for any other purpose. For more details, refer to
[4].
The use of EAP between the mobile node and the Home Agent might
require the Home Agent to contact an authorization server like the
AAA Home server, on the home link, to authenticate the mobile node.
Please refer to [7] for more details.
The IKEv2 specification [4] requires that public key based mechanism
Devarapalli Expires August 24, 2005 [Page 17]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
be used to authenticate the Home Agent to the mobile node, when EAP
is used. But, if the EAP method that is used, supports mutual
authentication and and key generation, then the mobile node could use
EAP itself to authenticate the Home Agent. The mobile node can
request that the Home Agent also use EAP to authenticate itself, by
including the EAP_ONLY_AUTHENTICATION notification payload [8] in
message 3. If the Home Agent agrees to use EAP, it omits the public
key based AUTH and CERT payloads in message 4. More details can be
found in [8].
Devarapalli Expires August 24, 2005 [Page 18]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
7. Dynamic Home Address Configuration
The mobile node can dynamically configure a home address by including
a Configuration Payload in the IKE_AUTH exchange, with a request for
an address from the home link. The mobile node should include an
INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The
mobile node MAY also include the INTERNAL_IP6_SUBNET attribute if it
wants to obtain information about the IPv6 prefixes on the home link.
If the mobile node wants to configure a DNS server from the home link
it can request for the DNS server information by including an
INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload.
When the Home Agent receives a configuration payload with a
CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home
address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in
the CFG_REPLY contains the prefix length of the home prefix in
addition to a 128 bit home address. The Home Agent could use a local
database or contact a DHCPv6 server on the home link to allocate a
home address. The Home Agent should also include an
INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the
duration for which the dynamically allocated home address is valid.
Mobile Node Home Agent
----------- ----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr}
-->
<-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2,
TSi, TSr}
The mobile node could suggest a home address that it wants to use in
the CFG_REQUEST. For example, this could be a home address that it
was allocated before or could be an address the mobile node
auto-configured from the IPv6 prefix on the home link. The Home
Agent could let the mobile node use the same home address by setting
the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the
same home address. If the Home Agent wants the mobile node to use a
different home address, it sends a new home address in the
INTERNAL_IP_ADDRESS attribute in the CFG_REPLY payload. The Mobile
Node MUST stop using its old home address and start using the newly
allocated home address.
In case the Home Agent is unable to allocate a home address for the
mobile node during the IKE_AUTH exchange, it MUST send a Notify
Payload with an INTERNAL_ADDRESS_FAILURE message.
Devarapalli Expires August 24, 2005 [Page 19]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
If the CFG_REQUEST from the mobile node had the INTERNAL_IP6_SUBNET
attribute, the Home Agent SHOULD send prefix information for the all
prefixes on the home link. Note, that this prefix information in the
INTERNAL_IP6_SUBNET does not carry all the information that is
typically present when received through a router advertisement. The
mobile node should still rely on Mobile Prefix Discovery [2] to
obtain complete information about the prefixes on the home link.
Devarapalli Expires August 24, 2005 [Page 20]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
8. Security Considerations
This document describes how IPsec can be used to secure Mobile IPv6
signaling messages. Please refer to RFC 3775 and RFC 3776 for
security considerations related to the use of IPsec with Mobile IPv6.
Devarapalli Expires August 24, 2005 [Page 21]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
9. IANA Considerations
This document requires no action from IANA.
Devarapalli Expires August 24, 2005 [Page 22]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
10. Acknowledgements
The author would like to thank Mika Joutsenvirta and Pasi Eronen for
reviewing the draft.
Devarapalli Expires August 24, 2005 [Page 23]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
11. References
11.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004.
[5] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", Internet-Draft draft-ietf-ipsec-rfc2401bis-05,
December 2004.
[6] Kent, S., "IP Encapsulating Security Payload (ESP)",
Internet-Draft draft-ietf-ipsec-esp-v3-09, October 2004.
11.2 Informative References
[7] Giaretta, G., "Goals for AAA-HA interface",
Internet-Draft draft-giaretta-mip6-aaa-ha-goals-00, September
2004.
[8] Eronen, P., "Extension for EAP Authentication in IKEv2",
Internet-Draft draft-eronen-ipsec-ikev2-eap-auth-02, October
2004.
[9] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[11] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
Devarapalli Expires August 24, 2005 [Page 24]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 2005
Author's Address
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: vijay.devarapalli@nokia.com
Devarapalli Expires August 24, 2005 [Page 25]
Internet-Draft Mobile IPv6 with IKEv2 and revised IPsec February 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.
Devarapalli Expires August 24, 2005 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-21 10:30:27 |