One document matched: draft-laganier-mext-cga-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ebalard-mext-m6t PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ebalard-mext-m6t.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY rfc3971 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>
<!ENTITY rfc3972 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml'>
<!ENTITY rfc5533 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533.xml'>
<!ENTITY rfc4866 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4866.xml'>
<!ENTITY rfc4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
<!ENTITY rfc5213 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
<!ENTITY rfc5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'>
<!ENTITY rfc5648 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5648.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="exp" ipr="trust200902">
<!--rfc category="std" ipr="pre5378Trust200902"-->
<front>
<title abbrev="MIPv6 Binding Updates CGA Authorization">
Authorizing Mobile IPv6 Binding Update with Cryptographically Generated Addresses
</title>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="Qualcomm Inc.">
Qualcomm Incorporated
</organization>
<address> <postal>
<street>5775 Morehouse Drive
</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>USA</country>
</postal>
<phone>+1 858 658 3538</phone>
<email>julienl@qualcomm.com</email>
</address>
</author>
<date year="2010"/>
<abstract>
<t>
The standard RFC 3775 mechanism to secure Mobile IPv6 Binding Updates
sent by a Mobile Node to its Home Agent relies on the use of a pair of
unidirectional IPsec security associations between these two nodes.
The standard mechanism to secure Mobile IPv6 Binding Updates sent by a
Mobile Node to one of its Correspondent Nodes relies on the use of a
return routability test that involves the Correspondent Node verifying
reachability of the Mobile Node at both its Home Address and its
Care-of Address. The mechanism also requires the correspondent node to
send keying material to both of these addresses.
</t>
<t>
RFC 4866 specifies a standard track mecanism that allows a Mobile Node
that has configured a Cryptographically Generated Address (RFC 3972) as
its Home Address to secure Mobile IPv6 Binding Updates sent its
Correspondent Nodes based on the properties of its Cryptographically
Generated Addresses. Note that Cryptographically Generated Addresses
have also been used to counter similar security issues in the context
of SHIM6 (RFC 5533) and Secure Neighbor Discovery (RFC 3971.)
</t>
<t>
This memo proposes a mechanism that would let a Mobile Node use a
similar mechanism to secure Mobile IPv6 Binding Updates its sent to its
Home Agent with a similar technique based on the use of
Cryptographically Generated Addresses.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The standard <xref target="RFC3775">RFC 3775</xref> mechanism to secure
Mobile IPv6 Binding Updates sent by a Mobile Node to its Home Agent
relies on the use of a pair of unidirectional IPsec security
associations between these two nodes <xref target="RFC4877"/>. The
standard mechanism to secure Mobile IPv6 Binding Updates sent by a
Mobile Node to one of its Correspondent Nodes relies on the use of a
return routability test that involves the Correspondent Node verifying
reachability of the Mobile Node at both its Home Address and its
Care-of Address. The mechanism also requires the correspondent node to
send keying material to both of these addresses.
</t>
<t>
<xref target="RFC4866">RFC 4866</xref> specifies a standard track
mecanism that allows a Mobile Node that has configured a
Cryptographically Generated Address <xref target="RFC3972"/> as its
Home Address to secure Mobile IPv6 Binding Updates sent its
Correspondent Nodes based on the properties of its Cryptographically
Generated Addresses. Note that Cryptographically Generated Addresses
have also been used to counter similar security issues in the context
of SHIM6 <xref target="RFC5533"/> and Secure Neighbor Discovery <xref
target="RFC3971"/>.
</t>
<t>
This memo proposes a mechanism that would let a Mobile Node use a
similar mechanism to secure Mobile IPv6 Binding Updates its sent to its
Home Agent with a similar technique based on the use of
Cryptographically Generated Addresses.
</t>
</section>
<section title="Disclaimer">
<t> This Internet Draft is still Work in Progress. </t>
</section>
<section title="Requirement Levels Key Words">
<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>
<section title="Terminology">
<t>
Other terms used throughout this document are defined in the
relevant documents: <xref target="RFC3775"/>, <xref
target="RFC4866"/>, <xref target="RFC3972"/>.
</t>
</section>
<section title="Usage Scenario">
<t>
The mechanism described herein is useful in situations where
there is a desire not to depend on IPsec for protection of the
Mobile IPv6 signaling between the Mobile Node and the Home Agent.
</t>
</section>
<!--
<figure anchor="fig:bu_first" title="Home Registration and establishment of new semi-permanent Home Keygen Token"><artwork><![CDATA[
Mobile node Home agent
| |
| |
|---------------- Binding Update ------------------>|
| |
|<-------- Binding Ack + Home Keygen Token ---------|
| |
| |
]]></artwork></figure>
<t>
</t>
<figure anchor="fig:bu_next" title="Home registration with authentication based on semi-permanent Home Keygen Token"><artwork><![CDATA[
Mobile node Home agent
| |
| |
~ Handoff |
| |
|------------------ Binding Update ---------------->|
| |
|<------------------ Binding Ack -------------------|
| |
| |
]]></artwork></figure>
-->
<section title="Mobile Node Operation">
<t>
A Mobile Node sends a Binding Update message to its Home Agent when any of the following applies:
<list style="symbols">
<t>
It is needs to establish a new binding because it is
away from the home link and first attaches to a foreign
link.
</t>
<t>
It attaches to a different foreign link and needs to update the
binding with its new care-of address.
</t>
<t>
It needs to refresh a binding because it is
about to expire.
</t>
<t>
It needs to acquire a new permanent home keygen token for the binding,
either because it does not have one yet, or because the current permanent
home keygen token is going to become unusable due to the sequence number
being about to roll over since the token was acquired.
</t>
<t>
It needs to deregister an existing binding.
</t>
</list>
In any of these cases, the Mobile Node sends a Binding Update message to the
home agent. The Binding Update message is authenticated by one of the
following two authentication methods:
<list style="symbols">
<t>
If the Mobile Node does not have a usable permanent home keygen token in its
Binding Update List entry for the home agent, the mobile node MUST
authenticate the Binding Update message based on the CGA property of its
home address. The Binding Update message MUST omit the Binding Authorization
Data option and MUST include the following options:
<list style="symbols">
<t>a CGA Parameters option for the Cryptographically Generated Home Address of the Mobile Node as per <xref target="RFC4866"/>.</t>
<t>a Timestamp option as per <xref target="RFC5213"/>.</t>
<t>a Signature option as per <xref target="RFC4866"/>.</t>
</list>
</t>
<t>
If the Mobile Node has a usable permanent home keygen token in its Binding
Update List entry for the home agent, the mobile node MUST authenticate the
Binding Update message by a proof of its knowledge of the permanent home
keygen token. The Binding Update message MUST omit the CGA Parameters, Timestamp, and Signature options and MUST include the following option:
<list style="symbols">
<t> a Binding Authorization Data option whose authenticator for
the Binding Update message is calculated based on the
permanent home keygen token alone. The care-of keygen
token is set to zero while calculating the
authenticator.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Home Agent Operation">
<t>
A Home Agent MUST accept a Binding Update message from a Mobile
Node and maintain accordingly the corresponding Binding Cache
Entry if the Binding Update message can be authenticated as
follows:
<list style="symbols">
<t>
If the Binding Update message does not contain a Binding Authorization Data
option, the Mobile Node does not have a usable permanent home keygen token
in its Binding Update List entry for the home agent, and the Home AGent MUST
authenticate the Binding Update message based on the CGA property of the
Mobile Node home address. The Binding Update message MUST include the
following options:
<list style="symbols">
<t>a CGA Parameters option for the Cryptographically Generated Home Address of the Mobile Node as per <xref target="RFC4866"/>.</t>
<t>a valid Timestamp option as per <xref
target="RFC5213"/>. That is, if
there is no existing Binding Cache Entry, the
time offset between the Timestamp and local
Home Agent clock is recorded in the Binding
Cache Entry. If there exists a Binding Cache
Entry, the Timestamp MUST not differ from
the local Home Agent clock for more than 1.5
times the time offset recorded in the Binding
Cache Entry.</t>
<t>a valid Signature option as per <xref target="RFC4866"/>.</t>
</list>
</t>
<t>
If the Binding Update message contains a Binding Authorization Data option, the Mobile Node has a usable permanent home keygen token in its Binding
Update List entry for the home agent, and the Home Agend MUST authenticate the
Binding Update message by proof of the Mobile Node's knowledge of the permanent home keygen token by verifying that the
authenticator in the Binding Authorization Data option
is calculated based on the
permanent home keygen token with the care-of keygen
token set to zero.
</t>
</list>
If the Binding Update message has been authenticated based on the CGA property of the Mobile Node home address, the Home Agent MUST include a new permanent Home Keygen Token in the Binding Acknowledgment.
</t>
</section>
<section title="IPv4 Support">
<t> This mechanism can be used when the Mobile Node is attached to an IPv4-only foreign link by leveraging on <xref target="I-D.ebalard-mext-m6t"/>. IPv4 applications can be supported via assigning an IPv4 Home Address as described in <xref target="RFC5555"/>.
</t>
</section>
<section title="IANA Considerations">
<t>
There are no IANA considerations yet for this specification.
</t>
</section>
<section title="Security Considerations">
<t>
There are no security considerations yet for this document.
</t>
</section>
<section title="Acknowledgment">
<t>
The author acknowledge prior work in the area of Mobile IPv6
security based on Cryptographically Generated Addresses,
Statistically Unique and Crypgraphically Verifiable Identifiers,
and more.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3775;
&rfc3972;
&rfc4866;
&rfc5213;
&rfc5555;
&I-D.ebalard-mext-m6t;
</references>
<references title="Informative References">
&rfc3971;
&rfc4877;
&rfc5533;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:24:23 |