draft-ietf-mext-mip6-tls-03.txt   rfc6618.txt 
Mobility Extensions (MEXT) J. Korhonen, Ed. Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Request for Comments: 6618 Nokia Siemens Networks
Intended status: Experimental B. Patil Category: Experimental B. Patil
Expires: August 18, 2012 Nokia ISSN: 2070-1721 Nokia
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
D. Kroeselberg D. Kroeselberg
Siemens Siemens
February 15, 2012 May 2012
Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Mobile IPv6 Security Framework Using Transport Layer Security
Node to Home Agent Communication for Communication between the Mobile Node and Home Agent
draft-ietf-mext-mip6-tls-03.txt
Abstract Abstract
Mobile IPv6 signaling between a mobile node and its home agent is Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent
secured using IPsec. The security association between a mobile node (HA) is secured using IPsec. The security association (SA) between
and the home agent is established using IKEv1 or IKEv2. The security an MN and the HA is established using Internet Key Exchange Protocol
model specified for Mobile IPv6, which relies on IKE/IPsec, requires (IKE) version 1 or 2. The security model specified for Mobile IPv6,
interaction between the Mobile IPv6 protocol component and the IKE/ which relies on IKE/IPsec, requires interaction between the Mobile
IPsec module of the IP stack. This document proposes an alternate IPv6 protocol component and the IKE/IPsec module of the IP stack.
security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which This document proposes an alternate security framework for Mobile
relies on Transport Layer Security for establishing keying material IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer
and other bootstrapping parameters required to protect Mobile IPv6 Security for establishing keying material and other bootstrapping
signaling and data traffic between the mobile node and home agent. parameters required to protect Mobile IPv6 signaling and data traffic
between the MN and HA.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 18, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6618.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5 2. Terminology and Abbreviations ...................................4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background ......................................................5
4. TLS-based Security Establishment . . . . . . . . . . . . . . . 6 4. TLS-Based Security Establishment ................................5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview ...................................................5
4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Architecture ...............................................7
4.3. Security Association Management . . . . . . . . . . . . . 8 4.3. Security Association Management ............................7
4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 10 4.4. Bootstrapping of Additional Mobile IPv6 Parameters .........9
4.5. Protecting Traffic Between Mobile Node and Home Agent . . 11 4.5. Protecting Traffic between Mobile Node and Home Agent .....10
5. Mobile Node to Home Agent Controller Communication . . . . . . 11 5. MN-to-HAC Communication ........................................10
5.1. Request-response Message Framing over TLS-tunnel . . . . . 11 5.1. Request-Response Message Framing over TLS-Tunnel ..........10
5.2. Request-response Message Content Encoding . . . . . . . . 12 5.2. Request-Response Message Content Encoding .................11
5.3. Request-Response Message Exchange . . . . . . . . . . . . 12 5.3. Request-Response Message Exchange .........................12
5.4. Home Agent Controller Discovery . . . . . . . . . . . . . 13 5.4. Home Agent Controller Discovery ...........................13
5.5. Generic Request-Response Parameters . . . . . . . . . . . 13 5.5. Generic Request-Response Parameters .......................13
5.5.1. Mobile Node Identifier . . . . . . . . . . . . . . . . 13 5.5.1. Mobile Node Identifier .............................13
5.5.2. Authentication Method . . . . . . . . . . . . . . . . 14 5.5.2. Authentication Method ..............................13
5.5.3. Extensible Authentication Protocol Payload . . . . . . 14 5.5.3. Extensible Authentication Protocol Payload .........14
5.5.4. Status Code . . . . . . . . . . . . . . . . . . . . . 14 5.5.4. Status Code ........................................14
5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 14 5.5.5. Message Authenticator ..............................14
5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 15 5.5.6. Retry After ........................................14
5.5.7. End of Message Content . . . . . . . . . . . . . . . . 15 5.5.7. End of Message Content .............................14
5.5.8. Random Values . . . . . . . . . . . . . . . . . . . . 15 5.5.8. Random Values ......................................15
5.6. Security Association Configuration Parameters . . . . . . 15 5.6. Security Association Configuration Parameters .............15
5.6.1. Security Parameter Index . . . . . . . . . . . . . . . 16 5.6.1. Security Parameter Index ...........................15
5.6.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 16 5.6.2. MN-HA Shared Keys ..................................16
5.6.3. Security Association Validity Time . . . . . . . . . . 16 5.6.3. Security Association Validity Time .................16
5.6.4. Security association scope (SAS) . . . . . . . . . . . 16 5.6.4. Security Association Scope (SAS) ...................16
5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17 5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping ..17
5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18 5.7. Mobile IPv6 Bootstrapping Parameters ......................18
5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18 5.7.1. Home Agent Address .................................18
5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18 5.7.2. Mobile IPv6 Service Port Number ....................18
5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 18 5.7.3. Home Addresses and Home Network Prefix .............18
5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19 5.7.4. DNS Server .........................................19
5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19 5.8. Authentication of the Mobile Node .........................19
5.9. Extensible Authentication Protocol Methods . . . . . . . . 21 5.9. Extensible Authentication Protocol Methods ................22
6. Mobile Node to Home Agent communication . . . . . . . . . . . 23 6. Mobile Node to Home Agent Communication ........................23
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. General ...................................................23
6.2. PType and Security Parameter Index . . . . . . . . . . . . 24 6.2. PType and Security Parameter Index ........................25
6.3. Binding Management Message Formats . . . . . . . . . . . . 25 6.3. Binding Management Message Formats ........................25
6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27 6.4. Reverse-Tunneled User Data Packet Formats .................27
7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28 7. Route Optimization .............................................29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations ............................................29
8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29 8.1. New Registry: Packet Type .................................29
8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Status Codes ..............................................29
8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29 8.3. Port Numbers ..............................................29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations ........................................30
9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30 9.1. Discovery of the HAC ......................................30
9.2. Authentication and Key Exchange executed between the 9.2. Authentication and Key Exchange Executed between
MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 30 the MN and the HAC ........................................30
9.3. Protection of MN and HA Communication . . . . . . . . . . 33 9.3. Protection of MN and HA Communication .....................33
9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 34 9.4. AAA Interworking ..........................................35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 10. Acknowledgements ..............................................35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. References ....................................................35
11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 11.1. Normative References .....................................35
11.2. Informative References . . . . . . . . . . . . . . . . . . 35 11.2. Informative References ...................................36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Mobile IPv6 [RFC6275] signaling, and optionally user traffic, between Mobile IPv6 (MIPv6) [RFC6275] signaling, and optionally user traffic,
a mobile node (MN) and home agent (HA) are secured by IPsec between a Mobile Node (MN) and Home Agent (HA) are secured by IPsec
[RFC4301]. The current Mobile IPv6 security architecture is [RFC4301]. The current Mobile IPv6 security architecture is
specified in [RFC3776] and [RFC4877]. This security model requires a specified in [RFC3776] and [RFC4877]. This security model requires a
tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/ tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/
IPsec part of the IP stack. Client implementation experience has IPsec part of the IP stack. Client implementation experience has
shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly
complex. complex.
This document proposes an alternate security framework for Mobile This document proposes an alternate security framework for Mobile
IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify
implementations as well as make it easy to deploy the protocol implementations as well as make it easy to deploy the protocol
without compromising on security. Transport Layer Security (TLS) without compromising on security. Transport Layer Security (TLS)
[RFC5246] is widely implemented in almost all major operating systems [RFC5246] is widely implemented in almost all major operating systems
and extensively used by various applications. Instead of using IKEv2 and extensively used by various applications. Instead of using IKEv2
to establish security associations, the security framework proposed to establish security associations, the security framework proposed
in this document is based on TLS protected messages to exchange keys in this document is based on TLS-protected messages to exchange keys
and bootstrapping parameters between the Mobile Node and a new and bootstrapping parameters between the MN and a new functional
functional entity called as the Home Agent Controller (HAC). The entity called the "Home Agent Controller" (HAC). The Mobile IPv6
Mobile IPv6 signaling between the mobile node and home agent is signaling between the mobile node and home agent is subsequently
subsequently secured using the resulting keys and negotiated cipher secured using the resulting keys and negotiated ciphersuite. The HAC
suite. The HAC can be co-located with the HA, or can be an can be co-located with the HA, or it can be an independent entity.
independent entity. For the latter case, communication between HAC For the latter case, communication between the HAC and HA is not
and HA is not defined by this document. Such communication could be defined by this document. Such communication could be built on top
built on top of AAA protocols such as Diameter, for instance. of AAA protocols such as Diameter.
The primary advantage of using TLS based establishment of Mobile IP6 The primary advantage of using TLS for the establishment of Mobile
security associations compared to IKEv2 is the ease of implementation IPv6 security associations as compared to the use of IKEv2 is the
while providing an equivalent level of security. For the protection ease of implementation (especially on the mobile nodes) while
of signaling messages and user plane traffic a solution is provided providing an equivalent level of security. A solution which
that decouples Mobile IPv6 security from IPsec, thereby reducing decouples Mobile IPv6 security from IPsec, for securing signaling
messages and user plane traffic, is proposed herein that reduces
client implementation complexity. client implementation complexity.
The security framework proposed in this document is not intended to The security framework proposed in this document is not intended to
replace the currently specified architecture which relies on IPsec replace the currently specified architecture that relies on IPsec and
and IKEv2. It provides an alternative solution which is more optimal IKEv2. It provides an alternative solution that is more optimal for
for certain deployment scenarios. This and other alternative certain deployment scenarios. This and other alternative security
security models have been considered by the MEXT working group at the models have been considered by the MEXT working group at the IETF,
IETF, and it has been decided that the alternative solutions should and it has been decided that the alternative solutions should be
be published as Experimental RFCs, so that more implementation and published as Experimental RFCs, so that more implementation and
deployment experience with these models can be gathered. The working deployment experience with these models can be gathered. The status
group may reconsider the status of the different models in the of this proposal may be reconsidered in the future if it becomes
future, if it becomes clear that one is superior to the others. clear that it is superior to others.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Home Agent Controller (HAC): Home Agent Controller (HAC):
The home agent controller is a node responsible for bootstrapping The home agent controller is a node responsible for bootstrapping
Mobile IPv6 security associations between a mobile node and one or Mobile IPv6 security associations between a mobile node and one or
more home agents. The home agent controller also provides key more home agents. The home agent controller also provides key
distribution to both mobile nodes and home agents. Mobile IPv6 distribution to both mobile nodes and home agents. Mobile IPv6
bootstrapping is also performed by the HA in addition to the bootstrapping is also performed by the HA in addition to the
security association bootstrapping between the mobile node and security association bootstrapping between the mobile node and
home agent controller. home agent controller.
Binding Management Messages: Binding Management Messages:
Mobile IPv6 signaling messages between a mobile node and a home Mobile IPv6 signaling messages between a mobile node and a home
agent, correspondent node or mobility access point to manage the agent, correspondent node, or mobility access point to manage the
bindings are referred to as binding management messages. Binding bindings are referred to as binding management messages. Binding
Updates and Binding Acknowledgement messages are examples of Updates (BUs) and Binding Acknowledgement (BA) messages are
binding management messages. examples of binding management messages.
3. Background 3. Background
Mobile IPv6 design and specification was begun in the mid to late Mobile IPv6 design and specification began in the mid-to-late 90s.
90s. The security architecture of Mobile IPv6 was based on the The security architecture of Mobile IPv6 was based on the
understanding that IPsec is an inherent and integral part of the IPv6 understanding that IPsec is an inherent and integral part of the IPv6
stack and any protocol that needs security should use IPsec unless 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 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 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 MN and HA. Reusing security components that are an integral part
the IP stack is a good objective, in the case of Mobile IPv6, of the IP stack is a good design objective for any protocol; however,
implementation complexity increases. It should be noted that Mobile in the case of Mobile IPv6, it increases implementation complexity.
IPv4 [RFC5944] for example does not use IPsec for security and It should be noted that Mobile IPv4 [RFC5944], for example, does not
instead has specified its own security solution. Mobile IPv4 has use IPsec for security and instead has specified its own security
been implemented and deployed on a reasonably large scale and the solution. Mobile IPv4 has been implemented and deployed on a
security model has proven itself to be sound. reasonably large scale and the security model has proven itself to be
sound.
Mobile IPv6 standardization was completed in 2005 along with the Mobile IPv6 standardization was completed in 2005 along with the
security architecture using IKE/IPsec specified in RFC 3776 security architecture using IKE/IPsec specified in RFC 3776
[RFC3776]. With the evolution to IKEv2 [RFC5996], Mobile IP6 [RFC3776]. With the evolution to IKEv2 [RFC5996], Mobile IPv6
security has also been updated to rely on the use of IKEv2 [RFC4877]. security has also been updated to rely on the use of IKEv2 [RFC4877].
Implementation exercises of Mobile IPv6 and Dual-stack Mobile IPv6 Implementation exercises of Mobile IPv6 and Dual-Stack Mobile IPv6
[RFC5555] have identified the complexity of using IPsec and IKEv2 in [RFC5555] have identified the complexity of using IPsec and IKEv2 in
conjunction with Mobile IPv6. Implementing Mobile IPv6 with IPsec conjunction with Mobile IPv6. Implementing Mobile IPv6 with IPsec
and IKEv2 requires modifications to both the IPsec and IKEv2 and IKEv2 requires modifications to both the IPsec and IKEv2
components, due to the communication models that Mobile IPv6 uses and components, due to the communication models that Mobile IPv6 uses and
the changing IP addresses. For further details, see Section 7.1 in the changing IP addresses. For further details, see Section 7.1 in
[RFC3776]. [RFC3776].
This document proposes a security framework based on TLS protected This document proposes a security framework based on TLS-protected
establishment of Mobile IPv6 security associations with reduced establishment of Mobile IPv6 security associations, which reduces
implementation complexity, while maintaining an equivalent (to IKEv2/ implementation complexity while maintaining an equivalent (to IKEv2/
IPsec) level of security. IPsec) level of security.
4. TLS-based Security Establishment 4. TLS-Based Security Establishment
4.1. Overview 4.1. Overview
The security architecture proposed in this document relies on a The security architecture proposed in this document relies on a
secure TLS session established between the MN and the HAC for secure TLS session established between the MN and the HAC for mutual
authentication and MN-HA security association bootstrapping. authentication and MN-HA security association bootstrapping.
Authentication of the HAC is done via standard TLS operation wherein Authentication of the HAC is done via standard TLS operation wherein
the HAC uses a TLS server certificate as its credentials. MN the HAC uses a TLS server certificate as its credentials. MN
authentication is done by the HAC via signaling messages that are authentication is done by the HAC via signaling messages that are
secured by the TLS connection. Any EAP method can be used for secured by the TLS connection. Any Extensible Authentication
Protocol (EAP) method or Pre-Shared Key (PSK) can be used for
authenticating the MN to the HAC. Upon successful completion of authenticating the MN to the HAC. Upon successful completion of
authentication, the HAC generates keys which are delivered to the MN authentication, the HAC generates keys that are delivered to the MN
through the secure TLS channel. The same keys are also provided to through the secure TLS channel. The same keys are also provided to
the assigned HA. The HAC also provides the MN with MIP6 the assigned HA. The HAC also provides the MN with MIPv6
bootstrapping information such as the IPv6 and IPv4 address of the 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 HA, the home network prefix, the IPv6 and/or IPv4 Home Address (HoA),
address. and DNS server address.
The MN and HA use security associations based on the keys and SPIs The MN and HA use security associations based on the keys and
generated by the HAC and delivered to the MN and HA to secure Security Parameter Indexes (SPIs) generated by the HAC and delivered
signaling and optionally user plane traffic. Figure 1 below is an to the MN and HA to secure signaling and optionally user plane
illustration of the process. traffic. Figure 1 below is an illustration of the process.
Signaling messages and user plane traffic between the MN and HA are Signaling messages and user plane traffic between the MN and HA are
always UDP encapsulated. The packet formats for the signaling and always UDP encapsulated. The packet formats for the signaling and
user plane traffic is described in Sections 6.3 and 6.4. user plane traffic is described in Sections 6.3 and 6.4.
MN HAC HA MN HAC HA
-- --- -- -- --- --
| | | | | |
| /-------------------------\ | | | /-------------------------\ | |
|/ \| | |/ \| |
|\ TLS session setup /| | |\ TLS session setup /| |
| \-------------------------/ | | | \-------------------------/ | |
| | | | | |
| /-------------------------\ | | | /-------------------------\ | |
|/ MN Authentication \| | |/ MN Authentication \| |
|\ /| | |\ /| |
| \-------------------------/ | | | \-------------------------/ | |
| | | | | |
| /-------------------------\ | | | /-------------------------\ | |
|/ HAC provisions the MN \| | |/ HAC provisions the MN \| |
|\ keys, SPI and MIP6 parms /| | |\ keys, SPI, & MIPv6 parms /| |
| \-------------------------/ | | | \-------------------------/ | |
| |--MNID, keys, SPI->| | |--MNID, keys, SPI->|
| | | | | |
| /--------------------------------------------\ | | /--------------------------------------------\ |
|/ MN-HA SA established; Secures \ | |/ MN-HA SA established; Secures \ |
|\ signaling and optionally user traffic / | |\ signaling and optionally user traffic / |
| \--------------------------------------------/ | | \--------------------------------------------/ |
| | | |
|------------BU(encrypted)----------------------->| |------------BU(encrypted)----------------------->|
| | | |
|<---------BAck(encrypted)------------------------| |<---------BAck(encrypted)------------------------|
Figure 1: High level architecture Figure 1: High-Level Architecture
4.2. Architecture 4.2. Architecture
The TLS-based security architecture is shown in Figure 2. The The TLS-based security architecture is shown in Figure 2. The
signaling message exchange between the MN and the HAC is protected by 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 TLS. It should be noted that an HAC, a AAA server, and an HA are
logically separate entities and can be collocated in all possible logically separate entities and can be collocated in all possible
combinations. There MUST be a strong trust relationship between the combinations. There MUST be a strong trust relationship between the
HA and the HAC, and the communication between them MUST be both HA and the HAC, and the communication between them MUST be both
integrity and confidentially protected. integrity and confidentially protected.
+------+ +------+ +------+ +------+ +------+ +------+
|Mobile| TLS |Home | AAA | AAA | |Mobile| TLS |Home | AAA | AAA |
| Node |<----------->|Agent |<---------->|Server| | Node |<----------->|Agent |<---------->|Server|
| | |Contrl| | | | | |Contrl| | |
+------+ +------+ +------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^
| | | | | |
| BU/BA/../ | e.g. AAA | AAA | BU/BA/../ | e.g., AAA | AAA
| (Data) | | | (Data) | |
| v | | v |
| +---------+ | | +---------+ |
| | MIPv6 | | | | MIPv6 | |
+--------------->| Home |<-------------+ +--------------->| Home |<-------------+
| Agent(s)| | Agent(s)|
+---------+ +---------+
Figure 2: TLS-based Security Architecture Overview Figure 2: TLS-Based Security Architecture Overview
4.3. Security Association Management 4.3. Security Association Management
Once the MN has contacted the HAC and mutual authentication has taken 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 place between the MN and the HAC, the HAC securely provisions the MN
with all security related information inside the TLS protected with all security-related information inside the TLS protected
tunnel. This security related information constitutes a security tunnel. This security-related information constitutes a security
association (SA) between the MN and the HA. The created SA MUST NOT association (SA) between the MN and the HA. The created SA MUST NOT
be tied to the Care-of Address (CoA) of the MN. be tied to the Care-of Address (CoA) of the MN.
The HAC may proactively distribute the SA information to HAs, or the 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 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 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 be able to query/index the SA information from the HAC based on the
Security Parameter Index (SPI) identifying the correct security SPI identifying the correct security association between the MN and
association between the MN and the HA. the HA.
The HA may want the MN to re-establish the SA even if the existing SA 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 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, 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 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. would provision the MN and HAs with a new SA to be used subsequently.
The SA established between MN and HAC SHALL contain at least the The SA established between MN and HAC SHALL contain at least the
following information: following information:
skipping to change at page 9, line 20 skipping to change at page 8, line 35
A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering
Mobile IPv6 traffic between the MN and the HA. The HAC is Mobile IPv6 traffic between the MN and the HA. The HAC is
responsible for generating these keys. The key generation responsible for generating these keys. The key generation
algorithm is specific to the HAC implementation. algorithm is specific to the HAC implementation.
MN-HA shared key for integrity protection: MN-HA shared key for integrity protection:
A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity
protecting Mobile IPv6 traffic between the MN and the HA. This protecting Mobile IPv6 traffic between the MN and the HA. This
includes both binding management messages and reverse tunneled includes both binding management messages and reverse-tunneled
user data traffic between the MN and the HA. The HAC is user data traffic between the MN and the HA. The HAC is
responsible for generating these keys. The key generation responsible for generating these keys. The key generation
algorithm is specific to the HAC implementation. In case of algorithm is specific to the HAC implementation. In the case of
combined algorithms a separate integrity protection key is not combined algorithms, a separate integrity protection key is not
needed and may be omitted, i.e., the encryption keys SHALL be needed and may be omitted, i.e., the encryption keys SHALL be
used. used.
Security association validity time: Security association validity time:
This parameter represents the validity time for the security This parameter represents the validity time for the security
association. The HAC is responsible for defining the lifetime association. The HAC is responsible for defining the lifetime
value based on its policies. The lifetime may be in the order of 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 hours or weeks. The MN MUST re-contact the HAC before the SA
validity time ends. validity time ends.
Security Association Scope: Security association scope:
This parameter defines whether the security association is applied This parameter defines whether the security association is applied
to Mobile IPv6 signaling messages only, or to both Mobile IPv6 to Mobile IPv6 signaling messages only or to both Mobile IPv6
signaling messages and data traffic. signaling messages and data traffic.
Selected ciphersuite: Selected ciphersuite:
This parameter is the ciphersuite used to protect the traffic This parameter is the ciphersuite used to protect the traffic
between the MN and the HA. This includes both binding management between the MN and the HA. This includes both binding management
messages and reverse tunneled user data traffic between the MN and messages and reverse-tunneled user data traffic between the MN and
the HA. The selected algorithms SHOULD be one of the mutually the HA. The selected algorithms SHOULD be one of the mutually
supported ciphersuites of the negotiated TLS version between the supported ciphersuites of the negotiated TLS version between the
MN and the HAC. The HAC is responsible for choosing the mutually MN and the HAC. The HAC is responsible for choosing the mutually
supported ciphersuite that complies with the policy of the HAC. supported ciphersuite that complies with the policy of the HAC.
Obviously, the HAs under HAC's management must have at least one 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 ciphersuite with the HAC in common and need to be aware of the
implemented ciphersuites. The selected ciphersuite is the same implemented ciphersuites. The selected ciphersuite is the same
for both directions (MN -> HA and HA -> MN). for both directions (MN -> HA and HA -> MN).
Sequence numbers: Sequence numbers:
skipping to change at page 10, line 20 skipping to change at page 9, line 37
A monotonically increasing unsigned sequence number used in all A monotonically increasing unsigned sequence number used in all
protected packets exchanged between the MN and the HA in the same protected packets exchanged between the MN and the HA in the same
direction. Sequence numbers are maintained per direction, so each direction. Sequence numbers are maintained per direction, so each
SA includes two independent sequence numbers (MN -> HA, HA -> MN). SA includes two independent sequence numbers (MN -> HA, HA -> MN).
The initial sequence number for each direction MUST always be set The initial sequence number for each direction MUST always be set
to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing
beyond their maximum defined value. beyond their maximum defined value.
4.4. Bootstrapping of Additional Mobile IPv6 Parameters 4.4. Bootstrapping of Additional Mobile IPv6 Parameters
When the MN contacts the HAC to distribute the security related When the MN contacts the HAC to distribute the security-related
information, the HAC may also provision the MN with various Mobile information, the HAC may also provision the MN with various MIPv6-
IPv6 related bootstrapping information. Bootstrapping of the related bootstrapping information. Bootstrapping of the following
following information SHOULD at least be possible: information SHOULD at least be possible:
Home Agent IP Address: Home Agent IP Address:
Concerns both IPv6 and IPv4 home agent addresses. The IPv6 and IPv4 address of the home agent assigned by the HAC.
Mobile IPv6 Service Port Number: Mobile IPv6 Service Port Number:
The port number where the HA is listening to UDP [RFC0768] The port number where the HA is listening to UDP [RFC0768]
packets. packets.
Home Address: Home Address:
Concerns both IPv6 and IPv4 Home Addresses. The IPv6 and/or IPv4 home address assigned to the mobile node by
the HAC.
Home Link Prefix: Home Link Prefix:
Concerns the IPv6 Home link prefix and the associated prefix Concerns the IPv6 Home link prefix and the associated prefix
length. length.
DNS Server Address: DNS Server Address:
The address of a DNS server that can be reached via the HA. DNS 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 queries in certain cases cannot be routed to the DNS servers
assigned by the access network to which the MN is attached and assigned by the access network to which the MN is attached; hence,
hence an additional DNS server address which is reachable via the an additional DNS server address that is reachable via the HA
HA needs to be configured. needs to be configured.
The Mobile IPv6 related bootstrapping information is delivered from The MIPv6-related bootstrapping information is delivered from the HAC
the HAC to the MN over the same TLS protected tunnel as the security to the MN over the same TLS protected tunnel as the security related
related information. information.
4.5. Protecting Traffic Between Mobile Node and Home Agent 4.5. Protecting Traffic between Mobile Node and Home Agent
The same integrity and confidentiality algorithms MUST be used to The same integrity and confidentiality algorithms MUST be used to
protect both binding management messages and reverse tunneled user protect both binding management messages and reverse-tunneled user
data traffic between the MN and the HA. Generally, all binding data traffic between the MN and the HA. Generally, all binding
management messages (BUs, BAs and so on) MUST be integrity protected management messages (BUs, BAs, and so on) MUST be integrity protected
and SHOULD be confidentially protected. The reverse tunneled user and SHOULD be confidentially protected. The reverse-tunneled user
data traffic SHOULD be equivalently protected. Generally, the data traffic SHOULD be equivalently protected. Generally, the
requirements stated in [RFC6275] concerning the protection of the requirements stated in [RFC6275] concerning the protection of the
traffic between the MN and the HA also apply to the mechanisms traffic between the MN and the HA also apply to the mechanisms
defined by this specification. defined by this specification.
5. Mobile Node to Home Agent Controller Communication 5. MN-to-HAC Communication
5.1. Request-response Message Framing over TLS-tunnel 5.1. Request-Response Message Framing over TLS-Tunnel
The MN and the HAC communicate with each other using a simple lock- The MN and the HAC communicate with each other using a simple
step request-response protocol that is run inside the protected TLS- lockstep request-response protocol that is run inside the protected
tunnel. A generic message container framing for the request messages TLS-tunnel. A generic message container framing for the request
and for the response messages is defined. The message containers are messages and for the response messages is defined. The message
only meant to be exchanged on top of connection oriented TLS-layer. containers are only meant to be exchanged on top of a connection-
Therefore, the end of message exchange is determined by the other end oriented TLS-layer. Therefore, the end of message exchange is
closing the transport connection (assuming the "application layer" determined by the other end closing the transport connection
has also indicated the completion of the message exchange). The peer (assuming the "application layer" has also indicated the completion
initiating the TLS-connection is always sending "Requests" and the of the message exchange). The peer initiating the TLS connection is
peer accepting the TLS-connection is always sending "Responses". The always sending "Requests", and the peer accepting the TLS connection
format of the message container is shown in Figure 3. is always sending "Responses". The format of the message container
is shown in Figure 3.
All data inside the Content portion of the message container MUST be All data inside the Content portion of the message container MUST be
encoded using octets. Fragmentation of message containers is not encoded using octets. Fragmentation of message containers is not
supported, which means one request or response at the "application supported, which means one request or response at the "application
layer" MUST NOT exceed the maximum size allowed by the message layer" MUST NOT exceed the maximum size allowed by the message
container format. container format.
0 1 2 3 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 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 | | Ver | Rsrvd | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content portion.. ~ | Content portion.. ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Request-Response Message Container Figure 3: Request-Response Message Container
The three bit Ver field identifies the protocol version. The current The 3-bit Ver field identifies the protocol version. The current
version is 0 i.e. all bits are set to value 0 (zero). version is 0, i.e., all bits are set to a value of 0 (zero).
The Rsrvd field MUST be set to value 0 (zero), The Rsrvd field MUST be set to a value of 0 (zero),
The Identifier field is meant for matching requests and responses. The Identifier field is meant to match requests and responses. The
The valid Identifier values are between 1-255. The value 0 MUST NOT valid Identifier values are between 1-255. The value 0 MUST NOT be
be used. The first request for each communication session between used. The first request for each communication session between the
the MN and the HAC MUST have the Identifier values set to 1. MN and the HAC MUST have the Identifier values set to 1.
The Length field tells the length of the Content portion of the The Length field tells the length of the Content portion of the
container (i.e. Reserved octet, Identifier octet and Length field container (i.e., Reserved octet, Identifier octet, and Length field
are excluded). The Content portion length MUST always be at least are excluded). The Content portion length MUST always be at least
one octet up to 65535 octets. The value is in network order. one octet and up to 65535 octets. The value is in network order.
5.2. Request-response Message Content Encoding 5.2. Request-Response Message Content Encoding
The encoding of the message content is similar to HTTP header The encoding of the message content is similar to HTTP header
encoding, and complies to the augmented Backus-Naur Form (BNF) encoding and complies with the augmented Backus-Naur Form (BNF)
defined in Section 2.1 of [RFC2616]. All presented hexadecimal defined in Section 2.1 of [RFC2616]. All presented hexadecimal
numbers are in network byte order. From now on, we use TypeValue numbers are in network byte order. From now on, we use the TypeValue
header (TV-header) term to refer request-response message content header (TV-header) term to refer to request-response message content
HTTP-like headers. HTTP-like headers.
5.3. Request-Response Message Exchange 5.3. Request-Response Message Exchange
The message exchange between the MN and the HAC is a simple lock-step The message exchange between the MN and the HAC is a simple lockstep
request-response type as stated in Section 5.1. A request message request-response type as stated in Section 5.1. A request message
includes monotonically increasing Identifier value that is copied to includes a monotonically increasing Identifier value that is copied
the corresponding response message. Each request MUST have a to the corresponding response message. Each request MUST have a
different Identifier value. Hence, a reliable connection oriented different Identifier value. Hence, a reliable connection-oriented
transport below the message container framing is assumed. The number transport below the message container framing is assumed. The number
of request-response message exchanges MUST NOT exceed 255. of request-response message exchanges MUST NOT exceed 255.
Each new communication session between the MN and the HAC MUST reset 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 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 only request messages and the HAC only sends response messages. Once
the request-response message exchange completes, the HAC and the MN the request-response message exchange completes, the HAC and the MN
MUST close the transport connection and the corresponding TLS-tunnel. MUST close the transport connection and the corresponding TLS-tunnel.
In a case of a HAC side error, the HAC MUST send a response back to a In the case of an HAC-side error, the HAC MUST send a response back
MN with an appropriate status code and then close the transport to an MN with an appropriate status code and then close the transport
connection. connection.
The first request message - MHAuth-Init - (i.e. the Identifier is 1) The first request message - MHAuth-Init - (i.e., the Identifier is 1)
MUST always contain at least the following parameters: MUST always contain at least the following parameters:
MN-Identity - See Section 5.5.1. MN-Identity - See Section 5.5.1.
Authentication Method - See Section 5.5.2. Authentication Method - See Section 5.5.2.
The first response message - MHAuth-Init - (i.e. the Identifier is 1) The first response message - MHAuth-Init - (i.e., the Identifier is
MUST contain at minimum the following parameters: 1) MUST contain at minimum the following parameters:
Selected authentication Method - See Section 5.5.2. Selected authentication Method - See Section 5.5.2.
The last request message from the MN side - MHAuth-Done - MUST The last request message from the MN side - MHAuth-Done - MUST
contain the following parameters: contain the following parameters:
Security Association Scope - See Section 5.6.4. Security association scope - See Section 5.6.4.
Proposed ciphersuites - See Section 5.6.5. Proposed ciphersuites - See Section 5.6.5.
Message Authenticator - See Section 5.5.5. Message Authenticator - See Section 5.5.5.
The last response message - MHAuth-Done - that ends the request- The last response message - MHAuth-Done - that ends the request-
response message exchange MUST contain the following parameters: response message exchange MUST contain the following parameters:
Status Code - See Section 5.5.4. Status Code - See Section 5.5.4.
Message Authenticator - See Section 5.5.5. Message Authenticator - See Section 5.5.5.
And in a case of successful authentication the following additional In the case of successful authentication, the following additional
parameters: parameters:
Selected ciphersuite - See Section 5.6.5. Selected ciphersuite - See Section 5.6.5.
Security Association Scope - See Section 5.6.4.
Security association scope - See Section 5.6.4.
The rest of the security association data - See Section 5.6. The rest of the security association data - See Section 5.6.
5.4. Home Agent Controller Discovery 5.4. Home Agent Controller Discovery
All bootstrapping information, whether for setting up the SA or for All bootstrapping information, whether for setting up the SA or for
bootstrapping Mobile IPv6 specific information, is exchanged between bootstrapping MIPv6-specific information, is exchanged between the MN
the MN and the HAC using the framing protocol defined in Section 5.1. and the HAC using the framing protocol defined in Section 5.1. The
The IP address of the HAC MAY be statically configured to the MN or IP address of the HAC MAY be statically configured in the MN or
may be dynamically discovered using DNS. In a case of DNS-based HAC alternatively MAY be dynamically discovered using DNS. In the case
discovery, the MN either queries an A/AAAA or a SRV record for the of DNS-based HAC discovery, the MN queries either an A/AAAA or a SRV
HAC IP address. The actual domain name used in queries is up to the record for the HAC IP address. The actual domain name used in
deployment to decide and out of scope of this specification. queries is up to the deployment to decide and out of scope of this
specification.
5.5. Generic Request-Response Parameters 5.5. Generic Request-Response Parameters
The grammar used in the following sections is the augmented Backus- The grammar used in the following sections is the augmented Backus-
Naur Form (BNF) same to that used by HTTP [RFC2616]. Naur Form (BNF), the same as that used by HTTP [RFC2616].
5.5.1. Mobile Node Identifier 5.5.1. Mobile Node Identifier
An identifier that identifies a MN. The Mobile Node Identifier is in An identifier that identifies an MN. The Mobile Node Identifier is
form of a Network Access Identifier (NAI) [RFC4282]. in the form of a Network Access Identifier (NAI) [RFC4282].
mn-id = "mn-id" ":" RFC4282-NAI CRLF mn-id = "mn-id" ":" RFC4282-NAI CRLF
5.5.2. Authentication Method 5.5.2. Authentication Method
The HAC is the peer that mandates the authentication method. The MN The HAC is the peer that mandates the authentication method. The MN
sends its authentication method proposal to the HAC. The HAC, upon sends its authentication method proposal to the HAC. The HAC, upon
receipt of the MN proposal returns the selected authentication receipt of the MN proposal, returns the selected authentication
method. The MN MUST propose at least one authentication method. The method. The MN MUST propose at least one authentication method. The
HAC MUST select exactly one authentication method, or return an error HAC MUST select exactly one authentication method or return an error
and then close the connection. and then close the connection.
auth-method = "auth-method" ":" a-method *("," a-method) CRLF auth-method = "auth-method" ":" a-method *("," a-method) CRLF
a-method = a-method =
"psk" ; Pre-shared key based authentication "psk" ; PSK-based authentication
| "eap" ; EAP-based authentication | "eap" ; EAP-based authentication
5.5.3. Extensible Authentication Protocol Payload 5.5.3. Extensible Authentication Protocol Payload
Each Extensible Authentication Protocol (EAP) [RFC3748] message is an Each Extensible Authentication Protocol (EAP) [RFC3748] message is an
encoded string of hexadecimal numbers. The "eap-payload" is encoded string of hexadecimal numbers. The "eap-payload" is
completely transparent what EAP-method or EAP message is carried completely transparent as to which EAP-method or EAP message is
inside it. The "eap-payload" can appear in both request and response carried inside it. The "eap-payload" can appear in both request and
messages: response messages:
eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF
5.5.4. Status Code 5.5.4. Status Code
The "status-code" MUST only be present in the response message that The "status-code" MUST only be present in the response message that
ends the request-response message exchange. The "status-code" ends the request-response message exchange. The "status-code"
follows the principles of HTTP and the definitions found in Section follows the principles of HTTP and the definitions found in Section
10 of RFC 2616 also apply for these status codes listed below: 10 of RFC 2616 also apply for these status codes listed below:
skipping to change at page 15, line 30 skipping to change at page 15, line 19
encoding): encoding):
mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF
hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF
5.6. Security Association Configuration Parameters 5.6. Security Association Configuration Parameters
During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a
single ciphersuite for protecting the traffic between the MN and the single ciphersuite for protecting the traffic between the MN and the
HA. The allowed ciphersuites for this specification are a subset of HA. The allowed ciphersuites for this specification are a subset of
those in TLS v1.2 (see Annex A.5 of [RFC5246]) as per Section 5.6.5. those in TLS version 1.2 (see Appendix A.5 of [RFC5246]) per
This might appear as a constraint as the HA and the HAC may have Section 5.6.5. This might appear as a constraint as the HA and the
implemented different ciphersuites. These two nodes are, however, HAC may have implemented different ciphersuites. These two nodes
assumed to belong to the same administrative domain. In order to are, however, assumed to belong to the same administrative domain.
avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol In order to avoid exchanging supported MN-HA ciphersuites in the MN-
and to reuse the TLS ciphersuite negotiation procedure we make this HAC protocol and to reuse the TLS ciphersuite negotiation procedure,
simplifying assumption. The selected ciphersuite MUST provide we make this simplifying assumption. The selected ciphersuite MUST
integrity and confidentiality protection. provide integrity and confidentiality protection.
Section 5.6.5 provides the mapping from the TLS ciphersuites to the Section 5.6.5 provides the mapping from the TLS ciphersuites to the
integrity and encryption algorithms allowed for MN-HA protection. integrity and encryption algorithms allowed for MN-HA protection.
This mapping mainly ignores the authentication algorithm part that is This mapping mainly ignores the authentication algorithm part that is
not required within the context of this specification. For example, not required within the context of this specification. For example,
[RFC5246] defines a number of AES based ciphersuites for TLS [RFC5246] defines a number of AES-based ciphersuites for TLS
including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification,
relevant part is 'AES_128_CBC_SHA'. the relevant part is 'AES_128_CBC_SHA'.
All the parameters described in the following sections apply only to All the parameters described in the following sections apply only to
a request-response protocol response message to the MN. The MN has a request-response protocol response message to the MN. The MN has
no way affecting to the provisioning decision of the HAC. no way of affecting the provisioning decision of the HAC.
5.6.1. Security Parameter Index 5.6.1. Security Parameter Index
The 28-bit unsigned SPI number identifies the SA used between the MN 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. and the HA. The value 0 (zero) is reserved and MUST NOT be used.
Therefore, values ranging from 1 to 268435455 are valid. Therefore, values ranging from 1 to 268435455 are valid.
The TV-header corresponding to the SPI number is: The TV-header corresponding to the SPI number is as follows:
mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF
5.6.2. MN-HA Shared Keys 5.6.2. MN-HA Shared Keys
The MN-HA shared integrity (ikey) and encryption (ekey) keys are used 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 to protect the traffic between the MN and the HA. The length of
these keys depend on the selected ciphersuite. these keys depend on the selected ciphersuite.
The TV-headers that carry these two parameters are: The TV-headers that carry these two parameters are the following:
mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF
mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF
5.6.3. Security Association Validity Time 5.6.3. Security Association Validity Time
The end of the SA validity time is encoded using the "rfc1123-date" The end of the SA validity time is encoded using the "rfc1123-date"
format, as defined in Section 3.3.1 of [RFC2616]. format, as defined in Section 3.3.1 of [RFC2616].
The TV-header corresponding to the SA validity time value is: The TV-header corresponding to the SA validity time value is as
follows:
mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date CRLF
CRLF
5.6.4. Security association scope (SAS) 5.6.4. Security Association Scope (SAS)
The SA is applied either to Mobile IPv6 signaling messages only, or The SA is applied either to Mobile IPv6 signaling messages only or to
to both Mobile IPv6 signaling messages and data traffic. This policy both Mobile IPv6 signaling messages and data traffic. This policy
MUST be agreed between the MN and HA prior to using the SA. 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 Otherwise, the receiving side will be unaware of whether the SA
applies to data traffic and could not decide how to act when applies to data traffic and hence unable to decide how to act when
receiving unprotected packets of PType 1 (see Section 6.4). receiving unprotected packets of PType 1 (see Section 6.4).
mip6-sas = "mip6-sas" ":" 1DIGIT CRLF mip6-sas = "mip6-sas" ":" 1DIGIT CRLF
where a value of "0" indicates that the SA does not protect data where a value of "O" indicates that the SA does not protect data
traffic and a value of "1" indicates that all data traffic MUST be 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 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 packet received with a PType value that does not match the mip6-sas
value of the SA MUST be silently discarded. value of the SA MUST be silently discarded.
The HAC is the peer that mandates the used security association The HAC is the peer that mandates the used security association
scope. The MN sends its proposal to the HAC but eventually the scope. The MN sends its proposal to the HAC, but eventually the
security association scope returned from the HAC defines the used security association scope returned from the HAC defines the used
scope. scope.
5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping 5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping
The ciphersuite negotiation between HAC and MN uses a subset of the The ciphersuite negotiation between HAC and MN uses a subset of the
TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation
defined in Annex A.5 of [RFC5246]. The TV-headers corresponding to defined in Appendix A.5 of [RFC5246]. The TV-headers corresponding
the selected ciphersuite and ciphersuite list are: to the selected ciphersuite and ciphersuite list are the following:
mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
csuite = "{" suite "}" csuite = "{" suite "}"
suite = suite =
"00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02} "00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02}
| "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B} | "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B}
| "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A} | "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A}
| "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F} | "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F}
| "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C} | "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C}
mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF
All other Ciphersuite values are reserved. All other Ciphersuite values are reserved.
The following integrity algorithms MUST be supported by all The following integrity algorithms MUST be supported by all
implementations: implementations:
HMAC-SHA1-96 [RFC2404] HMAC-SHA1-96 [RFC2404]
AES-XCBC-MAC-96 [RFC3566] AES-XCBC-MAC-96 [RFC3566]
skipping to change at page 17, line 47 skipping to change at page 17, line 42
integrity protected. Implementations MUST NOT use a NULL integrity integrity protected. Implementations MUST NOT use a NULL integrity
algorithm. algorithm.
The following encryption algorithms MUST be supported: The following encryption algorithms MUST be supported:
NULL [RFC2410] NULL [RFC2410]
TripleDES-CBC [RFC2451] TripleDES-CBC [RFC2451]
AES-CBC with 128-bit keys [RFC3602] AES-CBC with 128-bit keys [RFC3602]
Traffic between MN and HA MAY be encrypted. Any integrity-only Traffic between MN and HA MAY be encrypted. Any integrity-only
CipherSuite makes use of the NULL encryption algorithm. Ciphersuite makes use of the NULL encryption algorithm.
Note: In the present version, this document does not consider Note: This document does not consider combined algorithms. The
combined algorithms. The following table provides the mapping of following table provides the mapping of each ciphersuite to a
each ciphersuite to a combination of integrity and encryption combination of integrity and encryption algorithms that are part of
algorithms that are part of the negotiated SA between MN and HA. the negotiated SA between MN and HA.
+-------------------+-----------------+--------------------------+ +-------------------+-----------------+--------------------------+
|Ciphersuite |Integ. Algorithm |Encr. Algorithm | |Ciphersuite |Integ. Algorithm |Encr. Algorithm |
+-------------------+-----------------+--------------------------+ +-------------------+-----------------+--------------------------+
|NULL_SHA |HMAC-SHA1-96 |NULL | |NULL_SHA |HMAC-SHA1-96 |NULL |
|NULL_SHA256 |AES-XCBC-MAC-96 |NULL | |NULL_SHA256 |AES-XCBC-MAC-96 |NULL |
|3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC | |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_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys |
|AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys | |AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys |
+-------------------+----------------+---------------------------+ +-------------------+----------------+---------------------------+
Ciphersuite-to-Algorithm Mapping Ciphersuite-to-Algorithm Mapping
5.7. Mobile IPv6 Bootstrapping Parameters 5.7. Mobile IPv6 Bootstrapping Parameters
In parallel with the SA bootstrapping, the HAC SHOULD provision the In parallel with the SA bootstrapping, the HAC SHOULD provision the
MN with relevant Mobile IPv6 related bootstrapping information. MN with relevant MIPv6-related bootstrapping information.
The following generic BNFs are used to form IP addresses and The following generic BNFs are used to form IP addresses and
prefixes. They are used in subsequent sections. prefixes. They are used in subsequent sections.
ip6-addr = 7( word ":" ) word CRLF ip6-addr = 7( word ":" ) word CRLF
word = 1*4HEX word = 1*4HEX
ip6-prefix = ip6-addr "/" 1*2DIGIT ip6-prefix = ip6-addr "/" 1*2DIGIT
ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
ip4-subnet = ip4-addr "/" 1*2DIGIT ip4-subnet = ip4-addr "/" 1*2DIGIT
5.7.1. Home Agent Address 5.7.1. Home Agent Address
The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, The HAC MAY provision the MN with an IPv4 or an IPv6 address of an
or both. HA, or both.
mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF
mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF
5.7.2. Mobile IPv6 Service Port Number 5.7.2. Mobile IPv6 Service Port Number
The HAC SHOULD provision the MN with an UDP port number, where the HA 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, expects to receive UDP packets. If this parameter is not present,
then the IANA reserved port number (HALTSEC) MUST be used instead. then the IANA reserved port number (mipv6tls) MUST be used instead.
mip6-port = "mip6-port" ":" 1*5DIGIT CRLF mip6-port = "mip6-port" ":" 1*5DIGIT CRLF
5.7.3. Home Addresses and Home Network Prefix 5.7.3. Home Addresses and Home Network Prefix
The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or 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 both. The HAC MAY also provision the MN with its home network
prefix. prefix.
mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF
skipping to change at page 19, line 24 skipping to change at page 19, line 23
options. These DNS servers are reachable via the home agent. options. These DNS servers are reachable via the home agent.
dns-ip6 = "dns-ip6" ":" ip6-addr CRLF dns-ip6 = "dns-ip6" ":" ip6-addr CRLF
dns-ip4 = "dns-ip4" ":" ip4-addr CRLF dns-ip4 = "dns-ip4" ":" ip4-addr CRLF
5.8. Authentication of the Mobile Node 5.8. Authentication of the Mobile Node
This section describes the basic operation required for the MN-HAC This section describes the basic operation required for the MN-HAC
mutual authentication and the channel binding. The authentication mutual authentication and the channel binding. The authentication
protocol described as part of this section is a simple exchange that protocol described as part of this section is a simple exchange that
follows the GPSK exchange used by EAP-GPSK [RFC5433]. It is secured follows the Generalized Pre-Shared Key (GPSK) exchange used by EAP-
by the TLS tunnel and is cryptographically bound to the TLS tunnel GPSK [RFC5433]. It is secured by the TLS tunnel and is
through channel binding based on [RFC5056] and on the channel binding cryptographically bound to the TLS tunnel through channel binding
type 'tls-server-endpoint' described in [RFC5929]. As a result of based on [RFC5056] and on the channel binding type 'tls-server-
the channel binding type, this method can only be used with TLS endpoint' described in [RFC5929]. As a result of the channel binding
ciphersuites that use server certificates and the Certificate type, this method can only be used with TLS ciphersuites that use
handshake message. For example, TLS ciphersuites based on PSK or server certificates and the Certificate handshake message. For
anonymous authentication cannot be used. example, TLS ciphersuites based on PSK or anonymous authentication
cannot be used.
The authentication exchange MUST be performed through the encrypted The authentication exchange MUST be performed through the encrypted
TLS tunnel. It performs mutual authentication between the MN and the 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 HAC based on a PSK or based on an EAP-method (see Section 5.9). Note
Section 5.9). The PSK protocol is described in this section. It that an HAC MUST NOT allow MNs to renegotiate TLS sessions. The PSK
consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth- protocol is described in this section. It consists of the message
Done) in which both sides exchange nonces and their identities, and exchanges (MHAuth-Init, MHAuth-Mid, MHAuth-Done) in which both sides
compute and exchange a message authenticator 'auth' over the exchange nonces and their identities, and compute and exchange a
previously exchanged values, keyed with the pre-shared key. The message authenticator 'auth' over the previously exchanged values,
MHAuth-Done messages are used to deal with error situations. Key keyed with the pre-shared key. The MHAuth-Done messages are used to
binding with the TLS tunnel is ensured by channel binding of the type deal with error situations. Key binding with the TLS tunnel is
"tls-server-endpoint" as described by [RFC5929] where the hash of the ensured by channel binding of the type "tls-server-endpoint" as
TLS server certificate serves as input to the 'auth' calculation of described by [RFC5929] where the hash of the TLS server certificate
the MHAuth messages. serves as input to the 'auth' calculation of the MHAuth messages.
Note: The authentication exchange is based on the GPSK exchange used Note: The authentication exchange is based on the GPSK exchange used
by EAP-GPSK. In comparison to GPSK, it does not support exchanging by EAP-GPSK. In comparison to GPSK, it does not support exchanging
an encrypted container (it always runs through an already protected an encrypted container (it always runs through an already protected
TLS tunnel). Furthermore, the initial request of the authentication TLS tunnel). Furthermore, the initial request of the authentication
exchange (MHAuth-Init) is sent by the MN (client side) and is exchange (MHAuth-Init) is sent by the MN (client side) and is
comparable to EAP-Response/Identity, which reverses the roles of comparable to EAP-Response/Identity, which reverses the roles of
request and response messages compared to EAP-GPSK. Figure 4 shows a request and response messages compared to EAP-GPSK. Figure 4 shows a
successful protocol exchange. successful protocol exchange.
skipping to change at page 20, line 26 skipping to change at page 20, line 26
| Request/MHAuth-Done (...) | | Request/MHAuth-Done (...) |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| Response/MHAuth-Done (...) | | Response/MHAuth-Done (...) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
Figure 4: Authentication of the Mobile Node Using Shared Secrets Figure 4: Authentication of the Mobile Node Using Shared Secrets
1) Request/MHAuth-Init: (MN -> HAC) 1) Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=psk mn-id, mn-rand, auth-method=psk
2) Response/MHAuth-Init: (MN <- HAC) 2) Response/MHAuth-Init: (MN <- HAC)
[mn-rand, hac-rand, auth-method=psk, [status],] auth [mn-rand, hac-rand, auth-method=psk, [status],] auth
3) Request/MHAuth-Done: (MN -> HAC) 3) Request/MHAuth-Done: (MN -> HAC)
mn-rand, hac-rand, sa-scope, ciphersuite-list, auth mn-rand, hac-rand, sa-scope, ciphersuite-list, auth
4) Response/MHAuth-Done: (MN <- HAC) 4) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand,
hac-rand, status, auth hac-rand, status, auth
Where: Where 'auth' for MN -> HAC direction is as follows:
auth = HMAC-SHA256(PSK, msg-octets | CB-octets) auth = HMAC-SHA256(PSK, "MN" | msg-octets | CB-octets)
Where 'auth' for MN <- HAC direction is as follows:
auth = HMAC-SHA256(PSK, "HAC" | msg-octets | CB-octets)
In the above, "MN" is 2 ASCII characters without null termination and
"HAC" is 3 ASCII characters without null termination.
The length "mn-rand", "hac-rand" is 32 octets. Note that "|" The length "mn-rand", "hac-rand" is 32 octets. Note that "|"
indicates concatenation and optional parameters are shown in square indicates concatenation and optional parameters are shown in square
brackets [..]. The square brackets can be nested. brackets [..]. The square brackets can be nested.
The shared secret PSK can be variable length. 'msg-octets' includes The shared secret PSK can be variable length. 'msg-octets' includes
all payload parameters of the respective message to be signed except all payload parameters of the respective message to be signed except
the 'auth' payload. CB-octets is the channel binding input to the the 'auth' payload. CB-octets is the channel binding input to the
auth calculation that is the "TLS-server-endpoint" channel binding auth calculation that is the "TLS-server-endpoint" channel binding
type. The content and algorithm (only required for the "TLS-server- type. The content and algorithm (only required for the "TLS-server-
endpoint" type) are the same as described in [RFC5929]. endpoint" type) are the same as described in [RFC5929].
The MN starts by selecting a random number 'mn-rand' and choosing a The MN starts by selecting a random number 'mn-rand' and choosing a
list of supported authentication methods coded in 'auth-method'. The list of supported authentication methods coded in 'auth-method'. The
MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to the HAC MN sends its identity 'mn-id', 'mn-rand', and 'auth-method' to the
in MHAuth-Init. The decision of which authentication method to offer HAC in MHAuth-Init. The decision of which authentication method to
and which to pick is policy- and implementation-dependent and, offer and which to pick is policy and implementation dependent and,
therefore, outside the scope of this document. therefore, outside the scope of this document.
In MHAuth-Done, the HAC sends a random number 'hac-rand' and the In MHAuth-Done, the HAC sends a random number 'hac-rand' and the
selected ciphersuite. The selection MUST be one of the MN-supported selected ciphersuite. The selection MUST be one of the MN-supported
ciphersuites as received in 'ciphersuite-list'. Furthermore, it ciphersuites as received in 'ciphersuite-list'. Furthermore, it
repeats the received parameters of the MHAuth-Init message 'mn-rand'. repeats the received parameters of the MHAuth-Init message 'mn-rand'.
It computes a message authenticator 'auth' over all the transmitted It computes a message authenticator 'auth' over all the transmitted
parameters except 'auth' itself. The HAC calculates 'auth' over all parameters except 'auth' itself. The HAC calculates 'auth' over all
parameters and appends it to the message. parameters and appends it to the message.
The MN verifies the received MAC and the consistency of the The MN verifies the received Message Authentication Code (MAC) and
identities, nonces, and ciphersuite parameters transmitted in MHAuth- the consistency of the identities, nonces, and ciphersuite parameters
Auth. In case of successful verification, the MN computes a MAC over transmitted in MHAuth-Auth. In case of successful verification, the
the session parameter and returns it to the HAC in MHAuth-Done. The MN computes a MAC over the session parameter and returns it to the
HAC verifies the received MAC and the consistency of the identities, HAC in MHAuth-Done. The HAC verifies the received MAC and the
nonces, and ciphersuite parameters transmitted in MHAuth-Init. If consistency of the identities, nonces, and ciphersuite parameters
the verification is successful, MHAuth-Done is prepared and sent by transmitted in MHAuth-Init. If the verification is successful,
the HAC to confirm successful completion of the exchange. MHAuth-Done is prepared and sent by the HAC to confirm successful
completion of the exchange.
5.9. Extensible Authentication Protocol Methods 5.9. Extensible Authentication Protocol Methods
Basic operation required for the MN-HAC mutual authentication using Basic operation required for the MN-HAC mutual authentication using
EAP-based methods. EAP-based methods.
MN HAC MN HAC
| | | |
| Request/MHAuth-Init (...) | | Request/MHAuth-Init (...) |
|------------------------------------------------------>| |------------------------------------------------------>|
skipping to change at page 22, line 37 skipping to change at page 22, line 42
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| Response/MHAuth-Done (eap-payload=EAP-Success, | | Response/MHAuth-Done (eap-payload=EAP-Success, |
| ..., auth) | | ..., auth) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
Figure 5: Authentication of the Mobile Node Using EAP Figure 5: Authentication of the Mobile Node Using EAP
1) Request/MHAuth-Init: (MN -> HAC) 1) Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=eap mn-id, mn-rand, auth-method=eap
2) Response/MHAuth-Init: (MN <- HAC) 2) Response/MHAuth-Init: (MN <- HAC)
[auth-method=eap, eap, [status,]] auth [auth-method=eap, eap, [status,]] auth
3) Request/MHAuth-Mid: (MN -> HAC) 3) Request/MHAuth-Mid: (MN -> HAC)
eap, auth eap, auth
4) Response/MHAuth-Mid: (MN <- HAC) 4) Response/MHAuth-Mid: (MN <- HAC)
eap, auth eap, auth
MHAuth-Mid exchange is repeated as many times as needed by the MHAuth-Mid exchange is repeated as many times as needed by the
used EAP-method. used EAP-method.
5) Request/MHAuth-Done: (MN -> HAC) 5) Request/MHAuth-Done: (MN -> HAC)
sa-scope, ciphersuite-list, eap, auth sa-scope, ciphersuite-list, eap, auth
6) Response/MHAuth-Done: (MN <- HAC) 6) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap,
status, auth status, auth
Where: Where 'auth' for MN -> HAC direction is as follows:
auth = HMAC-SHA256(shared-key, msg-octets | CB-octets) auth = HMAC-SHA256(shared-key, "MN" | msg-octets | CB-octets)
Where 'auth' for MN <- HAC direction is as follows:
auth = HMAC-SHA256(shared-key, "HAC" | msg-octets | CB-octets)
In the above, "MN" is 2 ASCII characters without null termination and
"HAC" is 3 ASCII characters without null termination.
In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If 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 the EAP-method is key-deriving and creates a shared Master Session
effect of Authentication shared-key MUST be the MSK in all MHAuth- Key (MSK) as a side effect of Authentication shared-key MUST be the
Done messages. This MSK MUST NOT be used for any other purpose. In MSK in all MHAuth-Done messages. This MSK MUST NOT be used for any
case the EAP method does not generate an MSK key, shared-key is set other purpose. In case the EAP method does not generate an MSK,
to "1". shared-key is set to "1".
'msg-octets' includes all payload parameters of the respective 'msg-octets' includes all payload parameters of the respective
message to be signed except the 'auth' payload. CB-octets is the message to be signed except the 'auth' payload. CB-octets is the
channel binding input to the AUTH calculation that is the "TLS- channel binding input to the AUTH calculation that is the "TLS-
server-endpoint" channel binding type. The content and algorithm server-endpoint" channel binding type. The content and algorithm
(only required for the "TLS-server-endpoint" type) are the same as (only required for the "TLS-server-endpoint" type) are the same as
described in [RFC5929]. described in [RFC5929].
6. Mobile Node to Home Agent communication 6. Mobile Node to Home Agent Communication
6.1. General 6.1. General
The following sections describe the packet formats used for the The following subsections describe the packet formats used for the
traffic between the MN and the HA. This traffic includes binding traffic between the MN and the HA. This traffic includes binding
management messages (for example, BU and BA messages), reverse management messages (for example, BU and BA messages), reverse-
tunneled and encrypted user data, and reverse tunneled plain text tunneled and encrypted user data, and reverse-tunneled plaintext user
user data. This specification defines a generic packet format, where data. This specification defines a generic packet format, where
everything is encapsulated inside UDP. See Section 6.3 and everything is encapsulated inside UDP. See Sections 6.3 and 6.4 for
Section 6.4 for detailed illustrations of the corresponding packet detailed illustrations of the corresponding packet formats.
formats.
The Mobile IPv6 service port number is where the HA expects to The Mobile IPv6 service port number is where the HA expects to
receive UDP packets. The same port number is used for both binding receive UDP packets. The same port number is used for both binding
management messages and user data packets. The reason for management messages and user data packets. The reason for
multiplexing data and control messages over the same port number is multiplexing data and control messages over the same port number is
due to the possibility of Network Address and Port Translators due to the possibility of Network Address and Port Translators
located along the path between the MN and the HA. The Mobile IPv6 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 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 it MUST use the Mobile IPv6 service port number as the UDP
port. The Mobile IPv6 service port is either dynamically assigned to destination port. The Mobile IPv6 service port is dynamically
the MN during the bootstrapping phase (i.e. the mip6-port parameter) assigned to the MN during the bootstrapping phase (i.e., the mip6-
or in absence of the bootstrapping parameter the IANA reserved port port parameter) or, in absence of the bootstrapping parameter, the
(HALTSEC) MUST be used. IANA reserved port (mipv6tls) MUST be used.
The encapsulating UDP header is immediately followed by a 4-bit The encapsulating UDP header is immediately followed by a 4-bit
Packet Type (PType) field that defines whether the packet contains an Packet Type (PType) field that defines whether the packet contains an
encrypted mobility management message or a, an encrypted user data encrypted mobility management message, an encrypted user data packet,
packet, or a plain text user data packet. or a plaintext user data packet.
The Packet Type field is followed by a 28-bit SPI value, which The Packet Type field is followed by a 28-bit SPI value, which
identifies the correct SA concerning the encrypted packet. For any identifies the correct SA concerning the encrypted packet. For any
packet that is neither integrity protected nor encrypted (i.e. no SA 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). is applied by the originator), the SPI MUST be set to 0 (zero).
Mobility management messages MUST always be at least integrity Mobility management messages MUST always be at least integrity
protected. Hence, mobility management messages MUST NOT be sent with protected. Hence, mobility management messages MUST NOT be sent with
a SPI value of 0 (zero). an SPI value of 0 (zero).
There is always only one SPI per MN-HA mobility session and the same 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 SPI is used for all types of protected packets independent of the
direction. direction.
The SPI value is followed by a 32-bit Sequence Number value that is The SPI value is followed by a 32-bit Sequence Number value that is
used to identify retransmissions of protected messages (integrity used to identify retransmissions of protected messages (integrity
protected or both integrity protected and encrypted, see Figures 7 protected or both integrity protected and encrypted, see Figures 7
and 8) . Each endpoint in the security association maintains two and 8) . Each endpoint in the security association maintains two
"current" Sequence Numbers: the next one to be used for a packet it "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 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 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 of messages, the Sequence Numbers in the two directions can be very
different. In a case data protection is not used (see Figure 9), the different. In the case data protection is not used (see Figure 9),
Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD 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 initiate a re-establishment of the SA before any of the Sequence
Number cycle. Number cycle.
Finally, the Sequence Number field is followed by the data portion, Finally, the Sequence Number field is followed by the data portion,
whose content is identified by the Packet Type. The data portion may whose content is identified by the Packet Type. The data portion may
be protected. be protected.
6.2. PType and Security Parameter Index 6.2. PType and Security Parameter Index
The PType is a 4-bit field that indicates the Packet Type (PType) of 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 the UDP encapsulated packet. The PType is followed by a 28-bit SPI
value. The PType and the SPI fields are treated as one 32-bit field value. The PType and the SPI fields are treated as one 32-bit field
during the integrity protection calculation. during the integrity protection calculation.
0 1 2 3 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 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 | | PType | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Security Parameter Index with Packet Type Figure 6: Security Parameter Index with Packet Type
skipping to change at page 25, line 25 skipping to change at page 25, line 36
SPI value MUST be different from 0. When the SPI value is set to 0, SPI value MUST be different from 0. When the SPI value is set to 0,
then the PType MUST also be 0. then the PType MUST also be 0.
6.3. Binding Management Message Formats 6.3. Binding Management Message Formats
The binding management messages that are only meant to be exchanged The binding management messages that are only meant to be exchanged
between the MN and the HA MUST be integrity protected and MAY be between the MN and the HA MUST be integrity protected and MAY be
encrypted. They MUST use the packet format shown in Figure 7. encrypted. They MUST use the packet format shown in Figure 7.
All packets that are specific to the Mobile IPv6 protocol, contain a 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 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 used between the MN and the HA shall use the packet format shown in
Figure 7. (This means that some Mobile IPv6 mobility management Figure 7. (This means that some Mobile IPv6 mobility management
messages, such as the HoTI message, are treated as data packets and messages, such as the Home Test Init (HoTI) message, are treated as
using encapsulation described in Section 6.4 and shown in Figures 8 data packets and using encapsulation described in Section 6.4 and
and 9). shown in Figures 8 and 9).
0 1 2 3 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 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) : : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: UDP header (src-port=Xp,dst-port=Yp) : : UDP header (src-port=Xp,dst-port=Yp) :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|PType=8| SPI | ^Int. |PType=8| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered | Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^ | Payload Data (variable) | | ^
: : | | : : | |
| | |Conf. | | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered* | | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v | | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) | | Integrity Check Value-ICV (variable) |
: : : :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UDP Encapsulated Binding Management Message Format Figure 7: UDP-Encapsulated Binding Management Message Format
The PType value 8 (eight) identifies that the UDP encapsulated packet The PType value 8 (eight) identifies that the UDP-encapsulated packet
contains a RFC 6275 defined Mobility Header and other relevant IPv6 contains a Mobility Header (defined by RFC 6275) and other relevant
extension headers. Note, there is no additional IP header inside the IPv6 extension headers. Note, there is no additional IP header
encapsulated part. The Next Header field MUST be set to value of the inside the encapsulated part. The Next Header field MUST be set to
first encapsulated header. The encapsulated headers follow the value of the first encapsulated header. The encapsulated headers
natural IPv6 and Mobile IPv6 extension header alignment and follow the natural IPv6 and Mobile IPv6 extension header alignment
formatting rules. and formatting rules.
The Padding, Pad Length, Next Header and ICV fields follow the rules The Padding, Pad Length, Next Header, and ICV fields follow the rules
of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this
document. For a SPI value of 0 (zero) that indicates an unprotected document. For an SPI value of 0 (zero) that indicates an unprotected
packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT
be present. be present.
The source and destination IP addresses of the outer IP header (i.e. The source and destination IP addresses of the outer IP header (i.e.,
the src-addr and the dst-addr in Figure 7) use the current care-of the src-addr and the dst-addr in Figure 7) use the current CoA of the
address of the MN and the HA address. MN and the HA address.
6.4. Reverse Tunneled User Data Packet Formats 6.4. Reverse-Tunneled User Data Packet Formats
There are two types of reverse tunneled user data packets between the There are two types of reverse-tunneled user data packets between the
MN and the HA. Those that are integrity protected and encrypted and MN and the HA: those that are integrity protected and/or encrypted
those that are plaintext. The MN or the HA decide whether to apply and those that are sent in the clear. The MN or the HA decides
integrity protection and encryption to a packet or to send it in whether to apply integrity protection and/or encryption to a packet
plaintext based on the mip6-sas value in the SA. If the mip6-sas is or to send it in the clear based on the mip6-sas value in the SA. If
set to 1 the originator MUST NOT send any plaintext packet, and the the mip6-sas is set to 1, the originator MUST NOT send any user data
receiver MUST silently discard any packet with the PType set to 0 packets in the clear, and the receiver MUST silently discard any
(unprotected). It is RECOMMENDED to apply confidentiality and packet with the PType set to 0 (unprotected). It is RECOMMENDED that
integrity protection of user data traffic. The reverse tunneled IPv4 confidentiality and integrity protection of user data traffic be
or IPv6 user data packets are encapsulated as-is inside the 'Payload applied. The reverse-tunneled IPv4 or IPv6 user data packets are
Data' shown in Figures 8 and 9. encapsulated as is inside the 'Payload Data' shown in Figures 8 and
9.
0 1 2 3 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 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) : : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: UDP header (src-port=Xp,dst-port=Yp) : : UDP header (src-port=Xp,dst-port=Yp) :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=1| SPI | ^Int. |PType=1| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered | Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^ | Payload Data (variable) | | ^
: : | | : : | |
| | |Conf. | | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered* | | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v | | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) | | Integrity Check Value-ICV (variable) |
: : : :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: UDP Encapsulated Protected User Data Packet Format Figure 8: UDP-Encapsulated Protected User Data Packet Format
The PType value 1 (one) identifies that the UDP encapsulated packet The PType value 1 (one) identifies that the UDP-encapsulated packet
contains an encrypted tunneled IPv4/IPv6 user data packet. The Next contains an encrypted-tunneled IPv4/IPv6 user data packet. The Next
Header field header MUST be set to value corresponding the tunneled Header field header MUST be set to value corresponding the tunneled
IP packet (e.g., 41 for IPv6). IP packet (e.g., 41 for IPv6).
The Padding, Pad Length, Next Header and ICV fields follow the rules The Padding, Pad Length, Next Header, and ICV fields follow the rules
of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this
document. For a SPI value of 0 (zero) that indicates an unprotected document. For an SPI value of 0 (zero) that indicates an unprotected
packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT
be present. be present.
The source and destination IP addresses of the outer IP header (i.e., The source and destination IP addresses of the outer IP header (i.e.,
the src-addr and the dst-addr in Figure 8) use the current care-of the src-addr and the dst-addr in Figure 8) use the current CoA of the
address of the MN and the HA address. The ESP protected inner IP MN and the HA address. The ESP-protected inner IP header, which is
header, which is not shown in Figure 8, uses the home address of the not shown in Figure 8, uses the home address of the MN and the
MN and the correspondent node (CN) address. correspondent node (CN) address.
0 1 2 3 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 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) : : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: UDP header (src-port=Xp,dst-port=Yp) : : UDP header (src-port=Xp,dst-port=Yp) :
skipping to change at page 28, line 37 skipping to change at page 28, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0| 0 | |PType=0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Payload Data (plain IPv4 or IPv6 Packet) : : Payload Data (plain IPv4 or IPv6 Packet) :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: UDP Encapsulated Non-Protected User Data Packet Format Figure 9: UDP-Encapsulated Non-Protected User Data Packet Format
The PType value 0 (zero) identifies that the UDP encapsulated packet The PType value 0 (zero) identifies that the UDP-encapsulated packet
contains a plaintext tunneled IPv4/IPv6 user data packet. Also the contains a plaintext-tunneled IPv4/IPv6 user data packet. Also, the
SPI and the Sequence Number fields MUST be set to 0 (zero). SPI and the Sequence Number fields MUST be set to 0 (zero).
The source and destination IP addresses of the outer IP header (i.e., The source and destination IP addresses of the outer IP header (i.e.,
the src-addr and the dst-addr in Figure 9) use the current care-of the src-addr and the dst-addr in Figure 9) use the current CoA of the
address of the MN and the HA address. The plain text inner IP header MN and the HA address. The plaintext inner IP header uses the home
uses the home address of the MN and the CN address. address of the MN and the CN address.
7. Route Optimization 7. Route Optimization
Mobile IPv6 route optimization as described in [RFC6275] is not Mobile IPv6 route optimization as described in [RFC6275] is not
affected by this specification. Route optimization is possible only affected by this specification. Route optimization is possible only
between an IPv6 MN and CN. UDP encapsulation of signaling and data between an IPv6 MN and CN. UDP encapsulation of signaling and data
traffic is only between the MN and HA. The return routability traffic is only between the MN and HA. The return routability
signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are
treated as data packets and encapsulation, when needed, is as per the treated as data packets and encapsulation, when needed, is per the
description in Section 6.4 of this specification. The data packets description in Section 6.4 of this specification. The data packets
between an MN and CN which have successfully completed the return between an MN and CN that have successfully completed the return
routability test and created the appropriate entries in their binding routability test and created the appropriate entries in their binding
cache are not UDP encapsulated using the packet formats defined in cache are not UDP encapsulated using the packet formats defined in
this specification but follow the [RFC6275] specification. this specification but follow the [RFC6275] specification.
8. IANA Considerations 8. IANA Considerations
8.1. New Registry: Packet Type 8.1. New Registry: Packet Type
IANA is requested to create a new registry under the [RFC6275] Mobile IANA has created a new registry under the [RFC6275] Mobile IPv6
IPv6 parameters registry for the Packet Type as described in parameters registry for the Packet Type as described in Section 6.1.
Section 6.1.
Packet Type | Value Description | Value
----------------------------------+---------------------------------- ----------------------------------+----------------------------------
non-encrypted IP packet | 0 non-encrypted IP packet | 0
encrypted IP packet | 1 encrypted IP packet | 1
mobility header | 8 mobility header | 8
Following the allocation policies from [RFC5226] new values for the Following the allocation policies from [RFC5226], new values for the
Packet Type AVP MUST be assigned based on the "RFC Required" policy. Packet Type AVP MUST be assigned based on the "RFC Required" policy.
8.2. Status Codes 8.2. Status Codes
A new Status Code (to be used in BA messages) is reserved for the 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- cases where the HA wants to indicate to the MN that it needs to
establish the SA information with the HAC. The Result Code is re-establish the SA information with the HAC. The following value is
reserved from the 0-127 code space in [RFC6275] Status Codes reserved in the [RFC6275] Status Codes registry:
registry:
REINIT_SA_WITH_HAC TBD1 REINIT_SA_WITH_HAC 176
8.3. Port Numbers 8.3. Port Numbers
A new port number (HALTSEC) for UDP packets is reserved from the A new port number (mipv6tls) for UDP packets is reserved from the
existing PORT NUMBERS registry. existing PORT NUMBERS registry.
HALTSEC TBD2 mipv6tls 7872
9. Security Considerations 9. Security Considerations
This document describes and uses a number of building blocks that This document describes and uses a number of building blocks that
introduce security mechanisms and need to inter-work in a secure introduce security mechanisms and need to interwork in a secure
manner. manner.
The following building blocks are considered from a security point of The following building blocks are considered from a security point of
view: view:
1. Discovery of the HAC 1. Discovery of the HAC
2. Authentication and MN-HA SA establishment executed between the MN 2. Authentication and MN-HA SA establishment executed between the MN
and the HAC (PSK or EAP-based) through a TLS tunnel and the HAC (PSK- or EAP-based) through a TLS tunnel
3. Protection of MN-HA communication 3. Protection of MN-HA communication
4. AAA Interworking
4. AAA interworking
9.1. Discovery of the HAC 9.1. Discovery of the HAC
No dynamic procedure for discovering the HAC by the MN is described No dynamic procedure for discovering the HAC by the MN is described
in this document. As such, no specific security considerations apply in this document. As such, no specific security considerations apply
to the scope of this document. to the scope of this document.
9.2. Authentication and Key Exchange executed between the MN and the 9.2. Authentication and Key Exchange Executed between the MN and the
HAC HAC
This document describes a simple authentication and MN-HA SA This document describes a simple authentication and MN-HA SA
negotiation exchange over TLS. The TLS procedures remain unchanged; negotiation exchange over TLS. The TLS procedures remain unchanged;
however, channel binding is provided. however, channel binding is provided.
Authentication: Server-side certificate based authentication MUST be Authentication: Server-side certificate-based authentication MUST be
performed using TLS 1.2 [RFC5246]. performed using TLS version 1.2 [RFC5246]. The MN MUST verify the
HAC's TLS server certificate, using either the subjectAltName
extension [RFC5280] dNSName identities as described in [RFC6125]
or subjectAltName iPAddress identities. In case of iPAddress
identities, the MN MUST check the IP address of the TLS connection
against these iPAddress identities and SHOULD reject the
connection if none of the iPAddress identities match the
connection. In case of dNSName identities, the rules and
guidelines defined in [RFC6125] apply here, with the following
considerations:
* Support for DNS-ID identifier type (the dNSName identity in the
subjectAltName extension) is REQUIRED in the HAC and the MN TLS
implementations.
* DNS names in the HAC server certificates MUST NOT contain the
wildcard character "*".
* The CN-ID MUST NOT be used for authentication within the rules
described in [RFC6125].
* The MN MUST set its "reference identifier" to the DNS name of
the HAC.
The client-side authentication may depend on the specific The client-side authentication may depend on the specific
deployment and is therefore not mandated. Note that TLS-PSK deployment and is therefore not mandated. Note that TLS-PSK
[RFC4279] cannot be used in conjunction with the methods described [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 in Sections 5.8 and 5.9 of this document due to the limitations of
the channel binding type used. the channel binding type used.
Through the protected TLS tunnel, an additional authentication Through the protected TLS tunnel, an additional authentication
exchange is performed that provides client-side or mutual exchange is performed that provides client-side or mutual
authentication and exchanges SA parameters and optional authentication and exchanges SA parameters and optional
configuration data to be used in the subsequent protection of configuration data to be used in the subsequent protection of
MN-HA communication. The additional authentication exchange can MN-HA communication. The additional authentication exchange can
either be PSK-based (section 5.8) or EAP-based (section 5.9). be either PSK-based (Section 5.8) or EAP-based (Section 5.9).
Both exchanges are always performed within the protected TLS Both exchanges are always performed within the protected TLS
tunnel and MUST NOT be used as standalone protocols. tunnel and MUST NOT be used as standalone protocols.
The simple PSK-based authentication exchange provides mutual The simple PSK-based authentication exchange provides mutual
authentication and follows the GPSK exchange used by EAP-GPSK authentication and follows the GPSK exchange used by EAP-GPSK
[RFC5433] and has similar properties, although some features of [RFC5433] and has similar properties, although some features of
GPSK like the exchange of a protected container are not supported. GPSK like the exchange of a protected container are not supported.
The EAP-based authentication exchange simply defines message The EAP-based authentication exchange simply defines message
containers to allow carrying the EAP packets between the MN and containers to allow carrying the EAP packets between the MN and
the HAC. In principle, any EAP method can be used. However, it the HAC. In principle, any EAP method can be used. However, it
is strongly recommended to use only EAP methods that provide is strongly recommended to use only EAP methods that provide
mutual authentication and that derive keys including an MSK key in mutual authentication and that derive keys including an MSK in
compliance with [RFC3748]. compliance with [RFC3748].
Both exchanges use channel binding with the TLS tunnel. The Both exchanges use channel binding with the TLS tunnel. The
channel binding type 'TLS-server-endpoint' as per [RFC5929] MUST channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be
be used. used.
Dictionary Attacks: All messages of the authentication exchanges Dictionary Attacks: All messages of the authentication exchanges
specified in this document are protected by TLS. However, any specified in this document are protected by TLS. However, any
implementation SHOULD assume that the properties of the implementation SHOULD assume that the properties of the
authentication exchange are the same as for GPSK [RFC5433] in case authentication exchange are the same as for GPSK [RFC5433], in
the PSK-based method as per section 5.8. is used, and are the same case the PSK-based method per Section 5.8 is used, and are the
as those of the underlying EAP method in case the EAP-based same as those of the underlying EAP method, in case the EAP-based
exchange as per section 5.9 is used. exchange per Section 5.9 is used.
Replay Protection: The underlying TLS protection provides protection Replay Protection: The underlying TLS protection provides protection
against replays. against replays.
Key Derivation and Key Strength: For TLS, the TLS specific Key Derivation and Key Strength: For TLS, the TLS-specific
considerations apply unchanged. For the authentication exchanges considerations apply unchanged. For the authentication exchanges
defined in this document, no key derivation step is performed as 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 the MN-HA keys are generated by the HAC and are distributed to the
MN through the secure TLS connection. MN through the secure TLS connection.
Key Control: No joint key control for MN-HA keys is provided by this Key Control: No joint key control for MN-HA keys is provided by this
version of the specification. version of the specification.
Lifetime: The TLS-protected authentication exchange between the MN Lifetime: The TLS-protected authentication exchange between the MN
and the HAC is only to bootstrap keys and other parameters for 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 usage with MN-HA security. The SAs that contain the keys have an
associated lifetime. The usage of Transport Layer Security (TLS) associated lifetime. The usage of Transport Layer Security (TLS)
Session Resumption without Server-Side State, described in Session Resumption without Server-Side State, described in
[RFC5077], provides the ability for the MN to minimize the latency [RFC5077], provides the ability for the MN to minimize the latency
of future exchanges towards the HA without having to keep state at of future exchanges towards the HA without having to keep state at
the HA itself. the HA itself.
Denial of Service Resistance: The level of resistance against denial Denial-of-Service (DoS) Resistance: The level of resistance against
of service attacks SHOULD be considered the same as for common TLS DoS attacks SHOULD be considered the same as for common TLS
operation, as TLS is used unchanged. For the PSK-based operation, as TLS is used unchanged. For the PSK-based
authentication exchange, no additional factors are known. For the authentication exchange, no additional factors are known. For the
EAP-based authentication exchange, any considerations regarding EAP-based authentication exchange, any considerations regarding
denial-of-service resistance specific to the chosen EAP method are DoS resistance specific to the chosen EAP method are expected to
expected to be applicable and need to be be taken into account. be applicable and need to be taken into account.
Session Independence: Each individual TLS protocol run is Session Independence: Each individual TLS protocol run is
independent from any previous exchange based on the security independent from any previous exchange based on the security
properties of the TLS handshake protocol. However, several PSK or properties of the TLS handshake protocol. However, several PSK-
EAP-based authentication exchanges can be performed across the or EAP-based authentication exchanges can be performed across the
same TLS connection. same TLS connection.
Fragmentation: TLS runs on top of TCP and no fragmentation specific Fragmentation: TLS runs on top of TCP and no fragmentation-specific
considerations apply to the MN-HAC authentication exchanges. considerations apply to the MN-HAC authentication exchanges.
Channel Binding: Both the PSK and the EAP-based exchanges use Channel Binding: Both the PSK and the EAP-based exchanges use
channel binding with the TLS tunnel. The channel binding type channel binding with the TLS tunnel. The channel binding type
'TLS-server-endpoint' as per [RFC5929] MUST be used. 'TLS-server-endpoint' per [RFC5929] MUST be used.
Fast Reconnect: This protocol provides session resumption as part of Fast Reconnect: This protocol provides session resumption as part of
TLS and optionally the support for [RFC5077]. No fast reconnect TLS and optionally the support for [RFC5077]. No fast reconnect
is supported for the PSK-based authentication exchange. For the is supported for the PSK-based authentication exchange. For the
EAP-based authentication exchange, availability of fast reconnect EAP-based authentication exchange, availability of fast reconnect
depends on the EAP method used. depends on the EAP method used.
Identity Protection: Based on the security properties of the TLS Identity Protection: Based on the security properties of the TLS
tunnel, passive user identity protection is provided. An attacker tunnel, passive user identity protection is provided. An attacker
acting as man-in-the-middle in the TLS connection would be able to acting as man-in-the-middle in the TLS connection would be able to
skipping to change at page 33, line 26 skipping to change at page 33, line 50
length depends on the chosen cryptographic algorithms. length depends on the chosen cryptographic algorithms.
Replay Protection: Replay protection for the communication between Replay Protection: Replay protection for the communication between
the MN and the HA is provided based on sequence numbers and the MN and the HA is provided based on sequence numbers and
follows the design of IPsec ESP. follows the design of IPsec ESP.
Key Derivation and Key Strength: The strength of the keying material Key Derivation and Key Strength: The strength of the keying material
established for the communication between the MN and the HA is established for the communication between the MN and the HA is
selected based on the negotiated ciphersuite (based on the MN-HAC selected based on the negotiated ciphersuite (based on the MN-HAC
exchange) and the key created by the HAC. The randomness exchange) and the key created by the HAC. The randomness
requirements for security described in RFC 4086 [RFC4086] are requirements for security described in [RFC4086] are applicable to
applicable to the key generation by the HAC. the key generation by the HAC.
Key Control: The keying material established during the MN-HAC Key Control: The keying material established during the MN-HAC
protocol exchange for subsequent protection of the MN-HA protocol exchange for subsequent protection of the MN-HA
communication is created by the HA and therefore no joint key communication is created by the HA and therefore no joint key
control is provided for it. control is provided for it.
Key Naming: For the MN-HA communication the security associations Key Naming: For the MN-HA communication, the security associations
are indexed with the help of the SPI and additionally based on the are indexed with the help of the SPI and additionally based on the
direction (in-bound communication or out-bound communication). direction (inbound communication or outbound communication).
Lifetime: The lifetime of the MN-HA security associations is based Lifetime: The lifetime of the MN-HA security associations is based
on the value in the mip6-sa-validity-end header field exchanged on the value in the mip6-sa-validity-end header field exchanged
during the MN-HAC exchange. The HAC controls the SA lifetime. during the MN-HAC exchange. The HAC controls the SA lifetime.
Denial of Service Resistance: For the communication between the MN DoS Resistance: For the communication between the MN and the HA,
and the HA there are no heavy cryptographic operations (such as there are no heavy cryptographic operations (such as public key
public key computations). As such, there are no DoS concerns. computations). As such, there are no DoS concerns.
Session Independence: Sessions are independent from each other when Session Independence: Sessions are independent from each other when
new keys are created by via the MN-HAC protocol. A new MN-HAC new keys are created via the MN-HAC protocol. A new MN-HAC
protocol run produces fresh and unique keying material for protocol run produces fresh and unique keying material for
protection of the MN-HA communication. protection of the MN-HA communication.
Fragmentation: There is no additional fragmentation support provided Fragmentation: There is no additional fragmentation support provided
beyond what is offered by the network layer. beyond what is offered by the network layer.
Channel Binding: Channel binding is not applicable to the MN-HA Channel Binding: Channel binding is not applicable to the MN-HA
communication. communication.
Fast Reconnect: The concept of fast reconnect is not applicable to Fast Reconnect: The concept of fast reconnect is not applicable to
the MN-HA communication. the MN-HA communication.
Identity Protection: User identities SHOULD NOT be exchanged between Identity Protection: User identities SHOULD NOT be exchanged between
the MN and the HA. In a case binding management messages contain the MN and the HA. In the case where binding management messages
the user identity, the messages SHOULD be confidentiality contain the user identity, the messages SHOULD be confidentiality
protected. protected.
Protected Ciphersuite Negotiation: The MN-HAC protocol provides Protected Ciphersuite Negotiation: The MN-HAC protocol provides
protected ciphersuite negotiation through a secure TLS connection. protected ciphersuite negotiation through a secure TLS connection.
Confidentiality: Confidentiality protection of payloads exchanged Confidentiality: Confidentiality protection of payloads exchanged
between the MN and the HAC (for Mobile IPv6 signaling and between the MN and the HAC (for Mobile IPv6 signaling and
optionally for the data traffic) is provided utilizing algorithms optionally for the data traffic) is provided utilizing algorithms
negotiated during the MN-HAC exchange. negotiated during the MN-HAC exchange.
Cryptographic Binding: No cryptographic bindings are provided by Cryptographic Binding: No cryptographic bindings are provided by
this protocol specified in this document. this protocol specified in this document.
Perfect Forward Secrecy: Perfect forward secrecy is provided when Perfect Forward Secrecy: Perfect forward secrecy is provided when
the MN bootstraps new keying material with the help of the MN-HAC the MN bootstraps new keying material with the help of the MN-HAC
protocol (assuming that a proper TLS ciphersuite is used). protocol (assuming that a proper TLS ciphersuite is used).
Key confirmation: Key confirmation of the MN-HA keying material Key Confirmation: Key confirmation of the MN-HA keying material
conveyed from the HAC to the MN is provided when the first packets 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 are exchanged between the MN and the HA (in both directions as two
different keys are used). different keys are used).
9.4. AAA Interworking 9.4. AAA Interworking
The AAA backend infrastructure interworking is not defined in this The AAA backend infrastructure interworking is not defined in this
document and therefore out-of-scope. document and is therefore out of scope.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Pasi Eronen, Domagoj Premec, Julien The authors would like to thank Pasi Eronen, Domagoj Premec, Julien
Laganier, Jari Arkko and Christian Bauer for their comments. Laganier, Jari Arkko, Stephen Farrell, Peter Saint-Andre and
Christian Bauer for their comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
skipping to change at page 35, line 42 skipping to change at page 36, line 18
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, July 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
11.2. Informative References 11.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
skipping to change at page 37, line 5 skipping to change at page 37, line 30
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010. RFC 5944, November 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo FIN-02600 Espoo FIN-02600
Finland Finland
Email: jouni.nospam@gmail.com EMail: jouni.nospam@gmail.com
Basavaraj Patil Basavaraj Patil
Nokia Nokia
6021 Connection Drive 6021 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: basavaraj.patil@nokia.com EMail: basavaraj.patil@nokia.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
Dirk Kroeselberg Dirk Kroeselberg
Siemens Siemens
Otto-Hahn-Ring 6
Munich 81739
Germany
Email: dirk.kroeselberg@siemens.com EMail: dirk.kroeselberg@siemens.com
 End of changes. 192 change blocks. 
431 lines changed or deleted 509 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/