draft-ietf-mext-mip6-tls-02.txt   draft-ietf-mext-mip6-tls-03.txt 
Mobility Extensions (MEXT) J. Korhonen, Ed. Mobility Extensions (MEXT) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Experimental B. Patil Intended status: Experimental B. Patil
Expires: April 13, 2012 Nokia Expires: August 18, 2012 Nokia
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
D. Kroeselberg D. Kroeselberg
Siemens Siemens
October 11, 2011 February 15, 2012
Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Transport Layer Security-based Mobile IPv6 Security Framework for Mobile
Node to Home Agent Communication Node to Home Agent Communication
draft-ietf-mext-mip6-tls-02.txt 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 and its home agent is
secured using IPsec. The security association between a mobile node secured using IPsec. The security association between a mobile node
and the home agent is established using IKEv1 or IKEv2. The security and the home agent is established using IKEv1 or IKEv2. The security
model specified for Mobile IPv6, which relies on IKE/IPsec, requires model specified for Mobile IPv6, which relies on IKE/IPsec, requires
interaction between the Mobile IPv6 protocol component and the IKE/ interaction between the Mobile IPv6 protocol component and the IKE/
IPsec module of the IP stack. This document proposes an alternate IPsec module of the IP stack. This document proposes an alternate
security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2012. This Internet-Draft will expire on August 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TLS-based Security Establishment . . . . . . . . . . . . . . . 6 4. TLS-based Security Establishment . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Security Association Management . . . . . . . . . . . . . 8 4.3. Security Association Management . . . . . . . . . . . . . 8
4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 10 4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 10
4.5. Protecting Traffic Between Mobile Node and Home Agent . . 11 4.5. Protecting Traffic Between Mobile Node and Home Agent . . 11
5. Mobile Node to Home Agent Controller Communication . . . . . . 11 5. Mobile Node to Home Agent Controller Communication . . . . . . 11
5.1. Request-response Message Framing over TLS-tunnel . . . . . 11 5.1. Request-response Message Framing over TLS-tunnel . . . . . 11
5.2. Request-response Message Content Encoding . . . . . . . . 12 5.2. Request-response Message Content Encoding . . . . . . . . 12
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 . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . 15 5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 14
5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 15 5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 15
5.5.7. End of Message Content . . . . . . . . . . . . . . . . 15 5.5.7. End of Message Content . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . 16
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 . . . . . . . . 19 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 . . . . . . . . 21
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 . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Replicating RFC6275 Route Optimization . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7.2. Enhanced Route Optimization with Home Agent-less 8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29
Operation . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 30
8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 31 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30
9.2. Authentication and Key Exchange executed between the 9.2. Authentication and Key Exchange executed between the
MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . 35 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 34
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Mobile IPv6 signaling as specified in RFC6275 [RFC6275], and Mobile IPv6 [RFC6275] signaling, and optionally user traffic, between
optionally user traffic, between a mobile node (MN) and home agent a mobile node (MN) and home agent (HA) are secured by IPsec
(HA) are secured by IPsec [RFC4301]. The current Mobile IPv6 [RFC4301]. The current Mobile IPv6 security architecture is
security architecture is specified in [RFC3776] and [RFC4877]. This specified in [RFC3776] and [RFC4877]. This security model requires a
security model requires a tight coupling between the Mobile IPv6 tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/
protocol part and the IKE(v2)/IPsec part of the IP stack. IPsec part of the IP stack. Client implementation experience has
Implementation experience has shown that the use of IKE(v2)/IPsec shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly
with Mobile IPv6 is fairly complex. The issues with the IKE(v2)/ complex.
IPsec based security architecture are documented in
[I-D.patil-mext-mip6issueswithipsec].
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. Instead of using IKEv2, the security framework and extensively used by various applications. Instead of using IKEv2
proposed in this document is based on TLS protected messages to to establish security associations, the security framework proposed
exchange keys and bootstrapping parameters between the Mobile Node in this document is based on TLS protected messages to exchange keys
and a new functional entity called as the Home Agent Controller and bootstrapping parameters between the Mobile Node and a new
(HAC). The Mobile IPv6 signaling between the mobile node and home functional entity called as the Home Agent Controller (HAC). The
agent is subsequently secured using the resulting keys and negotiated Mobile IPv6 signaling between the mobile node and home agent is
cipher suite. The HAC can be co-located with the HA, or can be an subsequently secured using the resulting keys and negotiated cipher
suite. The HAC can be co-located with the HA, or can be an
independent entity. For the latter case, communication between HAC independent entity. For the latter case, communication between HAC
and HA is not defined by this document. The Diameter protocol can be and HA is not defined by this document. Such communication could be
used between the HA and HAC when the two entities are not collocated. built on top of AAA protocols such as Diameter, for instance.
The primary advantage of using TLS based establishment of Mobile IP6 The primary advantage of using TLS based establishment of Mobile IP6
security associations compared to IKEv2 is the ease of implementation security associations compared to IKEv2 is the ease of implementation
while providing equivalent level of security. For the protection of while providing an equivalent level of security. For the protection
Mobile IPv6 signaling messages a solution is provided that decouples of signaling messages and user plane traffic a solution is provided
Mobile IPv6 protection from regular IPsec operation to reduce that decouples Mobile IPv6 security from IPsec, thereby reducing
complexity in Mobile IP client implementations. 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 which relies on IPsec
and IKEv2. It provides an alternative solution which is more optimal and IKEv2. It provides an alternative solution which is more optimal
for certain deployment scenarios. for certain deployment scenarios. This and other alternative
security models have been considered by the MEXT working group at the
IETF, and it has been decided that the alternative solutions should
be published as Experimental RFCs, so that more implementation and
deployment experience with these models can be gathered. The working
group may reconsider the status of the different models in the
future, if it becomes clear that one is superior to the others.
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
skipping to change at page 5, line 25 skipping to change at page 5, line 31
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 and Binding Acknowledgement messages are examples of
binding management messages. binding management messages.
3. Background 3. Background
Work on the design and specification of Mobile IPv6 has been done Mobile IPv6 design and specification was begun in the mid to late
since the late 90s. The security architecture of Mobile IPv6 was 90s. The security architecture of Mobile IPv6 was based on the
based on the understanding that IPsec is an inherent and integral understanding that IPsec is an inherent and integral part of the IPv6
part of the IPv6 stack and any protocol that needs security should stack and any protocol that needs security should use IPsec unless
use IPsec unless there is a good reason not to. As a result of this there is a good reason not to. As a result of this mindset the
mindset the Mobile IP6 protocol relied on the use of IPsec for Mobile IP6 protocol relied on the use of IPsec for security between
security between the MN and HA. While reuse of security components the MN and HA. While reuse of security components that are part of
that are part of the IP stack is a good objective, in the case of the IP stack is a good objective, in the case of Mobile IPv6,
Mobile IPv6 implementation complexity increases quite dramatically. implementation complexity increases. It should be noted that Mobile
It should be noted that Mobile IPv4 [RFC5944] for example does not IPv4 [RFC5944] for example does not use IPsec for security and
use IPsec for security and instead has specified its own security instead has specified its own security solution. Mobile IPv4 has
solution. Mobile IPv4 has been implemented and deployed on a been implemented and deployed on a reasonably large scale and the
reasonably large scale and the security model has proven itself to be security model has proven itself to be sound.
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 transition to IKEv2 [RFC5996], Mobile IP6 [RFC3776]. With the evolution to IKEv2 [RFC5996], Mobile IP6
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].
Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile Implementation exercises of Mobile IPv6 and Dual-stack Mobile IPv6
IPv6 [RFC5555] have identified the complexity of using IPsec and [RFC5555] have identified the complexity of using IPsec and IKEv2 in
IKEv2 in conjunction with Mobile IPv6. At an abstract level it can conjunction with Mobile IPv6. Implementing Mobile IPv6 with IPsec
be said that implementing Mobile IPv6 with IPsec and IKEv2 is and IKEv2 requires modifications to both the IPsec and IKEv2
possible only with modifications to the IPsec and IKEv2 components. components, due to the communication models that Mobile IPv6 uses and
The original design intent was to reuse IPsec without having to the changing IP addresses. For further details, see Section 7.1 in
modify them. The current security model requires an IPsec/IKEv2 [RFC3776].
implementation that is specific to Mobile IPv6.
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 with reduced
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
authentication and MN-HA security association bootstrapping. authentication and MN-HA security association bootstrapping.
Authentication of the HAC is done via standard TLS operation where Authentication of the HAC is done via standard TLS operation wherein
the HAC uses a TLS server certificate as 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. This can either be MN-only secured by the TLS connection. Any EAP method can be used for
authentication within the server-authenticated TLS channel, or mutual authenticating the MN to the HAC. Upon successful completion of
authentication between the MN and HAC. Upon successful completion of
authentication, the HAC generates keys which are delivered to the MN authentication, the HAC generates keys which 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 MIP6
bootstrapping information such as the address of the HA, the Home bootstrapping information such as the IPv6 and IPv4 address of the
network prefix, and the IPv6 and/or IPv4 HoA. HA, the Home network prefix, the IPv6 and/or IPv4 HoA 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 SPIs
generated by the HAC and delivered to the MN and HA. Figure 1 below generated by the HAC and delivered to the MN and HA to secure
is an illustration of the process: signaling and optionally user plane traffic. Figure 1 below is an
illustration of the process.
Signaling messages and user plane traffic between the MN and HA are
always UDP encapsulated. The packet formats for the signaling and
user plane traffic is described in Sections 6.3 and 6.4.
MN HAC HA MN HAC HA
-- --- -- -- --- --
| | | | | |
| /-------------------------\ | | | /-------------------------\ | |
|/ \| | |/ \| |
|\ TLS session setup /| | |\ TLS session setup /| |
| \-------------------------/ | | | \-------------------------/ | |
| | | | | |
| /-------------------------\ | | | /-------------------------\ | |
skipping to change at page 13, line 46 skipping to change at page 13, line 46
bootstrapping Mobile IPv6 specific information, is exchanged between bootstrapping Mobile IPv6 specific information, is exchanged between
the MN and the HAC using the framing protocol defined in Section 5.1. the MN and the HAC using the framing protocol defined in Section 5.1.
The IP address of the HAC MAY be statically configured to the MN or The IP address of the HAC MAY be statically configured to the MN or
may be dynamically discovered using DNS. In a case of DNS-based HAC may be dynamically discovered using DNS. In a case of DNS-based HAC
discovery, the MN either queries an A/AAAA or a SRV record for the discovery, the MN either queries an A/AAAA or a SRV record for the
HAC IP address. The actual domain name used in queries is up to the HAC IP address. The actual domain name used in queries is up to the
deployment to decide and out of scope of this specification. 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-
Naur Form (BNF) same to 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 a MN. The Mobile Node Identifier is in
form of a Network Access Identifier (NAI) [RFC4282]. form of a Network Access Identifier (NAI) [RFC4282].
mn-id = "mn-id" ":" nai CRLF mn-id = "mn-id" ":" RFC4282-NAI CRLF
nai = username
| "@" realm
| username "@" realm
...
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.
skipping to change at page 24, line 26 skipping to change at page 24, line 26
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). a 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 encrypted messages. Each used to identify retransmissions of protected messages (integrity
endpoint in the security association maintains two "current" Sequence protected or both integrity protected and encrypted, see Figures 7
Numbers: the next one to be used for a packet it initiates and the and 8) . Each endpoint in the security association maintains two
next one it expects to see in a packet from the other end. If the MN "current" Sequence Numbers: the next one to be used for a packet it
and the HA ends initiate very different numbers of messages, the initiates and the next one it expects to see in a packet from the
Sequence Numbers in the two directions can be very different. In a other end. If the MN and the HA ends initiate very different numbers
case encryption is not used, the Sequence Number MUST be set to 0 of messages, the Sequence Numbers in the two directions can be very
(zero). Note that the HA SHOULD initiate a re-establishement of the different. In a case data protection is not used (see Figure 9), the
SA before any of the Sequence Number cycle. Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD
initiate a re-establishement of the SA before any of the Sequence
Number cycle.
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 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
skipping to change at page 25, line 22 skipping to change at page 25, line 22
A SPI value of 0 (zero) indicates a plaintext packet. If the packet A SPI value of 0 (zero) indicates a plaintext packet. If the packet
is integrity protected or both integrity protected and encrypted, the is integrity protected or both integrity protected and encrypted, the
SPI value MUST be different from 0. When the SPI value is set to 0, 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. All encrypted. They MUST use the packet format shown in Figure 7.
packets that are specific to the Mobile IPv6 protocol and contain a
Mobility Header (as defined in Section 6.1.1. of RFC 6275) SHOULD use All packets that are specific to the Mobile IPv6 protocol, contain a
the packet format shown in Figure 7. (This means that some Mobile Mobility Header (as defined in Section 6.1.1. of RFC 6275), and are
IPv6 mobility management messages, such as the HoTI message, as used between the MN and the HA use the packet format shown in
treated as data packets and using encapsulation described in Figure 7. (This means that some Mobile IPv6 mobility management
Section 6.4). messages, such as the HoTI message, are treated as data packets and
using encapsulation described in Section 6.4 and 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) :
skipping to change at page 27, line 17 skipping to change at page 27, line 17
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 encrypted and
those that are plaintext. The MN or the HA decide whether to apply those that are plaintext. The MN or the HA decide whether to apply
integrity protection and encryption to a packet or to send it in integrity protection and encryption to a packet or to send it in
plaintext based on the mip6-sas value in the SA. If the mip6-sas is plaintext based on the mip6-sas value in the SA. If the mip6-sas is
set to 1 the originator MUST NOT send any plaintext packet, and the set to 1 the originator MUST NOT send any plaintext packet, and the
receiver MUST silently discard any packet with the PType set to 0 receiver MUST silently discard any packet with the PType set to 0
(unprotected). It is RECOMMENDED to apply confidentiality and (unprotected). It is RECOMMENDED to apply confidentiality and
integrity protection of user data traffic. The reverse tunneled IPv4 integrity protection of user data traffic. The reverse tunneled IPv4
or IPv6 user data packets are encapsulated as-is inside the 'Payload or IPv6 user data packets are encapsulated as-is inside the 'Payload
Data' shown in Figure 8. and Figure 9. 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) :
skipping to change at page 28, line 50 skipping to change at page 28, line 50
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 care-of
address of the MN and the HA address. The plain text inner IP header address of the MN and the HA address. The plain text inner IP header
uses the home address of the MN and the CN address. uses the home address of the MN and the CN address.
7. Route Optimization 7. Route Optimization
The MN-CN route optimization protocol functionality, related messages Mobile IPv6 route optimization as described in [RFC6275] is not
and mobility options are out of scope of this specification. A affected by this specification. Route optimization is possible only
future specification may add route optimization functionality to the between an IPv6 MN and CN. UDP encapsulation of signaling and data
Transport Layer Security-based Mobile IPv6 protocol. traffic is only between the MN and HA. The return routability
signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are
We discuss few possible route optimization approaches in the treated as data packets and encapsulation, when needed, is as per the
following sections. The route optimization could be done in two description in Section 6.4 of this specification. The data packets
ways: 1) using the return routability procedure described in between an MN and CN which have successfully completed the return
[RFC6275] or 2) directly between the MN and the CN i.e. enhancing the routability test and created the appropriate entries in their binding
route optimization also for Home Agent-less operation. cache are not UDP encapsulated using the packet formats defined in
this specification but follow the [RFC6275] specification.
Both discussed solution approaches share the same tunneling
considerations between the MN and the CN. When the MN sends UDP
encapsulated packets to the CN, those are destined to CN's CoA. That
implies, the inner tunneled packets would also have the same
destination address as the outer tunneling packets. There should not
be issues regarding the decapsulation and encapsulation as long as
the inner tunneled packet does not have UDP payload with the same
destination port that the CN uses for its MN-CN UDP tunnel.
7.1. Replicating RFC6275 Route Optimization
Obviously [RFC6275] approach has already been verified from the
security considerations and procedures point of view. The existing
protocol proves both the Home Address ownership and verifies the
reachability. However, there are several gaps in scope of this
specification (TLS-based solution). For instance, the binding
management message encapsulation between the MN and the CN must be
specified and how to reach a CN using an IPv4 address. Following the
trend in this specification that would use UDP encapsulated IPv6 and
mobility headers as in Section 6.3. Another gap is the lack of SA
between the MN and the CN, if the communication were to be protected.
In order to enable the protection the CN should actually implement a
HAC function, which would then allow the MN and the CN to negotiate
required ciphersuites.
7.2. Enhanced Route Optimization with Home Agent-less Operation
If the CN were to implement a HAC, then the HAC could also
authenticate the MN. Possible authentication methods include pre-
shared secrets, certificates or using EAP+AAA against MN's home realm
AAA server (assuming the AAA infrastructure is in place). That
approach could actually allow the MN and the CN to setup secured
communication without doing the return routability test and support
Home Agent-less operation of MNs. However, the prerequisite is that
the MN has at some point of time bootstrapped with its HA e.g. to
acquire the HoA.
The "bootstrapping" between the MN and the "CN HAC" would concern a
subset of parameter needed between the MN and the "HA HAC". For
example, there is no need to negotiate Home Addresses and such. The
main use would be establishing the SA and authenticating at least the
MN to the CN.
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 for the Packet Type as IANA is requested to create a new registry under the [RFC6275] Mobile
described in Section 6.1. IPv6 parameters registry for the Packet Type as described in
Section 6.1.
Packet Type | Value Packet Type | 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 re-
establish the SA information with the HAC. The Result Code is establish the SA information with the HAC. The Result Code is
reserved from the 0-127 code space: reserved from the 0-127 code space in [RFC6275] Status Codes
registry:
REINIT_SA_WITH_HAC TBD1 REINIT_SA_WITH_HAC TBD1
8.3. Port Numbers 8.3. Port Numbers
A new port number (HALTSEC) for UDP packets is reserved from the PORT A new port number (HALTSEC) for UDP packets is reserved from the
NUMBERS registry. existing PORT NUMBERS registry.
HALTSEC TBD2 HALTSEC TBD2
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 inter-work 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
skipping to change at page 35, line 10 skipping to change at page 34, line 16
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 a case binding management messages contain
the user identity, the messages SHOULD be confidentity protected. the user identity, the messages SHOULD be confidentiality
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
skipping to change at page 35, line 40 skipping to change at page 34, line 47
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 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 and Christian Bauer for their comments. Laganier, Jari Arkko 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 36, line 43 skipping to change at page 35, line 50
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 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
[I-D.patil-mext-mip6issueswithipsec]
Patil, B., Perkins, C., Tschofenig, H., and D. Premec,
"Problems with the use of IPsec as the security protocol
for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-04
(work in progress), October 2011.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004. Home Agents", RFC 3776, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
 End of changes. 39 change blocks. 
167 lines changed or deleted 128 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/