One document matched: draft-ietf-mext-mip6-tls-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4282 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml'>
<!ENTITY RFC4283 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4283.xml'>
<!ENTITY RFC4346 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml'>
<!ENTITY RFC5077 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml'>
<!ENTITY RFC6275 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml'>
<!ENTITY RFC3776 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3776.xml'>
<!ENTITY RFC4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
<!ENTITY RFC2818 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>
<!ENTITY RFC3602 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3602.xml'>
<!ENTITY RFC2410 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2410.xml'>
<!ENTITY RFC2451 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2451.xml'>
<!ENTITY RFC2404 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2404.xml'>
<!ENTITY RFC3566 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3566.xml'>
<!ENTITY RFC0768 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'>
<!ENTITY RFC5996 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
<!ENTITY RFC4301 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY RFC4303 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml'>
<!ENTITY RFC5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY RFC3948 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3948.xml'>
<!ENTITY RFC5944 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5944.xml'>
<!ENTITY RFC5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'>
<!ENTITY RFC5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY RFC4648 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml'>
<!ENTITY I-D.patil-mext-mip6issueswithipsec PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.patil-mext-mip6issueswithipsec.xml'>
<!ENTITY RFC4279 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml'>
<!ENTITY RFC2617 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
<!ENTITY RFC4086 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml'>
<!ENTITY RFC2616 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY RFC3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY RFC5433 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5433.xml'>
<!ENTITY RFC5056 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY RFC5929 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc ipr="trust200902" category="exp" docName="draft-ietf-mext-mip6-tls-03.txt">
<front>
<title abbrev="TLS-based MIPv6 Security Framework">Transport Layer Security-based Mobile IPv6
Security Framework for Mobile Node to Home Agent Communication</title>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen" role="editor">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>FIN-02600</code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author initials="B" surname="Patil" fullname="Basavaraj Patil">
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection Drive</street>
<city>Irving,</city>
<code>TX 75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
</address>
</author>
<author initials="D." surname="Kroeselberg" fullname="Dirk Kroeselberg">
<organization>Siemens</organization>
<address>
<!--postal>
<street>St.-Martin-Str. 53</street>
<city>Munich</city>
<code>81541</code>
<country>Germany</country>
</postal-->
<email>dirk.kroeselberg@siemens.com</email>
</address>
</author>
<date year="2012"/>
<area>Internet</area>
<workgroup>Mobility Extensions (MEXT)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Mobile IPv6</keyword>
<keyword>Security</keyword>
<abstract>
<t>Mobile IPv6 signaling between a mobile node and its home
agent is secured using IPsec. The security association
between a mobile node and the home agent is established
using IKEv1 or IKEv2. The security model specified for
Mobile IPv6, which relies on IKE/IPsec, requires
interaction between the Mobile IPv6 protocol component
and the IKE/IPsec module of the IP stack. This document
proposes an alternate security framework for Mobile IPv6 and
Dual-Stack Mobile IPv6, which relies on Transport
Layer Security for establishing keying material and other
bootstrapping parameters required to protect Mobile
IPv6 signaling and data traffic between the mobile node
and home agent. </t>
</abstract>
</front>
<middle>
<!-- ================================================================== -->
<section anchor="introduction" title="Introduction">
<t>Mobile IPv6 <xref target="RFC6275"/> signaling, and optionally user
traffic, between a mobile node (MN) and home agent (HA) are secured
by IPsec <xref target="RFC4301"/>. The current Mobile IPv6
security architecture is specified in <xref target="RFC3776"/> and
<xref target="RFC4877"/>. This security model requires a tight
coupling between the Mobile IPv6 protocol part and the
IKE(v2)/IPsec part of the IP stack. Client implementation experience
has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly
complex.
</t>
<t>This document proposes an alternate security framework for Mobile
IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify
implementations as well as make it easy to deploy the protocol
without compromising on security. Transport Layer Security (TLS)
<xref target="RFC5246"/> is widely implemented in almost all major
operating systems and extensively used by various applications.
Instead of using IKEv2 to establish security associations, the
security framework proposed in this document is based on TLS
protected messages to exchange keys and bootstrapping parameters
between the Mobile Node and a new functional entity called as the
Home Agent Controller (HAC). The Mobile IPv6 signaling between the
mobile node and home agent is subsequently secured using the
resulting keys and negotiated cipher suite. The HAC can be
co-located with the HA, or can be an independent entity. For the
latter case, communication between HAC and HA is not defined by
this document. Such communication could be built on top of AAA
protocols such as Diameter, for instance.
</t>
<t>The primary advantage of using TLS based establishment of Mobile IP6
security associations compared to IKEv2 is the ease of implementation
while providing an equivalent level of security. For the protection of
signaling messages and user plane traffic a solution is provided
that decouples Mobile IPv6 security from IPsec, thereby reducing
client implementation complexity.
</t>
<t>The security framework proposed in this document is not intended to
replace the currently specified architecture which relies on IPsec
and IKEv2. It provides an alternative solution which is more optimal
for certain deployment scenarios. This and other alternative
security models have been considered by the MEXT working group at
the IETF, and it has been decided that the alternative solutions
should be published as Experimental RFCs, so that more
implementation and deployment experience with these models can be
gathered. The working group may reconsider the status of the
different models in the future, if it becomes clear that one is
superior to the others.
</t>
</section>
<!-- introduction -->
<!-- ================================================================== -->
<section anchor="terms" title="Terminology and Abbreviations">
<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>
<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. Mobile IPv6 bootstrapping is also performed by the HA in addition to the security association bootstrapping between the
mobile node and home agent controller. <vspace blankLines="1"/>
</t>
<t hangText="Binding Management Messages:">
<vspace blankLines="1"/>
Mobile IPv6 signaling messages between a mobile node and a home
agent, correspondent node or mobility access point to manage the
bindings are referred to as binding management messages. Binding
Updates and Binding Acknowledgement messages are examples of
binding management messages.<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<!-- terminology -->
<!-- ================================================================== -->
<section title="Background">
<t>Mobile IPv6 design and specification was begun in the mid to late
90s. The security architecture of Mobile IPv6 was based on the
understanding that IPsec is an inherent and integral part of the
IPv6 stack and any protocol that needs security should use IPsec
unless there is a good reason not to. As a result of this mindset
the Mobile IP6 protocol relied on the use of IPsec for security
between the MN and HA. While reuse of security components that are
part of the IP stack is a good objective, in the case of Mobile
IPv6, implementation complexity increases. It should be noted that
Mobile IPv4 <xref target="RFC5944"/> for example does not use IPsec
for security and instead has specified its own security solution.
Mobile IPv4 has been implemented and deployed on a reasonably large
scale and the security model has proven itself to be sound.
</t>
<t>Mobile IPv6 standardization was completed in 2005 along with the
security architecture using IKE/IPsec specified in RFC 3776 <xref
target="RFC3776"/>. With the evolution to IKEv2 <xref
target="RFC5996"/>, Mobile IP6 security has also been updated to
rely on the use of IKEv2 <xref target="RFC4877"/>. Implementation
exercises of Mobile IPv6 and Dual-stack Mobile IPv6 <xref
target="RFC5555"/> have identified the complexity of using IPsec
and IKEv2 in conjunction with Mobile IPv6. Implementing Mobile IPv6
with IPsec and IKEv2 requires modifications to both the IPsec and
IKEv2 components, due to the communication models that Mobile IPv6
uses and the changing IP addresses. For further details, see
Section 7.1 in <xref target="RFC3776"/>.
</t>
<t>This document proposes a security framework based on TLS protected
establishment of Mobile IPv6 security associations with reduced
implementation complexity, while maintaining an equivalent (to IKEv2/
IPsec) level of security.
</t>
</section>
<!-- ================================================================== -->
<section title="TLS-based Security Establishment">
<section title="Overview">
<t>
The security architecture proposed in this document relies on a
secure TLS session established between the MN and the HAC for
authentication and MN-HA security association bootstrapping.
Authentication of the HAC is done via standard TLS operation wherein
the HAC uses a TLS server certificate as its credentials. MN
authentication is done by the HAC via signaling messages that are
secured by the TLS connection. Any EAP method can be used for
authenticating the MN to the HAC. Upon successful completion of
authentication, the HAC generates keys which are delivered to the MN
through the secure TLS channel. The same keys are also provided to
the assigned HA. The HAC also provides the MN with MIP6
bootstrapping information such as the IPv6 and IPv4 address of the
HA, the Home network prefix, the IPv6 and/or IPv4 HoA and, DNS
server address.
</t>
<t>
The MN and HA use security associations based on the keys and SPIs generated by the HAC and delivered to the MN and HA to secure
signaling and optionally user plane traffic. <xref target="arch-hl"/> below is an illustration of the process.
</t>
<t>Signaling messages and user plane traffic between the MN and HA are
always UDP encapsulated. The packet formats for the signaling and
user plane traffic is described in Sections <xref target="bmmmsg" format="counter"/> and <xref target="dtamsg" format="counter"/>.
</t>
<figure anchor="arch-hl" title="High level architecture">
<artwork><![CDATA[
MN HAC HA
-- --- --
| | |
| /-------------------------\ | |
|/ \| |
|\ TLS session setup /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ MN Authentication \| |
|\ /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ HAC provisions the MN \| |
|\ keys, SPI and MIP6 parms /| |
| \-------------------------/ | |
| |--MNID, keys, SPI->|
| | |
| /--------------------------------------------\ |
|/ MN-HA SA established; Secures \ |
|\ signaling and optionally user traffic / |
| \--------------------------------------------/ |
| |
|------------BU(encrypted)----------------------->|
| |
|<---------BAck(encrypted)------------------------|
]]></artwork>
</figure>
</section>
<section title="Architecture">
<t>The TLS-based security architecture is shown in <xref target="arch-altsec"/>.
The signaling message exchange between the MN and the HAC is protected by TLS. It should be
noted that a HAC, a AAA server and a HA are logically separate entities and can be
collocated in all possible combinations. There MUST be a strong trust relationship
between the HA and the HAC, and the communication between them MUST be both integrity
and confidentially protected. </t>
<figure anchor="arch-altsec" title="TLS-based Security Architecture Overview">
<artwork><![CDATA[
+------+ +------+ +------+
|Mobile| TLS |Home | AAA | AAA |
| Node |<----------->|Agent |<---------->|Server|
| | |Contrl| | |
+------+ +------+ +------+
^ ^ ^
| | |
| BU/BA/../ | e.g. AAA | AAA
| (Data) | |
| v |
| +---------+ |
| | MIPv6 | |
+--------------->| Home |<-------------+
| Agent(s)|
+---------+
]]></artwork>
</figure>
</section>
<section title="Security Association Management">
<t>Once the MN has contacted the HAC and mutual authentication has
taken place between the MN and the HAC, the HAC securely provisions the MN
with all security related information inside the TLS protected tunnel.
This security related information constitutes a security association (SA)
between the MN and the HA. The created SA MUST NOT be tied to the Care-of
Address (CoA) of the MN.
</t>
<t>The HAC may proactively distribute the SA information to HAs, or the HA may
query the SA information from the HAC once the MN contacts the HA. If the HA
requests SA information from the HAC, then the HA MUST be able to query/index
the SA information from the HAC based on the Security Parameter Index (SPI)
identifying the correct security association between the MN and the HA.
</t>
<t>The HA may want the MN to re-establish the SA even if the existing SA is still
valid. The HA can indicate this to the MN using a dedicated Status Code in a BA
(value set to REINIT_SA_WITH_HAC). As a result, the MN SHOULD contact the HAC
prior to the SA timing out, and the HAC would provision the MN and HAs with a
new SA to be used subsequently.
</t>
<t>The SA established between MN and HAC SHALL contain at least the following
information: </t>
<t>
<list style="hanging">
<t hangText="Mobility SPI:">
<vspace blankLines="1"/>This parameter is an SPI used by
the MN and the HA to index the SA between the MN and the
HA. The HAC is responsible for assigning SPIs to MNs.
There is only one SPI for both binding management messaging
and possible user data protection. The same SPI is used for
both directions between the MN and the HA. The SPI values
are assigned by the HAC. The HAC MUST ensure uniqueness of
the SPI values across all MNs controlled by the HAC.
<vspace blankLines="1"/>
</t>
<t hangText="MN-HA keys for ciphering:">
<vspace blankLines="1"/>A pair of symmetric keys (MN -> HA, HA -> MN) used
for ciphering Mobile IPv6 traffic between the MN and the HA. The HAC is
responsible for generating these keys. The key generation algorithm is
specific to the HAC implementation.
<vspace blankLines="1"/>
</t>
<t hangText="MN-HA shared key for integrity protection:">
<vspace blankLines="1"/>A pair of symmetric keys (MN -> HA, HA -> MN)
used for integrity protecting Mobile IPv6 traffic between the MN
and the HA. This includes both binding management messages
and reverse tunneled user data traffic between the MN and
the HA. The HAC is responsible for generating these
keys. The key generation algorithm is specific to the HAC
implementation. In case of combined algorithms a separate
integrity protection key is not needed and may be omitted, i.e., the
encryption keys SHALL be used.
<vspace blankLines="1"/>
</t>
<t hangText="Security association validity time:">
<vspace blankLines="1"/>This parameter represents the validity time for the
security association. The HAC is responsible for defining the lifetime value
based on its policies. The lifetime may be in the order of hours or weeks. The
MN MUST re-contact the HAC before the SA validity time ends.
<vspace blankLines="1"/>
</t>
<t hangText="Security Association Scope:">
<vspace blankLines="1"/>This parameter defines whether the
security association is applied to Mobile IPv6 signaling
messages only, or to both Mobile IPv6 signaling messages
and data traffic.
<vspace blankLines="1"/>
</t>
<t hangText="Selected ciphersuite:">
<vspace blankLines="1"/>This parameter is the ciphersuite
used to protect the traffic between the MN and the HA.
This includes both binding management messages and reverse
tunneled user data traffic between the MN and the HA. The
selected algorithms SHOULD be one of the mutually supported
ciphersuites of the negotiated TLS version between the MN
and the HAC. The HAC is responsible for choosing the
mutually supported ciphersuite that complies with the
policy of the HAC. Obviously, the HAs under HAC's
management must have at least one ciphersuite with the HAC
in common and need to be aware of the implemented
ciphersuites. The selected ciphersuite is the same for both
directions (MN -> HA and HA -> MN).
<vspace blankLines="1"/>
</t>
<t hangText="Sequence numbers:">
<vspace blankLines="1"/>A monotonically increasing
unsigned sequence number used in all protected packets exchanged between
the MN and the HA in the same direction. Sequence numbers are maintained
per direction, so each SA includes two independent sequence numbers
(MN -> HA, HA -> MN). The initial sequence number for each direction MUST
always be set to 0 (zero). Sequence numbers cycle to 0 (zero) when
increasing beyond their maximum defined value.
</t>
</list>
</t>
</section>
<section title="Bootstrapping of Additional Mobile IPv6 Parameters">
<t>When the MN contacts the HAC to distribute the security related information, the HAC may also provision the MN with various Mobile
IPv6 related bootstrapping information. Bootstrapping of the
following information SHOULD at least be possible: </t>
<t>
<list style="hanging">
<t hangText="Home Agent IP Address:">
<vspace blankLines="1"/>Concerns both IPv6 and IPv4 home agent addresses.
<vspace blankLines="1"/>
</t>
<!-- for some odd reason folks want this feature to be removed.. -->
<t hangText="Mobile IPv6 Service Port Number:">
<vspace blankLines="1"/> The port number where the HA is listening to UDP <xref target="RFC0768"/> packets.
<vspace blankLines="1"/>
</t>
<t hangText="Home Address:">
<vspace blankLines="1"/>Concerns both IPv6 and IPv4 Home Addresses.
<vspace blankLines="1"/>
</t>
<t hangText="Home Link Prefix:">
<vspace blankLines="1"/>Concerns the IPv6 Home link prefix and the
associated prefix length.
</t>
<t hangText="DNS Server Address:">
<vspace blankLines="1"/>The address of a DNS
server that can be reached via the HA. DNS
queries in certain cases cannot be routed to the
DNS servers assigned by the access network to
which the MN is attached and hence an additional
DNS server address which is reachable via the HA
needs to be configured.
</t>
</list>
</t>
<t>The Mobile IPv6 related bootstrapping information is delivered from the HAC to the MN
over the same TLS protected tunnel as the security related information. </t>
</section>
<section title="Protecting Traffic Between Mobile Node and Home Agent">
<t>The same integrity and confidentiality algorithms MUST be used
to protect both binding management messages and reverse tunneled
user data traffic between the MN and the HA. Generally, all
binding management messages (BUs, BAs and so on) MUST be integrity
protected and SHOULD be confidentially protected. The reverse
tunneled user data traffic SHOULD be equivalently protected.
Generally, the requirements stated in <xref target="RFC6275"/>
concerning the protection of the traffic between the MN and the
HA also apply to the mechanisms defined by this specification.
</t>
</section>
</section>
<!-- OK -->
<!-- ================================================================== -->
<section title="Mobile Node to Home Agent Controller Communication">
<section title="Request-response Message Framing over TLS-tunnel" anchor="record">
<t>The MN and the HAC communicate with each other using a simple
lock-step request-response protocol that is run inside the protected TLS-tunnel.
A generic message container framing for the request messages and for the
response messages is defined. The
message containers are only meant to be exchanged on top of connection
oriented TLS-layer. Therefore, the end of message exchange is determined by the
other end closing the transport connection (assuming the "application
layer" has also indicated the completion of the message exchange).
The peer initiating the TLS-connection is
always sending "Requests" and the peer accepting the TLS-connection
is always sending "Responses". The format of the message container
is shown in <xref target="container"/>.
</t>
<t>All data inside the Content portion of the message container MUST be
encoded using octets. Fragmentation of message containers is not supported,
which means one request or response at the "application layer"
MUST NOT exceed the maximum size allowed by the message container
format.
<figure title="Request-Response Message Container" anchor="container">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rsrvd | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content portion.. ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>The three bit Ver field identifies the protocol version. The current
version is 0 i.e. all bits are set to value 0 (zero).
</t>
<t>The Rsrvd field MUST be set to value 0 (zero),
</t>
<t>The Identifier field is meant for matching requests and responses. The
valid Identifier values are between 1-255. The value 0 MUST NOT
be used. The first request for each communication session between
the MN and the HAC MUST have the Identifier values set to 1.
</t>
<t>The Length field tells the length of the Content portion of the container
(i.e. Reserved octet, Identifier octet and Length field are excluded).
The Content portion length MUST always be at least one octet up to
65535 octets. The value is in network order.
</t>
</section>
<section title="Request-response Message Content Encoding">
<t>The encoding of the message content is similar to HTTP header
encoding, and
complies to the augmented Backus-Naur Form (BNF) defined in
Section 2.1 of <xref target="RFC2616"/>. All presented hexadecimal
numbers are in network byte order. From now on, we use TypeValue
header (TV-header) term to refer request-response message content
HTTP-like headers.
</t>
</section>
<section title="Request-Response Message Exchange">
<t>The message exchange between the MN and the HAC is a simple lock-step
request-response type as stated in <xref target="record"/>. A
request message includes monotonically increasing Identifier value
that is copied to the corresponding response message. Each request
MUST have a different Identifier value. Hence, a reliable connection
oriented transport below the message container framing is assumed. The
number of request-response message exchanges MUST NOT exceed 255.
</t>
<t>Each new communication session between the MN and the HAC MUST
reset the Identifier value to 1. The MN is also the peer that
always sends only request messages and the HAC only sends
response messages. Once the request-response message exchange
completes, the HAC and the MN MUST close the transport connection
and the corresponding TLS-tunnel.
</t>
<t>In a case of a HAC side error, the HAC MUST send a response back
to a MN with an appropriate status code and then close the
transport connection.
</t>
<t>The first request message - MHAuth-Init - (i.e. the Identifier is
1) MUST always contain at least the following parameters:
</t>
<t><list>
<t>MN-Identity - See <xref target="mn-id"/>.</t>
<t>Authentication Method - See <xref target="auth-method"/>.</t>
</list></t>
<t>The first response message - MHAuth-Init - (i.e. the Identifier is 1)
MUST contain at minimum the following parameters:
</t>
<t><list>
<t>Selected authentication Method - See <xref target="auth-method"/>.</t>
</list></t>
<t>The last request message from the MN side - MHAuth-Done -
MUST contain the following parameters:
</t>
<t><list>
<t>Security Association Scope - See <xref target="sas"/>.</t>
<t>Proposed ciphersuites - See <xref target="ciphersuite"/>.</t>
<t>Message Authenticator - See <xref target="msg-auth"/>.</t>
</list></t>
<t>The last response message - MHAuth-Done - that ends the
request-response message exchange MUST contain the following
parameters:
</t>
<t><list>
<t>Status Code - See <xref target="status-code"/>.</t>
<t>Message Authenticator - See <xref target="msg-auth"/>.</t>
</list></t>
<t>And in a case of successful authentication the following
additional parameters:
</t>
<t><list>
<t>Selected ciphersuite - See <xref target="ciphersuite"/>.</t>
<t>Security Association Scope - See <xref target="sas"/>.</t>
<t>The rest of the security association data - See <xref target="httpsa"/>.</t>
</list></t>
</section>
<section title="Home Agent Controller Discovery">
<t>All bootstrapping information, whether for setting up the SA or
for bootstrapping Mobile IPv6 specific information, is exchanged
between the MN and the HAC using the framing protocol defined in
<xref target="record"/>. The IP address of the HAC MAY be
statically configured to the MN or may be dynamically discovered
using DNS. In a case of DNS-based HAC discovery, the MN
either queries an A/AAAA or a SRV record for the HAC IP address.
The actual domain name used in queries is up to the deployment
to decide and out of scope of this specification.
</t>
</section>
<section title="Generic Request-Response Parameters">
<t>The grammar used in the following sections is the augmented Backus-Naur Form (BNF) same to that used by HTTP <xref target="RFC2616"/>.
</t>
<section title="Mobile Node Identifier" anchor="mn-id">
<t>An identifier that identifies a MN. The
Mobile Node Identifier is in form of a Network Access
Identifier (NAI) <xref target="RFC4282"/>.
</t>
<t><list>
<t>mn-id = "mn-id" ":" RFC4282-NAI CRLF
</t>
</list></t>
</section>
<section title="Authentication Method" anchor="auth-method">
<t>The HAC is the peer that mandates the authentication method.
The MN sends its authentication method proposal to the HAC. The HAC,
upon receipt of the MN proposal returns the selected authentication method.
The MN MUST propose at least one authentication method. The HAC MUST select
exactly one authentication method, or return an error and then close the
connection.
</t>
<t><list>
<t>auth-method = "auth-method" ":" a-method *("," a-method) CRLF
<vspace/>
a-method =
<vspace/>
"psk" ; Pre-shared key based authentication
<vspace/>
| "eap" ; EAP-based authentication
</t>
</list></t>
</section>
<section title="Extensible Authentication Protocol Payload" anchor="eap-payload">
<t>Each Extensible Authentication Protocol (EAP) <xref target="RFC3748"/>
message is an encoded string of hexadecimal numbers. The "eap-payload"
is completely transparent what EAP-method or EAP message is
carried inside it. The "eap-payload" can appear in both request
and response messages:
</t>
<t><list>
<t>eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF</t>
</list></t>
</section>
<section title="Status Code" anchor="status-code">
<t>The "status-code" MUST only be present in the response message
that ends the request-response message exchange. The "status-code"
follows the principles of HTTP and the definitions found in
Section 10 of RFC 2616 also apply for these status codes listed
below:
</t>
<t><list>
<t>status-code = "status-code" ":" status-value CRLF
<vspace/>
status-value =
<vspace/>
"100" ; Continue
<vspace/>
| "200" ; OK
<vspace/>
| "400" ; Bad Request
<vspace/>
| "401" ; Unauthorized
<vspace/>
| "500" ; Internal Server Error
<vspace/>
| "501" ; Not Implemented
<vspace/>
| "503" ; Service Unavailable
<vspace/>
| "504" ; Gateway Time-out
</t>
</list></t>
</section>
<section title="Message Authenticator" anchor="msg-auth">
<t>The "auth" header contains data
used for authentication purposes. It MUST be the
last TV-header in the message and calculated over
the whole message till the start of the "msg-header":
</t>
<t><list>
<t>msg-auth = "auth" ":" 1*(HEX HEX) CRLF</t>
</list></t>
</section>
<section title="Retry After" anchor="retry-after">
<t><list>
<t>retry-after = "retry-after" ":" rfc1123-date CRLF</t>
</list></t>
</section>
<section title="End of Message Content" anchor="eof">
<t><list>
<t>end-of-message = 2CRLF</t>
</list></t>
</section>
<section title="Random Values" anchor="rand">
<t>Random numbers generated by the MN and the HAC, respectively.
The length of the random number MUST be 32 octets (before TV-header encoding):
</t>
<t><list>
<t>mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF</t>
<t>hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF</t>
</list></t>
</section>
</section>
<!-- section 5.6 -->
<section title="Security Association Configuration Parameters" anchor="httpsa">
<t>During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate
a single ciphersuite for protecting the traffic between the MN and
the HA. The allowed ciphersuites for this specification are a
subset of those in TLS v1.2 (see Annex A.5 of <xref target="RFC5246"/>)
as per <xref target="ciphersuite"/>. This might appear as a
constraint as the HA and the HAC may have implemented different
ciphersuites. These two nodes are, however, assumed to belong to
the same administrative domain. In order to avoid exchanging
supported MN-HA ciphersuites in the MN-HAC protocol and to reuse
the TLS ciphersuite negotiation procedure we make this simplifying
assumption. The selected ciphersuite MUST provide integrity and
confidentiality protection.
</t>
<t><xref target="ciphersuite"/> provides the mapping from the TLS
ciphersuites to the integrity and encryption algorithms allowed
for MN-HA protection. This mapping mainly ignores the
authentication algorithm part that is not required within the
context of this specification. For example, <xref target="RFC5246"/>
defines a number of AES based ciphersuites for TLS including
'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the
relevant part is 'AES_128_CBC_SHA'.
</t>
<t>All the parameters described in the following sections apply only
to a request-response protocol response message to the MN. The MN has
no way affecting to the provisioning decision of the HAC.
</t>
<section title="Security Parameter Index" anchor="spi">
<t>The 28-bit unsigned SPI number identifies the SA used between
the MN and the HA. The value 0 (zero) is reserved and MUST NOT
be used. Therefore, values ranging from 1 to 268435455 are valid.
</t>
<t>The TV-header corresponding to the SPI number is:
</t>
<t><list>
<t>mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF</t>
</list>
</t>
</section>
<section title="MN-HA Shared Keys" anchor="mnhakey">
<t>The MN-HA shared integrity (ikey) and encryption (ekey) keys
are used to protect the traffic between
the MN and the HA. The length of these keys depend on the
selected ciphersuite.
</t>
<t>The TV-headers that carry these two parameters are: </t>
<t>
<list>
<t>mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF</t>
<t>mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF</t>
<t>mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF</t>
<t>mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF</t>
</list>
</t>
</section>
<section title="Security Association Validity Time" anchor="salifetime">
<t>The end of the SA validity time is encoded using the "rfc1123-date" format, as
defined in Section 3.3.1 of <xref target="RFC2616"/>. </t>
<t>The TV-header corresponding to the SA validity time value is: </t>
<t>
<list>
<t>mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date CRLF</t>
</list>
</t>
</section>
<section title="Security association scope (SAS)" anchor="sas">
<t>The SA is applied either to Mobile IPv6 signaling messages
only, or to both Mobile IPv6 signaling messages and data
traffic. This policy MUST be agreed between the MN and HA
prior to using the SA. Otherwise the receiving side would not
be aware of whether the SA applies to data traffic and could
not decide how to act when receiving unprotected packets of
PType 1 (see <xref target="dtamsg"/>).
</t>
<t>
<list>
<t>mip6-sas = "mip6-sas" ":" 1DIGIT CRLF</t>
</list>
</t>
<t>where a value of “0” indicates that the SA does not protect
data traffic and a value of “1” indicates that all data
traffic MUST be protected by the SA. If the mip6-sas value of
an SA is set to 1, any packet received with a PType value that
does not match the mip6-sas value of the SA MUST be silently
discarded.
</t>
<t>The HAC is the peer that mandates the used security association
scope. The MN sends its proposal to the HAC but eventually
the security association scope returned from the HAC defines
the used scope.
</t>
</section>
<section title="CipherSuites and Ciphersuite-to-Algorithm Mapping" anchor="ciphersuite">
<t>The ciphersuite negotiation between HAC and MN uses a subset
of the TLS 1.2 ciphersuites and follows the TLS 1.2 numeric
representation defined in Annex A.5 of <xref target="RFC5246"/>.
The TV-headers corresponding to the selected
ciphersuite and ciphersuite list are:
</t>
<t>
<list>
<t>mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
<vspace/>
csuite = "{" suite "}"
<vspace/>
suite =
<vspace/>
"00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02}
<vspace/>
| "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B}
<vspace/>
| "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A} <vspace/>
| "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F} <vspace/>
| "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C} </t>
<t>mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF
</t>
</list>
</t>
<!--t>The following ciphersuites are defined:
<figure>
<artwork><![CDATA[
CipherSuite NULL_SHA = { 0x00,0x02 }; CipherSuite NULL_SHA256 = { 0x00,0x3B }; CipherSuite 3DES_EDE_CBC_SHA = { 0x00,0x0A }; CipherSuite AES_128_CBC_SHA = { 0x00,0x2F }; CipherSuite AES_128_CBC_SHA256 = { 0x00,0x3C }; ]]></artwork>
</figure>
</t-->
<t>
All other Ciphersuite values are reserved.
</t>
<t>The following integrity algorithms MUST be supported by all
implementations:
<figure>
<artwork><![CDATA[
HMAC-SHA1-96 [RFC2404]
AES-XCBC-MAC-96 [RFC3566]
]]></artwork>
</figure>
</t>
<t>The binding management messages between the MN and HA MUST be
integrity protected. Implementations MUST NOT use a NULL
integrity algorithm.
</t>
<t>The following encryption algorithms MUST be supported:
<figure>
<artwork><![CDATA[
NULL [RFC2410]
TripleDES-CBC [RFC2451]
AES-CBC with 128-bit keys [RFC3602]
]]></artwork>
</figure>
</t>
<t>Traffic between MN and HA MAY be encrypted. Any
integrity-only CipherSuite makes use of the NULL encryption
algorithm.
</t>
<t>Note: In the present version, this document does not consider
combined algorithms. The following table provides the mapping
of each ciphersuite to a combination of integrity and
encryption algorithms that are part of the negotiated SA
between MN and HA.
<figure title="Ciphersuite-to-Algorithm Mapping">
<artwork><![CDATA[
+-------------------+-----------------+--------------------------+
|Ciphersuite |Integ. Algorithm |Encr. Algorithm |
+-------------------+-----------------+--------------------------+
|NULL_SHA |HMAC-SHA1-96 |NULL |
|NULL_SHA256 |AES-XCBC-MAC-96 |NULL |
|3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC |
|AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys |
|AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys |
+-------------------+----------------+---------------------------+
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Mobile IPv6 Bootstrapping Parameters" anchor="httpmip">
<t>In parallel with the SA bootstrapping, the HAC SHOULD provision
the MN with relevant Mobile IPv6 related bootstrapping
information.
</t>
<t>The following generic BNFs are used to form IP addresses and
prefixes. They are used in subsequent sections.
<figure>
<artwork><![CDATA[
ip6-addr = 7( word ":" ) word CRLF
word = 1*4HEX
ip6-prefix = ip6-addr "/" 1*2DIGIT
ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
ip4-subnet = ip4-addr "/" 1*2DIGIT
]]></artwork>
</figure>
</t>
<section title="Home Agent Address">
<t>The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, or both. </t>
<t>
<list>
<t>mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF</t>
<t>mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF</t>
</list>
</t>
</section>
<!-- dynamic port allocation replaced by IANA defined fixed port.. -->
<section title="Mobile IPv6 Service Port Number">
<t>The HAC SHOULD provision the MN with an UDP port number, where the HA expects to receive UDP packets. If this parameter is not present, then the IANA reserved port number (HALTSEC) MUST be used instead.
</t>
<t>
<list>
<t>mip6-port = "mip6-port" ":" 1*5DIGIT CRLF</t>
</list>
</t>
</section>
<section title="Home Addresses and Home Network Prefix">
<t>The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or both. The
HAC MAY also provision the MN with its home network prefix.
</t>
<t>
<list>
<t>mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF</t>
<t>mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF</t>
<t>mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF</t>
<t>mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF</t>
</list>
</t>
</section>
<section title="DNS Server">
<t>The HAC may also provide the MN with DNS server
configuration options. These DNS servers are reachable via
the home agent.
</t>
<t>
<list>
<t>dns-ip6 = "dns-ip6" ":" ip6-addr CRLF </t>
<t>dns-ip4 = "dns-ip4" ":" ip4-addr CRLF </t>
</list>
</t>
</section>
</section>
<section title="Authentication of the Mobile Node">
<t>This section describes the basic operation required for the MN-HAC
mutual authentication and the channel binding. The authentication
protocol described as part of this section is a simple exchange that
follows the GPSK exchange used by EAP-GPSK <xref target="RFC5433"/>.
It is secured by the TLS tunnel and is cryptographically bound to
the TLS tunnel through channel binding based on <xref target="RFC5056"/>
and on the channel binding type 'tls-server-endpoint' described in
<xref target="RFC5929"/>. As a result of
the channel binding type, this method can only be used with TLS
ciphersuites that use server certificates and the Certificate
handshake message. For example, TLS ciphersuites based on PSK or
anonymous authentication cannot be used.
</t>
<t>The authentication exchange MUST be performed through the encrypted
TLS tunnel. It performs mutual authentication between the MN and
the HAC based on a pre-shared key (PSK) or based on an EAP-method
(see <xref target="eap-method"/>). The PSK protocol is described
in this section. It consists of the message exchanges (MHAuth-Init,
MHAuth-Mid, MHAuth-Done) in which both sides exchange nonces and
their identities, and compute and exchange
a message authenticator 'auth' over the previously exchanged
values, keyed with the pre-shared key. The MHAuth-Done messages
are used to deal with error situations. Key binding with the TLS
tunnel is ensured by channel binding of the type "tls-server-endpoint"
as described by <xref target="RFC5929"/>
where the hash of the TLS server certificate serves as input to
the 'auth' calculation of the MHAuth messages.
</t>
<t>Note: The authentication exchange is based on the GPSK exchange
used by EAP-GPSK. In comparison to GPSK, it does not support
exchanging an encrypted container (it always runs through an
already protected TLS tunnel). Furthermore, the initial request
of the authentication exchange (MHAuth-Init) is sent by the MN
(client side) and is comparable to EAP-Response/Identity, which
reverses the roles of request and response messages compared to
EAP-GPSK. <xref target="psk"/> shows a successful protocol
exchange.
</t>
<t>
<figure title="Authentication of the Mobile Node Using Shared Secrets" anchor="psk">
<artwork><![CDATA[
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (...) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Done (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (...) |
|<------------------------------------------------------|
| |
]]></artwork>
</figure>
</t>
<t><list style="format %d)">
<t>Request/MHAuth-Init: (MN -> HAC)
<list style="empty"> <t>mn-id, mn-rand, auth-method=psk</t>
</list>
<vspace blankLines="1"/>
</t>
<t>Response/MHAuth-Init: (MN <- HAC)
<list style="empty">
<t>[mn-rand, hac-rand, auth-method=psk, [status],] auth</t>
</list>
<vspace blankLines="1"/>
</t>
<t>Request/MHAuth-Done: (MN -> HAC)
<list style="empty">
<t>mn-rand, hac-rand, sa-scope, ciphersuite-list, auth</t>
</list>
<vspace blankLines="1"/>
</t>
<t>Response/MHAuth-Done: (MN <- HAC)
<list style="empty">
<t>[sa-scope, sa-data, ciphersuite, bootstrapping-data,]
mn-rand, hac-rand, status, auth</t>
</list>
</t>
</list>
</t>
<t>Where:</t>
<t>
<list>
<t>auth = HMAC-SHA256(PSK, msg-octets | CB-octets)</t>
</list>
</t> <t>The length "mn-rand", "hac-rand" is 32 octets. Note that "|"
indicates concatenation and optional parameters are shown in
square brackets [..]. The square brackets can be nested.
</t> <t>The shared secret PSK can be variable length. 'msg-octets'
includes all payload parameters of the respective message to be
signed except the 'auth' payload. CB-octets is the channel binding
input to the auth calculation that is the "TLS-server-endpoint"
channel binding type. The content and algorithm (only required
for the "TLS-server-endpoint" type) are the same as described in
<xref target="RFC5929"/>.
</t>
<t>The MN starts by selecting a random number 'mn-rand' and choosing
a list of supported authentication methods coded in 'auth-method'.
The MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to
the HAC in MHAuth-Init. The decision of which authentication method
to offer and which to pick is policy- and implementation-dependent
and, therefore, outside the scope of this document.
</t>
<t>In MHAuth-Done, the HAC sends a random
number 'hac-rand' and the selected ciphersuite. The
selection MUST be one of the MN-supported ciphersuites as received
in 'ciphersuite-list'. Furthermore, it repeats the received parameters
of the MHAuth-Init message 'mn-rand'. It
computes a message authenticator 'auth' over all the transmitted
parameters except 'auth' itself. The HAC calculates 'auth' over all
parameters and appends it to the message.
</t>
<t>The MN verifies the received MAC and the consistency of the
identities, nonces, and ciphersuite parameters transmitted in
MHAuth-Auth. In case of successful verification, the MN computes
a MAC over the session parameter and returns it to the HAC in
MHAuth-Done. The HAC verifies the received MAC and the consistency
of the identities, nonces, and ciphersuite parameters transmitted
in MHAuth-Init. If the verification is successful, MHAuth-Done
is prepared and sent by the HAC to confirm successful completion
of the exchange.
</t>
</section>
<section title="Extensible Authentication Protocol Methods" anchor="eap-method">
<t>Basic operation required for the MN-HAC mutual authentication
using EAP-based methods.
</t>
<figure title="Authentication of the Mobile Node Using EAP" anchor="eap">
<artwork><![CDATA[
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (..., |
| eap-payload=EAP-Request/Identity) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Mid (eap-payload= |
| EAP-Response/Identity) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Mid (eap-payload=EAP-Request/...) |
|<------------------------------------------------------|
| |
: :
: ..EAP-method specific exchanges.. :
: :
| |
| Request/MHAuth-Done (eap-payload=EAP-Response/..., |
| ..., auth) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (eap-payload=EAP-Success, |
| ..., auth) |
|<------------------------------------------------------|
| |
]]></artwork>
</figure>
<t><list style="format %d)">
<t>Request/MHAuth-Init: (MN -> HAC)
<list style="empty"> <t>mn-id, mn-rand, auth-method=eap</t>
</list>
<vspace blankLines="1"/>
</t>
<t>Response/MHAuth-Init: (MN <- HAC)
<list style="empty">
<t>[auth-method=eap, eap, [status,]] auth</t>
</list>
<vspace blankLines="1"/>
</t>
<t>Request/MHAuth-Mid: (MN –> HAC)
<list style="empty">
<t>eap, auth</t>
</list>
<vspace blankLines="1"/>
</t>
<t>Response/MHAuth-Mid: (MN <- HAC)
<list style="empty">
<t>eap, auth</t>
</list>
<vspace blankLines="1"/>
MHAuth-Mid exchange is repeated as many times as needed by the used
EAP-method.
<vspace blankLines="1"/>
</t>
<t>Request/MHAuth-Done: (MN -> HAC)
<list style="empty">
<t>sa-scope, ciphersuite-list, eap, auth</t>
</list>
<vspace blankLines="1"/>
</t>
<t>Response/MHAuth-Done: (MN <- HAC)
<list style="empty">
<t>[sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, status, auth</t>
</list>
</t>
</list>
</t>
<t>Where:</t>
<t>
<list>
<t>auth = HMAC-SHA256(shared-key, msg-octets | CB-octets)</t>
</list>
</t> <t>In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1".
If the EAP-method is key-deriving and creates a shared MSK key as
a side effect of Authentication shared-key MUST be the MSK in all
MHAuth-Done messages. This MSK MUST NOT be used for any other
purpose. In case the EAP method does not generate an MSK key,
shared-key is set to "1".
</t>
<t>'msg-octets'
includes all payload parameters of the respective message to be
signed except the 'auth' payload. CB-octets is the channel binding
input to the AUTH calculation that is the "TLS-server-endpoint"
channel binding type. The content and algorithm (only required
for the "TLS-server-endpoint" type) are the same as described in
<xref target="RFC5929"/>.
</t>
</section>
</section>
<section title="Mobile Node to Home Agent communication">
<section title="General" anchor="packets">
<t>The following sections describe the packet formats used for the traffic between the
MN and the HA. This traffic includes binding management messages (for example, BU
and BA messages), reverse tunneled and encrypted user data, and reverse tunneled
plain text user data. This specification defines a generic packet format, where
everything is encapsulated inside UDP. See <xref target="bmmmsg"/> and <xref
target="dtamsg"/> for detailed illustrations of the corresponding packet formats.
</t>
<!-- fix the ha service port number.. -->
<t>The Mobile IPv6 service port number is where the HA expects to receive UDP
packets. The same
port number is used for both binding management messages and user data packets. The
reason for multiplexing data and control messages over the same port number is due to
the possibility of Network Address and Port Translators located along the path
between the MN and the HA. The Mobile IPv6 service MAY use any ephemeral port number
as the UDP source port, and MUST use the Mobile IPv6 service port number as the UDP destination port. The Mobile IPv6 service port is either dynamically assigned to the MN during the bootstrapping phase (i.e. the mip6-port parameter) or in absence of the bootstrapping parameter the IANA reserved port (HALTSEC) MUST be used.
</t>
<t>The encapsulating UDP header is immediately followed by a 4-bit
Packet Type (PType) field that defines whether the packet
contains an encrypted mobility management message or a, an encrypted
user data packet, or a plain text user data packet.
</t>
<t>The Packet Type field is followed by a 28-bit SPI value, which
identifies the correct SA concerning the encrypted packet. For
any packet that is neither integrity protected nor encrypted (i.e.
no SA is applied by the originator) the SPI MUST be set to 0 (zero). Mobility management messages MUST always be at least
integrity protected. Hence, mobility management messages MUST
NOT be sent with a SPI value of 0 (zero).
</t>
<t>There is always only one SPI per MN-HA mobility session and the
same SPI is used for all types of protected packets independent
of the direction.
</t>
<t>The SPI value is followed by a 32-bit Sequence Number value that
is used to identify retransmissions of protected messages (integrity protected or both integrity protected and
encrypted, see Figures <xref target="ptype8" format="counter"/> and <xref target="ptype1" format="counter"/>) . Each
endpoint in the security association maintains two "current"
Sequence Numbers: the next one to be used for a packet it
initiates and the next one it expects to see in a packet from
the other end. If the MN and the HA ends initiate very different
numbers of messages, the Sequence Numbers in the two directions
can be very different. In a case data protection is not used (see <xref target="ptype0"/>), the
Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD
initiate a re-establishement of the SA before any of the Sequence
Number cycle.
</t>
<t>Finally, the Sequence Number field is followed by the data
portion, whose content is identified by the Packet Type. The
data portion may be protected.
</t>
</section>
<section title="PType and Security Parameter Index">
<t>The PType is a 4-bit field that indicates the Packet Type (PType)
of the UDP encapsulated packet. The PType is followed by a
a 28-bit SPI value. The PType and the SPI fields are treated as
one 32-bit field during the integrity protection calculation.
<!--t>The SPI is a 32-bit field, where the first 4 bits indicate the
Packet Type (PType) of the UDP encapsulated packet. The SPI value
itself consists of the remaining 28-bit of the SPI field. The SPI
field is treated as one 32-bit field during the integrity
protection calculation.-->
<figure title="Security Parameter Index with Packet Type" anchor="spifig">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
A SPI value of 0 (zero) indicates a plaintext packet. If the
packet is integrity protected or both integrity protected and
encrypted, the SPI value MUST be different from 0. When
the SPI value is set to 0, then the PType MUST also be 0.
</t>
</section>
<section title="Binding Management Message Formats" anchor="bmmmsg">
<t>The binding management messages that are only meant to be
exchanged between the MN and the HA MUST be integrity
protected and MAY be encrypted. They MUST use the packet
format shown in <xref target="ptype8"/>.
</t>
<t>All packets that are
specific to the Mobile IPv6 protocol, contain a Mobility
Header (as defined in Section 6.1.1. of RFC 6275), and are used between the MN and the HA
use the packet format shown in <xref target="ptype8"/>.
(This means that some Mobile IPv6 mobility management
messages, such as the HoTI message, are treated as
data packets and using encapsulation described in
<xref target="dtamsg" /> and shown in Figures <xref target="ptype1" format="counter" /> and <xref target="ptype0" format="counter"/>).
</t>
<t>
<figure title="UDP Encapsulated Binding Management Message Format" anchor="ptype8">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|PType=8| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>The PType value 8 (eight) identifies that the UDP encapsulated
packet contains a RFC 6275 defined Mobility Header and other
relevant IPv6 extension headers. Note, there is no additional
IP header inside the encapsulated part. The Next Header field
MUST be set to value of the first encapsulated header. The
encapsulated headers follow the natural IPv6 and Mobile IPv6
extension header alignment and formatting rules.
</t>
<t>The Padding, Pad Length, Next Header and ICV fields follow
the rules of Section 2.4 to 2.8 of <xref target="RFC4303"/> unless
otherwise stated in this document. For a SPI value of 0 (zero)
that indicates an unprotected packet, the Padding, Pad Length,
Next Header and ICV fields MUST NOT be present.
</t>
<t>The source and destination IP addresses of the outer IP header
(i.e. the src-addr and the dst-addr in <xref target="ptype8"/>)
use the current care-of address of the MN and the HA address.
</t>
</section>
<section title="Reverse Tunneled User Data Packet Formats" anchor="dtamsg">
<t>There are two types of reverse tunneled user data packets
between the MN and the HA. Those that are integrity protected
and encrypted and those that are plaintext. The MN or the HA
decide whether to apply integrity protection and encryption
to a packet or to send it in plaintext based on the mip6-sas
value in the SA. If the mip6-sas is set to 1 the originator
MUST NOT send any plaintext packet, and the receiver MUST
silently discard any packet with the PType set to 0
(unprotected). It is RECOMMENDED to apply confidentiality and
integrity protection of user data traffic. The reverse
tunneled IPv4 or IPv6 user data packets are encapsulated
as-is inside the 'Payload Data' shown in Figures <xref target="ptype1" format="counter"/>
and <xref target="ptype0" format="counter"/>.
<figure
title="UDP Encapsulated Protected User Data Packet Format" anchor="ptype1">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=1| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>The PType value 1 (one) identifies that the UDP encapsulated
packet contains an encrypted tunneled IPv4/IPv6 user data
packet. The Next Header field header MUST be set to value
corresponding the tunneled IP packet (e.g., 41 for IPv6).
</t>
<t>The Padding, Pad Length, Next Header and ICV fields follow
the rules of Section 2.4 to 2.8 of <xref target="RFC4303"/> unless
otherwise stated in this document. For a SPI value of 0 (zero)
that indicates an unprotected packet, the Padding, Pad Length,
Next Header and ICV fields MUST NOT be present.
</t>
<t>The source and destination IP addresses of the outer IP header
(i.e., the src-addr and the dst-addr in
<xref target="ptype1"/>) use the current care-of address of
the MN and the HA address. The ESP protected inner IP header,
which is not shown in <xref target="ptype1"/>, uses the home
address of the MN and the correspondent node (CN) address.
</t>
<t>
<figure title="UDP Encapsulated Non-Protected User Data Packet Format"
anchor="ptype0">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Payload Data (plain IPv4 or IPv6 Packet) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>The PType value 0 (zero) identifies that the UDP encapsulated
packet contains a plaintext tunneled IPv4/IPv6 user data
packet. Also the SPI and the Sequence Number fields MUST be
set to 0 (zero).
</t>
<t>The source and destination IP addresses of the outer IP header
(i.e., the src-addr and the dst-addr in
<xref target="ptype0"/>) use the current care-of address of
the MN and the HA address. The plain text inner IP header
uses the home address of the MN and the CN address.
</t>
</section>
</section>
<section title="Route Optimization" anchor="ro">
<t>Mobile IPv6 route optimization as described in <xref
target="RFC6275"/> is not affected by this specification. Route
optimization is possible only between an IPv6 MN and CN. UDP
encapsulation of signaling and data traffic is only between
the MN and HA. The return routability signaling messages such as
HoTI/HoT and CoTI/CoT <xref target="RFC6275"/> are treated as
data packets and encapsulation, when needed, is as per the description in
<xref target="dtamsg"/> of this specification. The data packets between an MN and CN which have
successfully completed the return routability test and created
the appropriate entries in their binding cache are not UDP
encapsulated using the packet formats defined in this specification but follow the <xref target="RFC6275"/>
specification.
</t>
</section>
<!-- ================================================================== -->
<section title="IANA Considerations">
<section title="New Registry: Packet Type">
<t>IANA is requested to create a new registry under the <xref target="RFC6275"/> Mobile IPv6 parameters registry for the Packet Type as described in <xref
target="packets"/>. <figure>
<artwork><![CDATA[
Packet Type | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8
]]></artwork>
</figure>
</t>
<t>Following the allocation policies from <xref target="RFC5226"/> new values for the
Packet Type AVP MUST be assigned based on the "RFC Required" policy. </t>
</section>
<section title="Status Codes">
<t>A new Status Code (to be used in BA messages) is reserved for the
cases where the HA wants to indicate to the MN that it needs to
re-establish the SA information with the HAC. The Result Code is
reserved from the 0-127 code space in <xref target="RFC6275"/> Status Codes registry:
<figure>
<artwork><![CDATA[
REINIT_SA_WITH_HAC TBD1
]]></artwork>
</figure>
</t>
</section>
<section title="Port Numbers">
<t>A new port number (HALTSEC) for UDP packets is reserved from the existing PORT NUMBERS registry.
<figure>
<artwork><![CDATA[
HALTSEC TBD2
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- ================================================================== -->
<section title="Security Considerations">
<t>This document describes and uses a number of building blocks that
introduce security mechanisms and need to inter-work in a secure
manner.
</t>
<t> The following building blocks are considered from a security
point of view:
</t>
<t>
<list style="numbers">
<t>Discovery of the HAC </t>
<t>Authentication and MN-HA SA establishment executed between
the MN and the HAC (PSK or EAP-based) through a TLS tunnel</t>
<t>Protection of MN-HA communication </t>
<t>AAA Interworking </t>
</list>
</t>
<section title="Discovery of the HAC">
<t>No dynamic procedure for discovering the HAC by the MN is
described in this document. As such, no specific security
considerations apply to the scope of this document.
</t>
</section>
<section
title="Authentication and Key Exchange executed between the MN
and the HAC">
<t>This document describes a simple authentication and MN-HA SA
negotiation exchange over TLS. The TLS procedures remain
unchanged; however, channel binding is provided.
</t>
<t>
<list style="hanging">
<t hangText="Authentication:"> Server-side certificate based
authentication MUST be performed using TLS 1.2
<xref target="RFC5246"/>.
<vspace blankLines="1"/>
The client-side authentication may depend on the
specific deployment and is therefore not mandated. Note
that TLS-PSK <xref target="RFC4279"/> cannot be used in
conjunction with the methods described in section 5.8 and
5.9 of this document due to the limitations of the channel
binding type used.
<vspace blankLines="1"/>
Through the protected TLS tunnel, an additional
authentication exchange is performed that provides
client-side or mutual authentication and exchanges SA
parameters and optional configuration data to be used in
the subsequent protection of MN-HA communication. The
additional authentication exchange can either be PSK-based
(section 5.8) or EAP-based (section 5.9). Both exchanges
are always performed within the protected TLS tunnel and
MUST NOT be used as standalone protocols. <vspace blankLines="1"/>
The simple PSK-based authentication exchange provides
mutual authentication and follows the GPSK exchange used
by EAP-GPSK <xref target="RFC5433"/> and has similar
properties, although some features of GPSK like the
exchange of a protected container are not supported. <vspace blankLines="1"/>
The EAP-based authentication exchange simply defines
message containers to allow carrying the EAP packets
between the MN and the HAC. In principle, any EAP method
can be used. However, it is strongly recommended to use
only EAP methods that provide mutual authentication and
that derive keys including an MSK key in compliance with
<xref target="RFC3748"/>. <vspace blankLines="1"/>
Both exchanges use channel binding with the TLS tunnel.
The channel binding type ‘TLS-server-endpoint’ as per
<xref target="RFC5929"/> MUST be
used.
<vspace blankLines="1"/>
</t>
<t hangText="Dictionary Attacks:">All messages of the
authentication exchanges specified in this document are
protected by TLS. However, any implementation SHOULD assume
that the properties of the authentication exchange are the
same as for GPSK <xref target="RFC5433"/> in case the
PSK-based method as per section 5.8. is used, and are the
same as those of the underlying EAP method in case the
EAP-based exchange as per section 5.9 is used.
<vspace blankLines="1"/>
</t>
<t hangText="Replay Protection:">The underlying TLS protection
provides protection against replays.
<vspace blankLines="1"/>
</t>
<t hangText="Key Derivation and Key Strength:">For TLS, the
TLS specific considerations apply unchanged. For the
authentication exchanges defined in this document, no key
derivation step is performed as the MN-HA keys are
generated by the HAC and are distributed to the MN through
the secure TLS connection.
<vspace blankLines="1"/>
</t>
<t hangText="Key Control:">No joint key control for MN-HA keys
is provided by this version of the specification.
<vspace blankLines="1"/>
</t>
<t hangText="Lifetime:"> The TLS-protected authentication
exchange between the MN and the HAC is only to
bootstrap keys and other parameters for usage with MN-HA
security. The SAs that contain the keys have an associated
lifetime. The usage of Transport Layer Security (TLS)
Session Resumption without Server-Side State,
described in <xref target="RFC5077"/>, provides the ability
for the MN to minimize the latency of future exchanges
towards the HA without having to keep state at the HA
itself.
<vspace blankLines="1"/>
</t>
<t hangText="Denial of Service Resistance:"> The level of
resistance against denial of service attacks SHOULD be
considered the same as for common TLS operation, as TLS
is used unchanged. For the PSK-based authentication
exchange, no additional factors are known. For the
EAP-based authentication exchange, any considerations
regarding denial-of-service resistance specific to the
chosen EAP method are expected to be applicable and need
to be be taken into account.
<vspace blankLines="1"/>
</t>
<t hangText="Session Independence:"> Each individual TLS
protocol run is independent from any previous exchange
based on the security properties of the TLS handshake
protocol. However, several PSK or EAP-based authentication
exchanges can be performed across the same TLS connection.
<vspace blankLines="1"/>
</t>
<t hangText="Fragmentation:">TLS runs on top of TCP and no
fragmentation specific considerations apply to the MN-HAC
authentication exchanges.
<vspace blankLines="1"/>
</t>
<t hangText="Channel Binding:">Both the PSK and the EAP-based
exchanges use channel binding with the TLS tunnel. The
channel binding type ‘TLS-server-endpoint’ as per
<xref target="RFC5929"/> MUST be
used.
<vspace blankLines="1"/>
</t>
<t hangText="Fast Reconnect:"> This protocol provides session
resumption as part of TLS and optionally the support for
<xref target="RFC5077"/>. No fast reconnect is supported
for the PSK-based authentication exchange. For the
EAP-based authentication exchange, availability of fast
reconnect depends on the EAP method used.
<vspace blankLines="1"/>
</t>
<t hangText="Identity Protection:">Based on the security
properties of the TLS tunnel, passive user identity
protection is provided. An attacker acting as
man-in-the-middle in the TLS connection would be able to
observe the MN identity value sent in MHAuth-Init messages.
<vspace blankLines="1"/>
</t>
<t hangText="Protected Ciphersuite Negotiation:"> This protocol provides
ciphersuite negotiation based on TLS.
<vspace blankLines="1"/>
</t>
<t hangText="Confidentiality:"> Confidentiality protection of
payloads exchanged between the MN and the HAC are protected
with the TLS Record Layer. TLS ciphersuites with
confidentiality and integrity protection MUST be negotiated
and used in order to exchange security sensitive material
inside the TLS connection.
<vspace blankLines="1"/>
</t>
<t hangText="Cryptographic Binding:"> No cryptographic bindings are provided by
this protocol specified in this document.
<vspace blankLines="1"/>
</t>
<t hangText="Perfect Forward Secrecy:"> Perfect forward secrecy is provided with
appropriate TLS ciphersuites.
<vspace blankLines="1"/>
</t>
<t hangText="Key confirmation:"> Key confirmation of the keys established with TLS
is provided by the TLS Record Layer when the keys are used to protect the
subsequent TLS exchange.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Protection of MN and HA Communication">
<t>
<list style="hanging">
<t hangText="Authentication:"> Data origin authentication is provided for the
communication between the MN and the HA. The chosen level of security of this
authentication depends on the selected ciphersuite. Entity authentication is
offered by the MN to HAC protocol exchange.
<vspace blankLines="1"/>
</t>
<t hangText="Dictionary Attacks:"> The concept of dictionary attacks is not
applicable to the MN-HA communication as the keying material used for this
communication is randomly created by the HAC and its length depends on the
chosen cryptographic algorithms.
<vspace blankLines="1"/>
</t>
<t hangText="Replay Protection:"> Replay protection for the communication between
the MN and the HA is provided based on sequence numbers and follows the design
of IPsec ESP.
<vspace blankLines="1"/>
</t>
<t hangText="Key Derivation and Key Strength:"> The strength of the keying
material established for the communication between the MN and the HA is
selected based on the negotiated ciphersuite (based on the MN-HAC exchange) and
the key created by the HAC. The randomness requirements for security described
in RFC 4086 <xref target="RFC4086"/> are applicable to the key generation by
the HAC.
<vspace blankLines="1"/>
</t>
<t hangText="Key Control:"> The keying material established during the MN-HAC
protocol exchange for subsequent protection of the MN-HA communication is
created by the HA and therefore no joint key control is provided for it.
<vspace blankLines="1"/>
</t>
<t hangText="Key Naming:"> For the MN-HA communication the security associations
are indexed with the help of the SPI and additionally based on the direction
(in-bound communication or out-bound communication).
<vspace blankLines="1"/>
</t>
<t hangText="Lifetime:"> The lifetime of the MN-HA security associations is based
on the value in the mip6-sa-validity-end header field exchanged during the
MN-HAC exchange. The HAC controls the SA lifetime.
<vspace blankLines="1"/>
</t>
<t hangText="Denial of Service Resistance:"> For the communication between the MN
and the HA there are no heavy cryptographic operations (such as public key
computations). As such, there are no DoS concerns.
<vspace blankLines="1"/>
</t>
<t hangText="Session Independence:"> Sessions are independent from each other when
new keys are created by via the MN-HAC protocol. A new MN-HAC protocol run
produces fresh and unique keying material for protection of the MN-HA
communication.
<vspace blankLines="1"/>
</t>
<t hangText="Fragmentation:"> There is no additional fragmentation support
provided beyond what is offered by the network layer.
<vspace blankLines="1"/>
</t>
<t hangText="Channel Binding:"> Channel binding is not applicable to the MN-HA
communication.
<vspace blankLines="1"/>
</t>
<t hangText="Fast Reconnect:"> The concept of fast reconnect is not applicable to
the MN-HA communication.
<vspace blankLines="1"/>
</t>
<t hangText="Identity Protection:"> User identities SHOULD NOT be exchanged between
the MN and the HA. In a case binding management messages contain
the user identity, the messages SHOULD be confidentiality protected.
<vspace blankLines="1"/>
</t>
<t hangText="Protected Ciphersuite Negotiation:"> The MN-HAC
protocol provides protected ciphersuite negotiation through
a secure TLS connection.
<vspace blankLines="1"/>
</t>
<t hangText="Confidentiality:"> Confidentiality protection of payloads exchanged
between the MN and the HAC (for Mobile IPv6 signaling and optionally for the
data traffic) is provided utilizing algorithms
negotiated during the MN-HAC exchange.
<vspace blankLines="1"/>
</t>
<t hangText="Cryptographic Binding:"> No cryptographic bindings are provided by
this protocol specified in this document.
<vspace blankLines="1"/>
</t>
<t hangText="Perfect Forward Secrecy:"> Perfect forward secrecy is provided when
the MN bootstraps new keying material with the help of the MN-HAC protocol
(assuming that a proper TLS ciphersuite is used).
<vspace blankLines="1"/>
</t>
<t hangText="Key confirmation:"> Key confirmation of the MN-HA keying material
conveyed from the HAC to the MN is provided when the first packets are
exchanged between the MN and the HA (in both directions as two different keys
are used).
</t>
</list>
</t>
</section>
<section title="AAA Interworking">
<t> The AAA backend infrastructure interworking is not defined in this document and
therefore out-of-scope. </t>
</section>
</section>
<!-- ================================================================== -->
<section title="Acknowledgements">
<t>The authors would like to thank Pasi Eronen, Domagoj Premec,
Julien Laganier, Jari Arkko and Christian Bauer for their comments.</t>
</section>
<!-- ================================================================== -->
</middle>
<!-- ================================================================== -->
<back>
<references title="Normative References">
&RFC2119;
&RFC6275;
&RFC5246;
&RFC5226;
&RFC2616;
&RFC5056;
&RFC4282;
&RFC2404;
&RFC3566;
&RFC2410;
&RFC2451;
&RFC3602;
&RFC5929;
</references>
<references title="Informative References">
&RFC0768;
&RFC4301;
&RFC4303;
&RFC5996;
&RFC3776;
&RFC4877;
&RFC5944;
&RFC5555;
&RFC4279;
&RFC4086;
&RFC5077;
&RFC3748;
&RFC5433;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:25:51 |