< draft-korhonen-mext-mip6-altsec-05.txt   draft-korhonen-mext-mip6-altsec-06.txt >
Mobility Extensions (MEXT) J. Korhonen Mobility Extensions (MEXT) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Updates: 3775 (if approved) B. Patil Updates: 3775 (if approved) B. Patil
Intended status: Experimental Nokia Intended status: Experimental Nokia
Expires: January 13, 2011 H. Tschofenig Expires: April 22, 2011 H. Tschofenig
D. Kroeselberg D. Kroeselberg
Nokia Siemens Networks Nokia Siemens Networks
July 12, 2010 October 19, 2010
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-korhonen-mext-mip6-altsec-05.txt draft-korhonen-mext-mip6-altsec-06.txt
Abstract Abstract
Mobile IPv6 signaling between the mobile node and home agent is Mobile IPv6 signaling between the mobile node and 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 part of the IP stack and interaction between the Mobile IPv6 protocol part of the IP stack and
the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based security the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based security
architectures makes implementation and deployment of the protocol architectures makes implementation and deployment of the protocol
infeasible for numerous reasons. This document proposes an alternate infeasible for numerous reasons. This document proposes an alternate
security framework, which relies on Transport Layer Security for security framework, which relies on Transport Layer Security for
establishing keying material and other bootstrapping parameters establishing keying material and other bootstrapping parameters
required to protect Mobile IPv6 signaling and data traffic between required to protect Mobile IPv6 signaling and data traffic between
the mobile node and home agent. the mobile node and home agent.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 22, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TLS-based Security Establishment . . . . . . . . . . . . . . . 7 4. TLS-based Security Establishment . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Security Association Management . . . . . . . . . . . . . 9 4.3. Security Association Management . . . . . . . . . . . . . 8
4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 11 4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 10
4.5. Protecting Traffic Between Mobile Node and Home Agent . . 12 4.5. Protecting Traffic Between Mobile Node and Home Agent . . 11
5. Mobile Node to Home Agent Controller Communication . . . . . . 12 5. Mobile Node to Home Agent Controller Communication . . . . . . 11
5.1. Request-response Message Framing over TLS-tunnel . . . . . 12 5.1. Request-response Message Framing over TLS-tunnel . . . . . 11
5.2. Request-response Message Content Encoding . . . . . . . . 13 5.2. Request-response Message Content Encoding . . . . . . . . 12
5.3. Request-Response Message Exchange . . . . . . . . . . . . 13 5.3. Request-Response Message Exchange . . . . . . . . . . . . 12
5.4. Home Agent Controller Discovery . . . . . . . . . . . . . 14 5.4. Home Agent Controller Discovery . . . . . . . . . . . . . 13
5.5. Generic Request-Response Parameters . . . . . . . . . . . 14 5.5. Generic Request-Response Parameters . . . . . . . . . . . 13
5.5.1. Mobile Node Identifier . . . . . . . . . . . . . . . . 14 5.5.1. Mobile Node Identifier . . . . . . . . . . . . . . . . 13
5.5.2. Authentication Method . . . . . . . . . . . . . . . . 15 5.5.2. Authentication Method . . . . . . . . . . . . . . . . 14
5.5.3. Extensible Authentication Protocol Payload . . . . . . 15 5.5.3. Extensible Authentication Protocol Payload . . . . . . 14
5.5.4. Status Code . . . . . . . . . . . . . . . . . . . . . 15 5.5.4. Status Code . . . . . . . . . . . . . . . . . . . . . 14
5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 15 5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 15
5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 16 5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 15
5.5.7. End of Message Content . . . . . . . . . . . . . . . . 16 5.5.7. End of Message Content . . . . . . . . . . . . . . . . 15
5.5.8. Random Values . . . . . . . . . . . . . . . . . . . . 16 5.5.8. Random Values . . . . . . . . . . . . . . . . . . . . 15
5.6. Security Association Configuration Parameters . . . . . . 16 5.6. Security Association Configuration Parameters . . . . . . 15
5.6.1. Security Parameter Index . . . . . . . . . . . . . . . 17 5.6.1. Security Parameter Index . . . . . . . . . . . . . . . 16
5.6.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 17 5.6.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 16
5.6.3. Security Association Validity Time . . . . . . . . . . 17 5.6.3. Security Association Validity Time . . . . . . . . . . 16
5.6.4. Security association scope (SAS) . . . . . . . . . . . 17 5.6.4. Security association scope (SAS) . . . . . . . . . . . 16
5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 18 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17
5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 19 5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18
5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 19 5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18
5.7.2. Home Addresses and Home Network Prefix . . . . . . . . 19 5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18
5.7.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . 20 5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 19
5.8. Authentication of the Mobile Node . . . . . . . . . . . . 20 5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19
5.9. Extensible Authentication Protocol Methods . . . . . . . . 22 5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19
6. Mobile Node to Home Agent communication . . . . . . . . . . . 24 5.9. Extensible Authentication Protocol Methods . . . . . . . . 21
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Mobile Node to Home Agent communication . . . . . . . . . . . 23
6.2. Security Parameter Index . . . . . . . . . . . . . . . . . 25 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3. Binding Management Message Formats . . . . . . . . . . . . 26 6.2. Security Parameter Index . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . . . 29 7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29 8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29
8.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 30 8.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 29
8.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 30 8.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29
8.4. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 30 8.4. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30
9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Mobile IPv6 [RFC3775] signaling, and optionally user traffic, between Mobile IPv6 [RFC3775] signaling, and optionally user traffic, between
a mobile node (MN) and home agent (HA) are secured by IPsec 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. Implementation experience has shown that IPsec part of the IP stack. Implementation experience has shown that
the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex. The the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex. The
issues with the IKE(v2)/IPsec based security architecture are issues with the IKE(v2)/IPsec based security architecture are
documented in [I-D.patil-mext-mip6issueswithipsec]. 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. Transport Layer Security (TLS) [RFC5246] is widely implemented IPv6. Transport Layer Security (TLS) [RFC5246] is widely implemented
in almmost all major operating systems and extensively used. Instead in almost all major operating systems and extensively used. Instead
of using IKEv2, the security framework proposed in this document is of using IKEv2, the security framework proposed in this document is
based on TLS protected messages to exchange keys and bootstrapping based on TLS protected messages to exchange keys and bootstrapping
parameters between the Mobile Node and a new functional entity called parameters between the Mobile Node and a new functional entity called
as the Home Agent Controller (HAC). The Mobile IPv6 signaling as the Home Agent Controller (HAC). The Mobile IPv6 signaling
between the mobile node and home agent is subsequently secured using between the mobile node and home agent is subsequently secured using
the resulting keys and negotiated cipher suite. The HAC can be co- 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 located with the HA, or can be an independent entity. For the latter
case, communication between HAC and HA is not defined by this case, communication between HAC and HA is not defined by this
document. The Diameter protocol can be used between the HA and HAC document. The Diameter protocol can be used between the HA and HAC
when the two entities are not colocated. when the two entities are not collocated.
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 equivalent level of security. For the protection of
Mobile IPv6 signaling messages a solution is provided that decouples Mobile IPv6 signaling messages a solution is provided that decouples
Mobile IPv6 protection from regular IPsec operation to reduce Mobile IPv6 protection from regular IPsec operation to reduce
complexity in Mobile IP client implementations. complexity in Mobile IP client implementations.
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
skipping to change at page 6, line 39 skipping to change at page 5, line 39
use IPsec unless there is a good reason not to. As a result of this use IPsec unless there is a good reason not to. As a result of this
mindset the Mobile IP6 protocol relied on the use of IPsec for mindset the Mobile IP6 protocol relied on the use of IPsec for
security between the MN and HA. It should be noted that Mobile IPv4 security between the MN and HA. It should be noted that Mobile IPv4
[RFC3344] for example does not use IPsec for security and instead has [RFC3344] for example does not use IPsec for security and instead has
specified its own security solution. Mobile IPv4 has been specified its own security solution. Mobile IPv4 has been
implemented and deployed on a reasonably large scale and the security implemented and deployed on a reasonably large scale and the security
model has proven itself to be sound. 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 transition to IKEv2 [RFC4306], Mobile IP6 [RFC3776]. With the transition 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 Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile
IPv6 [RFC5555] have identified the complexity of using IPsec and IPv6 [RFC5555] have identified the complexity of using IPsec and
IKEv2 in conjunction with Mobile IPv6. At an abstract level it can IKEv2 in conjunction with Mobile IPv6. At an abstract level it can
be said that implementing Mobile IPv6 with IPsec and IKEv2 is be said that implementing Mobile IPv6 with IPsec and IKEv2 is
possible only with modifications to the IPsec and IKEv2 components. possible only with modifications to the IPsec and IKEv2 components.
The original design intent was to reuse IPsec without having to The original design intent was to reuse IPsec without having to
modify them. The current security model requires an IPsec/IKEv2 modify them. The current security model requires an IPsec/IKEv2
implementation that is specific to Mobile IPv6. implementation that is specific to Mobile IPv6.
skipping to change at page 11, line 29 skipping to change at page 10, line 29
When the MN contacts the HAC to distribute of the security related When the MN contacts the HAC to distribute of the security related
information, the HAC may also provision the MN with various Mobile information, the HAC may also provision the MN with various Mobile
IPv6 related bootstrapping information. Bootstrapping of the IPv6 related bootstrapping information. Bootstrapping of the
following information SHOULD at least be possible: following information SHOULD at least be possible:
Home Agent IP Address: Home Agent IP Address:
Concerns both IPv6 and IPv4 home agent addresses. Concerns both IPv6 and IPv4 home agent addresses.
Mobile IPv6 Service Port Number:
The port number where the HA is listening to UDP [RFC0768]
packets.
Home Address: Home Address:
Concerns both IPv6 and IPv4 Home Addresses. Concerns both IPv6 and IPv4 Home Addresses.
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
assiggned by the access network to which the MN is attached and assigned by the access network to which the MN is attached and
hence an additional DNS server address which is reachable via the hence an additional DNS server address which is reachable via the
HA needs to be configured. HA needs to be configured.
The Mobile IPv6 related bootstrapping information is delivered from The Mobile IPv6 related bootstrapping information is delivered from
the HAC to the MN over the same TLS protected tunnel as the security the HAC to the MN over the same TLS protected tunnel as the security
related information. related 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
skipping to change at page 19, line 40 skipping to change at page 18, line 44
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 a HA,
or both. 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. Home Addresses and Home Network Prefix 5.7.2. Mobile IPv6 Service Port Number
The HAC SHOULD provision the MN with an UDP port number, where the HA
expects to receive UDP packets. If this parameter is not present,
then the IANA reserved port number (HALTSEC) MUST be used instead.
mip6-port = "mip6-port" ":" 1*5DIGIT CRLF
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
mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF
mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF
mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF
5.7.3. DNS Server 5.7.4. DNS Server
The HAC may also provide the MN with DNS server configuration The HAC may also provide the MN with DNS server configuration
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 GPSK exchange used by EAP-GPSK [RFC5433]. It is secured
by the TLS tunnel and is cryptographically bound to the TLS tunnel by the TLS tunnel and is cryptographically bound to the TLS tunnel
through channel binding based on [RFC5056] and on the channel binding through channel binding based on [RFC5056] and on the channel binding
type 'tls-server-endpoint' described in type 'tls-server-endpoint' described in [RFC5929]. As a result of
[I-D.altman-tls-channel-bindings]. As a result of the channel the channel binding type, this method can only be used with TLS
binding type, this method can only be used with TLS ciphersuites that ciphersuites that use server certificates and the Certificate
use server certificates and the Certificate handshake message. For handshake message. For example, TLS ciphersuites based on PSK or
example, TLS ciphersuites based on PSK or anonymous authentication anonymous authentication cannot be used.
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 pre-shared key (PSK) or based on an EAP-method (see
Section 5.9). The PSK protocol is described in this section. It Section 5.9). The PSK protocol is described in this section. It
consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth- consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth-
Done) in which both sides exchange nonces and their identities, and Done) in which both sides exchange nonces and their identities, and
compute and exchange a message authenticator 'auth' over the compute and exchange a message authenticator 'auth' over the
previously exchanged values, keyed with the pre-shared key. The previously exchanged values, keyed with the pre-shared key. The
MHAuth-Done messages are used to deal with error situations. Key MHAuth-Done messages are used to deal with error situations. Key
binding with the TLS tunnel is ensured by channel binding of the type binding with the TLS tunnel is ensured by channel binding of the type
"tls-server-endpoint" as described by "tls-server-endpoint" as described by [RFC5929] where the hash of the
[I-D.altman-tls-channel-bindings] where the hash of the TLS server TLS server certificate serves as input to the 'auth' calculation of
certificate serves as input to the 'auth' calculation of the MHAuth the MHAuth messages.
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 21, line 48 skipping to change at page 21, line 8
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 endpoint" type) are the same as described in [RFC5929].
[I-D.altman-tls-channel-bindings].
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 HAC
in MHAuth-Init. The decision of which authentication method to offer in MHAuth-Init. The decision of which authentication method to offer
and which to pick is policy- and implementation-dependent and, 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
skipping to change at page 24, line 28 skipping to change at page 23, line 28
effect of Authentication shared-key MUST be the MSK in all MHAuth- effect of Authentication shared-key MUST be the MSK in all MHAuth-
Done messages. This MSK MUST NOT be used for any other purpose. In Done messages. This MSK MUST NOT be used for any other purpose. In
case the EAP method does not generate an MSK key, shared-key is set case the EAP method does not generate an MSK key, shared-key is set
to "1". 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 [I-D.altman-tls-channel-bindings]. 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 sections 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 plain text
user data. This specification defines a generic packet format, where user 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 Section 6.3 and
Section 6.4 for detailed illustrations of the corresponding packet Section 6.4 for detailed illustrations of the corresponding packet
formats. formats.
The Mobile IPv6 service port number (HALTSEC), where the HA expects The Mobile IPv6 service port number is where the HA expects to
to receive UDP packets, is reserved by IANA. The same port number is receive UDP packets. The same port number is used for both binding
used for both binding management messages and user data packets. The management messages and user data packets. The reason for
reason for multiplexing data and control messages over the same port multiplexing data and control messages over the same port number is
number is due to the possibility of Network Address and Port due to the possibility of Network Address and Port Translators
Translators located along the path between the MN and the HA. The located along the path between the MN and the HA. The Mobile IPv6
Mobile IPv6 service MAY use any ephemeral port number as the UDP service MAY use any ephemeral port number as the UDP source port, and
source port, and MUST use the Mobile IPv6 service port number MUST use the Mobile IPv6 service port number as the UDP destination
(HALTSEC) as the UDP destination port. port. The Mobile IPv6 service port is either dynamically assigned to
the MN during the bootstrapping phase (i.e. the mip6-port parameter)
or in absence of the bootstrapping parameter the IANA reserved port
(HALTSEC) MUST be used.
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 or a, an encrypted user data
packet, or a plain text user data packet. packet, or a plain text 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). 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 encrypted messages. Each
skipping to change at page 30, line 39 skipping to change at page 29, line 47
8.4. Port Numbers 8.4. 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 PORT
NUMBERS registry. 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 interwork 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
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
skipping to change at page 31, line 49 skipping to change at page 31, line 9
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 key 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 channel binding type 'TLS-server-endpoint' as per [RFC5929] MUST
[I-D.altman-tls-channel-bindings] MUST be used. be 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 case
the PSK-based method as per section 5.8. is used, and are the same the PSK-based method as per section 5.8. is used, and are the same
as those of the underlying EAP method in case the EAP-based as those of the underlying EAP method in case the EAP-based
exchange as per section 5.9 is used. exchange as per section 5.9 is used.
Replay Protection: The underlying TLS protection provides protection Replay Protection: The underlying TLS protection provides protection
skipping to change at page 33, line 7 skipping to change at page 32, line 16
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 or
EAP-based authentication exchanges can be performed across the 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 [I-D.altman-tls-channel-bindings] 'TLS-server-endpoint' as per [RFC5929] MUST be used.
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 35, line 43 skipping to change at page 35, line 4
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, and The authors would like to thank Pasi Eronen, Domagoj Premec, and
Christian Bauer for their comments. Christian Bauer for their comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.altman-tls-channel-bindings]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", draft-altman-tls-channel-bindings-10 (work in
progress), March 2010.
[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.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
skipping to change at page 36, line 44 skipping to change at page 35, line 45
[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.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010.
11.2. Informative References 11.2. Informative References
[I-D.patil-mext-mip6issueswithipsec] [I-D.patil-mext-mip6issueswithipsec]
Patil, B., Premec, D., Perkins, C., and H. Tschofenig, Patil, B., Premec, D., Perkins, C., and H. Tschofenig,
"Problems with the use of IPsec as the security protocol "Problems with the use of IPsec as the security protocol
for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-03 for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-03
(work in progress), July 2010. (work in progress), July 2010.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[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.
skipping to change at page 37, line 27 skipping to change at page 36, line 35
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007. April 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, February 2009. RFC 5433, February 2009.
[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.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Authors' Addresses Authors' Addresses
Jouni Korhonen 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
 End of changes. 38 change blocks. 
111 lines changed or deleted 117 lines changed or added

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