One document matched: draft-patil-mext-sec-negotiate-03.xml
<?xml version="1.0" encoding="US-ASCII" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
<!ENTITY RFC4862 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
<!ENTITY RFC3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY RFC3776 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3776.xml'>
<!ENTITY RFC4285 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4285.xml'>
<!ENTITY RFC4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
<!ENTITY I-D.draft-ietf-mext-mip6-tls-02 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mext-mip6-tls-02.xml'>
<!ENTITY I-D.laganier-mext-cga PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.laganier-mext-cga.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocappendix="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
docName="draft-patil-mext-sec-negotiate-03"
ipr="trust200902">
<front>
<title abbrev="Security protocol negotiation">Negotiation of
security protocol for Mobile IPv6 operation
</title>
<author role ="editor" fullname="Bruno Faria" initials="B" surname="Faria">
<organization>Nokia Institute of Technology</organization>
<address>
<postal>
<street>Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova</street>
<city>Manaus</city>
<region>AM</region>
<code>69048-660</code>
<country>BRAZIL</country>
</postal>
<email>bruno.faria@indt.org.br</email>
</address>
</author>
<author fullname="Basavaraj Patil" initials="B" surname="Patil">
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection drive</street>
<city>Irving</city>
<region>TX</region>
<code>75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<author initials="G" surname="Bajko" fullname="Gabor Bajko">
<organization>Nokia</organization>
<address>
<postal>
<street>323 Fairchild drive 6</street>
<city>Mountain view</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>gabor.bajko@nokia.com</email>
</address>
</author>
<date year="2011" />
<area>Internet</area>
<workgroup>Individual Submission</workgroup>
<keyword>Mobility</keyword>
<keyword>Mobile IPv6</keyword>
<keyword>Security</keyword>
<keyword>IKEv2</keyword>
<keyword>Home Agent</keyword>
<abstract>
<t>
Mobile IPv6 has relied on IPsec and IKEv2 for securing the
signaling and user traffic. A single security mechanism for
Mobile IPv6 does not adequately address various deployment
scenarios. The one-size-fits-all security approach is ill
suited for Mobile IPv6, as different deployments have different
security requirements. Multiple alternatives to securing
signaling and user traffic have been proposed and are being
considered for standardization. When multiple security
protocols coexist for providing security for mobile IPv6 nodes,
there is a need to negotiate the choice of security protocol between a
mobile node and home agent a priori. This document proposes a
method for negotiating the security protocol to be used between
mobile IPv6 nodes.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Mobile IPv6 has relied on IPsec and IKEv2 for securing the
signaling and user traffic. A single security mechanism for
Mobile IPv6 does not adequately address various deployment
scenarios. The one-size-fits-all security approach is ill
suited for Mobile IPv6, as different deployments need different
security requirements. Multiple alternatives to securing
signaling and user traffic have been proposed and are being
considered for standardization. When multiple security
protocols coexist for providing security for mobile IPv6 nodes,
there is a need to negotiate the choice of security protocol between a
mobile node and home agent a priori. This document proposes a
method for negotiating the security protocol to be used between
mobile IPv6 nodes based on the home agent controller (HAC) entity
defined in <xref target="I-D.ietf-mext-mip6-tls" />.
</t>
<t>
Mobile IPv6 <xref target="RFC3775" /> security using IPsec and
IKE is specified in <xref target="RFC3776" /> and
<xref target="RFC4877"/>.
A number of alternate security protocols for use by mobile IPv6
nodes have been proposed. Authentication protocol for Mobile
IPv6 <xref target="RFC4285" /> is an example of one such. The
use of such a mechanism is however restricted to networks with
certain characteristics that are documented in the RFC.
</t>
<t>
More recently, other security mechanisms for use in Mobile IPv6
deployments have been proposed. Transport Layer Security-based
Mobile IPv6 Security Framework for Mobile Node to Home Agent
Communication
<xref target="I-D.ietf-mext-mip6-tls" /> proposes a
security solution that uses TLS between the mobile node (MN)
and a home agent controller (HAC) to bootstrap Mobile IPv6 and the
security protocol parameters between the MN and home agent (HA).
Authorizing Mobile IPv6 Binding Update with Cryptographically
Generated Addresses
<xref target="I-D.laganier-mext-cga"/> proposes the use of CGA
for securing the signaling between an MN and HA.
</t>
</section>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119"/>.
</t>
<section title="Terminology">
<t>
The terminology used in this I-D is based on the Mobile IPv6 terminology
defined in <xref target="RFC3775"/>.
</t>
<t>
<list style="hanging">
<t hangText="Home Agent Controller (HAC)">
<vspace blankLines="1"/>
The home agent controller is a node responsible for bootstrapping
Mobile IPv6 security associations between a mobile node and one or
more home agents. The home agent controller also provides key
distribution to both mobile nodes and home agents. Optionally,
Mobile IPv6 bootstrapping can be done in addition to the security
association bootstrapping between the mobile node and home agent
controller.
</t>
</list>
</t>
</section>
</section>
<section title="Problem Statement">
<t>
Security for Mobile IPv6 signaling and user traffic can be
achieved via the use of different mechanisms. At the present time
the use of IPsec and IKEv2 is mandated and choice of any other
security protocol does not exist. However the use of IPsec and IKE
for providing security does not fit all deployments. Alternate
security solutions have been proposed and could be used. The use
of a security protocol by mobile IPv6 nodes should be driven by
the needs and requirements of a specific deployment. An enterprise
deployment of Mobile IPv6 will have a different set of security
requirements as compared to a cellular operator offering mobile
IPv6 service.
</t>
<t>
When Mobile IPv6 hosts have the option of choosing from multiple
security protocols, there is a need to negotiate the use of a
specific protocol between a mobile node and home agent prior to
operation. This problem is dealt with in the scope of this draft
and solutions proposed.
</t>
</section>
<section title="Using the Home agent controller">
<t>
The home agent controller (HAC) is an entity that is defined in
<xref target="I-D.ietf-mext-mip6-tls"/>. The HAC provides the MN with
bootstrapping information of Mobile IPv6 such as assigned HA address,
Home Network Prefix and MN IPv6 and/or IPv4 HoA.
In addition, it assigns security parameters information to constitute
the MN-HA security association. The HAC can generate IPSec SA information
such as keys and SPI and provide it to the MN through the secure TLS secure
connection without the use of IKEv2 for this purpose.
The security association information is distributed by the HAC to the HA
assigned to be used by the MN.
</t>
<t>
In the proposed solution, the HAC is the central entity which plays the
role of negotiating the security protocol to be used between a mobile node
and the home agent. The HAC is aware of the capabilities and security
protocols of various home agents that it is associated with. An MN MUST
contact the HAC to obtain the home agent and home address to use.
The MN can also inform the HAC about the security protocols that it supports
and can use for securing signaling and user traffic. Based on the security
protocols the MN informed, the HAC will then assign the MN a valid home agent
in addition to informing it of the security protocol to be used.
Optionally, if the communication between the MN and the HA is to be protected
by IPSec, the HAC may provide the MN and the assigned HA the relevant
security parameters such as keys, SPI, ciphers etc. that constitutes an
IPsec SA. The MN may be configured with the address of HACs or
alternatively it may discover a HAC via DNS. This is dealt with in the
<xref target="I-D.ietf-mext-mip6-tls"/> document.
</t>
</section>
<section title="Negotiation of security protocol">
<t>
The mobile node establishes a TLS connection with the home agent
controller (HAC) and exchanges a set of messages via this secure TLS
tunnel to bootstrap mobile IPv6 as well as negotiate the choice of
security protocol. The security protocol information is exchanged using
the Request-Response messaging within the TLS secure tunnel.
The signaling flow diagram below illustrates this negotiation mechanism:
<figure title="Negotiation of security protocol for use
between MN and HA"
anchor="fig:secnegotiate">
<artwork><![CDATA[
MN HAC HA AAA
| | | |
|<===TLS connection====>|(1) | |
| | | |
|-Indicate capability-->|(2) | |
| | | |
| |<--Obtain profile, security-------->|(3)
|<--Security protocol---|(4) | |
| |--MN_ID, Sec----->|(5) |
| | | |
|<------Establish SA --------------------->|(6) |
| | | |
|<--------BU/BAck------------------------->| |
| | | |
| | | |
]]></artwork></figure>
</t>
<t>
<list style="numbers">
<t>The MN establishes a TLS connection with the HAC and
authenticates itself. Authentication details are described in
<xref target="I-D.ietf-mext-mip6-tls"/>. All subsequent
messaging between the MN and HAC is within the secure TLS
connection.
</t>
<t>The MN signals the security protocols that it supports
including ciphersuite and capabilities.
</t>
<t>The HAC obtains the MNs profile and allowed security methods
for the MN from the AAA server. The Home agent to be assigned to
the MN is also informed by the AAA. The HAC chooses the
security protocol to be used based on the capabilities of the MN
as well as policy information from the AAA.
</t>
<t>The HAC indicates the security protocol to be used by the
MN. It also provides the MN with the security parameters such as encryption
and integrity keys, SPI, and ciphers to be used for establishing the
SA with the allocated HA.
</t>
<t>The HAC also indicates to the assigned HA information about
the MN and selected security protocol. Additionally security
parameters required for establishing the SA are delivered to the
HA.
</t>
<t>The MN establishes the security association of the type
indicated by the HAC. This could be an IPsec SA, or it could be
the use of the SA defined in
<xref target="I-D.ietf-mext-mip6-tls"/>, the use of CGA or the use of Mobility
Security Association as defined in <xref target="RFC4285" />.
</t>
<t>The MN performs registration with the HA. The BU/BAck are
secured using the security protocol that has been chosen.
</t>
</list>
</t>
<section title="Security Negotiation of Authentication Protocol for MIPv6">
<t>
This section describes the use of the proposed security negotiation
protocol to negotiate the use of Authentication Protocol for MIPv6
as specified in <xref target="RFC4285" />. That method can be applicable
in network deployments where the home agent and home address is
dynamically assigned to the mobile node and the security association
is created via an out-of-band mechanism. That information is distribuited
by the home agent controller via the TLS session established with the
mobile node. The HAC fetches the security parameters that forms a mobility
based security association from the AAA server and distribuite them to
the mobile node and assigned home agent like security keys.
</t>
<t>
The mobile node establishes a TLS connection with the home agent controller
and exchange a set of messages via this secure TLS tunnel to bootstrap
mobile IPv6. The MN indicates the Authentication Protocol for MIPv6 as
a supported security protocol. The diagram below illustrates
the negotiation of Authentication Protocol for MIPv6 as the security
protocol to be used:
<figure title="Negotiation of Authentication Protocol for MIPv6
as the security protocol for use between MN and HA"
anchor="fig:rfc4285negotiate">
<artwork><![CDATA[
MN HAC HA AAA
| | | |
|<===TLS connection====>|(1) | |
| | | |
|---Indicate RFC4285--->|(2) | |
| as security protocol | | |
| |<--Obtain profile, security-------->|(3)
|<---Set RFC4285 as --->|(4) | |
| security protocol | | |
| |--MN_ID, Sec----->|(5) |
| | | |
|<------Establish SA --------------------->|(6) |
| | | |
|<--------BU/BAck------------------------->| |
| | | |
| | | |
]]></artwork></figure>
</t>
<list style="numbers">
<t>
The MN establishes a TLS session with the HAC and authenticates itself
as described in <xref target="I-D.ietf-mext-mip6-tls"/>. All
subsequent messaging between the MN and HAC is within the secure
TLS connection
</t>
<t>
The MN indicates that it wants to use the Authentication Protocol
for MIPv6 as the security protocol. It should also inform
its capabilities based on the type of access network and the
security services that it provides.
</t>
<t>
The HAC obtains the MNs profile along with its allowed security
methods from the AAA server. The Home Agent to be assigned to
the MN is also informed by the AAA. Based on the MN capabilities
and policy information from the AAA, the HAC chooses
the RFC4285 as the security protocol to be used.
</t>
<t>
The HAC indicates the security protocol to be used by the MN.
The HAC also provides the information that composes a mobility
security association between the MN and the HA like mobility
SPI, keys, authentication algorithm and replay protection mechanism.
</t>
<t>
The HAC provides the assigned HA with information about the
Authentication Protocol for MIPv6. It also provides security
parameters required for establishing the mobility security association.
</t>
<t>
The MN and HA establish the mobility security association
just provided by the HAC.
</t>
<t>
The MN performs registration with the HA including the MN-HA mobility
message authentication option with in the BU message.
</t>
</list>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document does not have any IANA requests at the present time.
</t>
</section>
85
<section anchor="Security" title="Security Considerations">
<t>
The signaling between the mobile node and home agent controller is
secured by TLS. All the messages between the MN and HAC are
tunneled within the TLS connection and hence secured. The MN and
Home agent (HA) are either colocated or have a secure messaging
interface between them.
There exists the potential to downgrade the choice of the security
protocol between an MN and HA. However the HAC chooses the
security protocol to be used based on the capabilities of the MN
as well as policy information from an entity such as AAA. In case
the MN is incapable of more robust secure mechanisms, the HAC may
assign such a home agent with limited capabilities and
connectivity.
</t>
</section>
<section anchor="Summary" title="Summary and Conclusion">
<t>
The choice of security protocols to be used in mobile IPv6
deployments increases the flexibility of the protocol and makes
it viable for use in different deployment scenarios. This
however does result in the need for negotiation of a security
protocol to be used between the MN and HA. The capabilities of
the MN and home agents available for use to an MN determine the
security protocol that can be used. Use of a home agent
controller provides Mobile IPv6 with a robust mechanism for
bootstrapping as well negotiation the security protocol.
</t>
</section>
<!-- <section title="Acknowledgements"> -->
<!-- <t> -->
<!-- The authors thank X, Y, Z. -->
<!-- </t> -->
<!-- </section> -->
</middle>
<back>
<references title="Normative References">
&I-D.draft-ietf-mext-mip6-tls-02;
&RFC2119;
&RFC3775;
&RFC3776;
&RFC4877;
&RFC4285;
</references>
<references title="Informative References">
&I-D.laganier-mext-cga;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:15:39 |