One document matched: draft-korhonen-mext-mip6-altsec-01.txt
Differences from draft-korhonen-mext-mip6-altsec-00.txt
Mobility Extensions (MEXT) J. Korhonen
Internet-Draft Nokia Siemens Networks
Updates: 3775 (if approved) B. Patil
Intended status: Standards Track Nokia
Expires: January 14, 2010 H. Tschofenig
Nokia Siemens Networks
July 13, 2009
Transport Layer Security-based Mobile IPv6 Security Framework for Mobile
Node to Home Agent Communication
draft-korhonen-mext-mip6-altsec-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Korhonen, et al. Expires January 14, 2010 [Page 1]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Abstract
Mobile IPv6 signaling between the mobile node and home agent is
secured using IPsec. The security association between a mobile node
and the home agent is established using IKEv1 or IKEv2. The security
model specified for Mobile IPv6, which relies on IKE/IPsec, requires
interaction between the Mobile IPv6 protocol part of the IP stack and
the IKE/IPsec part of the IP stack. Implementation and deployment
concerns exist with such a security architecture. This document
proposes an alternate security framework, which relies on Transport
Layer Security for establishing keying material and other parameters
required to protecting Mobile IPv6 signaling and data traffic between
the mobile node and home agent.
Korhonen, et al. Expires January 14, 2010 [Page 2]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TLS-based Security Framework . . . . . . . . . . . . . . . . . 5
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Security Association Management . . . . . . . . . . . . . 6
4.3. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 7
4.4. Protecting Traffic Between the Mobile Node and the
Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Solution Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. HTTPS-based Mobile IPv6 Bootstrapping . . . . . . . . . . 8
5.2. Configuring Security Association Parameters . . . . . . . 9
5.2.1. Security Parameter Index . . . . . . . . . . . . . . . 10
5.2.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 10
5.2.3. Security Association Validity Time . . . . . . . . . . 11
5.2.4. CipherSuite . . . . . . . . . . . . . . . . . . . . . 11
5.3. Configuring Mobile IPv6 Parameters . . . . . . . . . . . . 11
5.3.1. Home Agent Address . . . . . . . . . . . . . . . . . . 11
5.3.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 11
5.3.3. Home Addresses and Home Network Prefix . . . . . . . . 12
5.4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 12
5.4.1. Binding Management Messages . . . . . . . . . . . . . 13
5.4.2. Reverse Tunneled User Data Packets . . . . . . . . . . 14
5.5. Protecting Traffic Between the Mobile Node and the
Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6. Route Optimization . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 17
6.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 18
7.2. Authentication and Key Exchange executed between the
MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Protection of MN and HA Communication . . . . . . . . . . 20
7.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Korhonen, et al. Expires January 14, 2010 [Page 3]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
1. Introduction
Mobile IPv6 [RFC3775] signaling, and optionally user traffic, between
a mobile node (MN) and home agent (HA) is secured by IPsec [RFC4301].
The current Mobile IPv6 security architecture is specified in
[RFC3776] and [RFC4877]. This security model requires a tight
coupling between the Mobile IPv6 protocol part of the IP stack and
the IKE/IPsec part of the IP stack. Implementation experience has
indicated that the use of IKE/IPsec with Mobile IPv6 is fairly
complex. The issues with the IKE/IPsec based security architecture
are documented in [I-D.patil-mext-mip6issueswithipsec].
This document proposes an alternate security framework for Mobile
IPv6. Transport Layer Security (TLS) [RFC5246] is widely implemented
in most operating systems and used. The security framework is based
on reusing TLS to secure Mobile IPv6 signaling and reverse tunneled
traffic between the MN and the HA. The primary advantage of using
TLS for Mobile IP6 security is the ease of implementation while
providing the equivalent security measures as compared to IPsec. The
TLS-based security framework for Mobile IP6 does not deprecate the
use of IKE/IPsec for Mobile IP6 security. Rather it provides an
alternative security solution to Mobile IPv6 implementations and
deployment.
2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Home Agent Controller (HAC):
The home agent controller is a node responsible for bootstrapping
the security association between a mobile node and one or more
home agents. The home agent controller also provides required key
distribution to both mobile nodes and home agents. A generic
Mobile IPv6 bootstrapping can be done as part of the security
association bootstrapping.
Binding Management Message:
A message used by mobile nodes, correspondent nodes, and home
agents in all messaging related to the creation and management of
bindings. Binding Updates and Binding Acknowledgement messages
are examples of binding management messages.
Korhonen, et al. Expires January 14, 2010 [Page 4]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
3. Background
Work on the design and specification of Mobile IPv6 has been done
since the late 90s. The security architecture of Mobile IPv6 was
based on the understanding that IPsec is an inherent and integral
part of the IPv6 stack and any protocol that needs security should
use IPsec unless there is a good reason not to. As a result of this
mindset the Mobile IP6 protocol relied on the use of IPsec for
security between the MN and HA. It should be noted that Mobile IPv4
[RFC3344] for example does not use IPsec for security and instead has
specified its own security solution.
Mobile IPv6 standardization was finished in 2005 along with the
security architecture using IKE/IPsec specified in RFC 3776
[RFC3776]. With the transition to IKEv2 [RFC4306], Mobile IP6
security has also been updated to rely on the use of IKEv2 [RFC4877].
Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile
IPv6 [RFC5555] have identified the complexity of using IPsec and
IKEv2 in conjunction with Mobile IP6. At an abstract level it can be
said that implementing Mobile IP6 with IPsec and IKEv2 is possible
only with modifications to the IPsec and IKEv2 components. The
original design intent was to reuse IPsec without having to modify
it. There is also a view that IPsec is not necessarily the most well
suited security protocol for Mobile IPv6.
To alleviate the implementation complexity concerns and to create a
security architecture that would be easier to implement, and to
deploy this document proposes a security framework based on TLS.
4. TLS-based Security Framework
4.1. Architecture
The generic TLS-based security architecture is shown in Figure 1.
The signaling exchange between the MN and the HAC is protected by
TLS. It should be noted that a HAC, a AAA server and a HA are
logically separate entities and can be collocated in all possible
combinations. There MUST be a strong trust relationship between the
HA and the HAC, and the communication between them MUST be both
integrity and confidentially protected.
Korhonen, et al. Expires January 14, 2010 [Page 5]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
+------+ +------+ +------+
|Mobile| TLS |Home | AAA | AAA |
| Node |<----------->|Agent |<---------->|Server|
| | |Contrl| | |
+------+ +------+ +------+
^ ^ ^
| | |
| BU/BA/../ | e.g. AAA | AAA
| (Data) | |
| v |
| +---------+ |
| | MIPv6 | |
+--------------->| Home |<-------------+
| Agent(s)|
+---------+
Figure 1: TLS-based Security Architecture Overview
4.2. Security Association Management
Once the MN has contacted the HAC and mutual authentication has taken
place between the MN and the HAC using TLS provided mechanisms, the
HAC provisions the MN with all security related information inside
the TLS protected tunnel. This security related information
constitutes a security association (SA) between the MN and the HA.
The created SA MUST NOT be tied to the Care-of Address (CoA) of the
MN.
The HAC may proactively distribute the SA information to HAs under
its management, or the HA may query the SA information from the HAC
once the MN contacts the HA. The HA MUST be able to query/index the
SA information from the HAC based on the combination of a MN Identity
(typically represented in a Network Access Identifier (NAI) [RFC4282]
format) and a Security Parameter Index (SPI). Within a HAC assigned
HA, the SPI alone MUST be enough to index the SA information.
In certain situations, the HA may want the MN to re-establish the SA
even if the existing SA is still valid. The HA can indicate this to
the MN using a dedicated Status Code in a BA (value set to
REINIT_SA_WITH_HAC). As a result, the MN would contact the HAC prior
the SA times out, and the HAC would provision the MN and HAs with a
new SA information.
The SA contains at least the following information:
Korhonen, et al. Expires January 14, 2010 [Page 6]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Mobility SPI:
This parameter is an SPI used by the MN and the HA to index the SA
between the MN and the HA. The HAC is responsible for assigning
SPIs to MNs. There is only one SPI for both binding management
messaging and possible user data protection. The same SPI is used
for both directions between the MN and the HA.
MN-HA shared key:
This parameter is a key used for ciphering Mobile IPv6 traffic
between the MN and the HA. The HAC is responsible for generating
this key. The key generation algorithm is specific to the HAC
implementation.
Security association validity time:
This parameter represents the validity time for the security
association. The HAC is responsible for defining the lifetime
value based on its policies. The lifetime may be in the order of
hours or weeks. The MN MUST re-contact the HAC before the SA
validity time ends.
Selected ciphersuite:
This parameter is the ciphersuite used to protect the traffic
between the MN and the HA. The selected algorithms are one of the
mutually supported ciphersuites of the negotiated TLS version
between the MN and the HAC. The HAC is responsible for choosing
the mutually supported ciphersuite that complies with the policy
of the HAC. Obviously, the HAs under HAC's management must have
at least one ciphersuite with the HAC in common and need to be
aware of the implemented ciphersuites.
Sequence number:
This parameter represents a monotonically increasing unsigned
sequence number used in all protected packets exchanged between
the MN and the HA. The initial sequence number MUST always be set
to 0 (zero). The sequence number may cycle to 0 (zero) when it
increases beyond its maximum defined value.
4.3. Bootstrapping of Additional Mobile IPv6 Parameters
When the MN contacts the HAC to distribute of the security related
information, the HAC may also provision the MN with various Mobile
IPv6 related bootstrapping information. Bootstrapping of the
Korhonen, et al. Expires January 14, 2010 [Page 7]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
following information SHOULD at least be possible:
Home Agent IP Address:
Concerns both IPv6 and IPv4 home agent addresses.
Mobile IPv6 Service Port Number:
The port number where the HA and the MN are listening to UDP
[RFC0768] packets. There is no fixed or IANA allocated port
number defined in this specification for Mobile IPv6. Rather,
deployments are free to choose any valid and available port number
for their HAs and MNs.
Home Address:
Concerns both IPv6 and IPv4 Home Addresses.
The Mobile IPv6 related bootstrapping information is delivered from
the HAC to the MN over the same TLS protected tunnel as the security
related information.
4.4. Protecting Traffic Between the Mobile Node and the Home Agent
The same integrity and confidentiality algorithms MUST be used to
protect both binding management messages and reverse tunneled user
data traffic between the MN and the HA. Generally, all binding
management messages (BUs, BAs and so on) MUST be both integrity and
confidentially protected. The reverse tunneled user data traffic
SHOULD be equivalently protected. Generally, the rules stated in
[RFC3775] concerning the protection of the traffic between the MN and
the HA apply also in this specification.
5. Solution Description
5.1. HTTPS-based Mobile IPv6 Bootstrapping
The scope of this specification, in comparison to the entire
architecture depicted in Figure 1, is shown in Figure 2 and reuses
well-known IETF technology, namely HTTP over TLS (HTTPS) [RFC2818]
for securing the communication between the MN and the HAC and for
establishing Mobile IPv6 specific security associations and
(optionally) for securely exchanging additional configuration data.
To protect the signaling and optionally the data traffic between the
MN and the HA the IPsec ESP header formats are re-used.
Korhonen, et al. Expires January 14, 2010 [Page 8]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
+------+ +------+
|Mobile| HTTPS |Home |
| Node |<----------->|Agent |
| | |Contrl|
+------+ +------+
^
| UDP encapsulated
| BU/BA/../Data
| packets +---------+
| | MIPv6 |
+--------------->| Home |
| Agent |
+---------+
Figure 2: HTTPS-based Security Architecture
The MN can be authenticated towards the HAC in two ways. First, the
MN can be authenticated at the TLS layer, assuming the MN and the HAC
can mutually authenticate each other. Second, the MN can be
authenticated separately using some authentication framework running
on top of HTTP. However, it is entirely a deployment specific
decision which way to choose.
All bootstrapping information, whether for setting up the SA or for
configuring Mobile IPv6 specific information, is exchanged between
the MN and the HAC in HTTP request and response headers. The MN MUST
have an Universal Resource Identifier (URI) [RFC3986] to contact the
HAC. The URI could be statically configured, provisioned or derived
by some deployment specific method. For example
https://www.example.com/mip6-login.html
could be a valid URI configured in the MN. At minimum the MN does a
"GET" to the HAC URI, and receives a successful HTTP response with
headers and an empty "page".
The encoding of the HTTP headers complies to the augmented Backus-
Naur Form (BNF) defined in Section 2.1 of [RFC2616]. All presented
hexadecimal numbers are in network byte order.
5.2. Configuring Security Association Parameters
During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a
single ciphersuite for protecting the traffic between the MN and the
HA. The available ciphersuites for this specification are the same
as those in TLS v1.2 (see Annex A.5 of [RFC5246]). This might appear
as a constraint as the HA and the HAC may have implemented different
ciphersuites. These two nodes are, however, assumed to belong to the
Korhonen, et al. Expires January 14, 2010 [Page 9]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
same administrative domain. In order to avoid exchanging supported
MN-HA ciphersuites in the MN-HAC protocol and to reuse the TLS
ciphersuite negotiation procedure we make this simplifying
assumption. The selected ciphersuite MUST provide integrity and
confidentially protection.
To map the TLS ciphersuites with the ESP algorithms it is necessary
to ignore the algorithm part that focuses on the authentication in
the TLS handshake. For example, RFC 3268 [RFC3268] defines a number
of AES based ciphersuites for TLS including
'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the relevant
part is 'AES_128_CBC_SHA'. The next task is to find a suitable ESP
algorithm that matches the TLS ciphersuite. The relevant
specification can be found with [RFC3602] and the algorithm
combination for usage with ESP would be RFC 3602 with AES-128 in CBC
mode with HMAC-SHA-1-96. As another example,
'LS_RSA_WITH_AES_256_CBC_SHA' would translate to 'AES_256_CBC_SHA'
and could map to RFC 3602 with AES-128 in CBC mode with HMAC-SHA-256
described in [RFC4868]. (** A table with TLS ciphersuite to ESP
algorithm mappings is required and will be provided in a future
version of this document **)
All the parameters described in the following sections apply only to
a HTTPS response the MN. The MN has no way affecting to the
provisioning decision of the HAC.
5.2.1. Security Parameter Index
The 28-bit unsigned SPI number identifies the SA used between the MN
and the HA. The value 0 (zero) is reserved and MUST NOT be used.
Therefore, values ranging from 1 to 268435455 are valid.
The HTTP header corresponding to the SPI number is:
mip6-spi = "mip6-spi" ":" 1*DIGIT
5.2.2. MN-HA Shared Keys
The MN-HA shared keys are used to protect the traffic between the MN
and the HA. The length of these keys depend on the selected
ciphersuite.
The HTTP headers that carry these two parameters are:
mip6-mn-to-ha-key = "mip6-mn-to-ha-key" ":" 1*(HEX HEX)
mip6-ha-to-mn-key = "mip6-ha-to-mn-key" ":" 1*(HEX HEX)
For cases where an algorithm does not provide integrity combined with
Korhonen, et al. Expires January 14, 2010 [Page 10]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
confidentiality protection an additional key derivation step is
required to derive additional keying material. A future version of
this document will address this issue.
5.2.3. Security Association Validity Time
The end of the SA validity time is encoded using the "rfc1123-date"
format, as defined in Section 3.3.1 of [RFC2616].
The HTTP header corresponding to the SA validity time value is:
mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date
5.2.4. CipherSuite
The ciphersuites follow the TLS 1.2 numeric representation defined in
Annex A.5 of [RFC5246]. The HTTP header corresponding to the
selected ciphersuite is:
mip6-ciphersuite = "mip6-ciphersuite" ":" 2HEX "," 2HEX
5.3. Configuring Mobile IPv6 Parameters
In parallel with the SA bootstrapping, the HAC SHOULD provision the
MN with relevant Mobile IPv6 related bootstrapping information.
The following generic BNFs are used to form IP addresses and
prefixes. They are used in subsequent sections.
ip6-addr = 7( word ":" ) word
word = 1*4HEX
ip6-prefix = ip6-addr "/" 1*2DIGIT
ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
5.3.1. Home Agent Address
The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA,
or both.
mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr
mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr
5.3.2. Mobile IPv6 Service Port Number
The HAC SHOULD provision the MN with an UDP port number. The port
number is used by the MNs and the HAs as the UDP destination port
number when they initiate messages towards each other.
Korhonen, et al. Expires January 14, 2010 [Page 11]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
mip6-port = "mip6-port" ":" 1*5DIGIT
5.3.3. Home Addresses and Home Network Prefix
The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or
both. The HAC MAY also provision the MN with its home network
prefix.
mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr
mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr
mip6-hnp-ip6 = "mip6-ip6-hnp" ":" ip6-prefix
5.4. Packet Formats
The following sections describe the packet formats used for the
traffic between the MN and the HA. This traffic includes binding
management messages (for example, BU and BA messages), reverse
tunneled and encrypted user data, and reverse tunneled plain text
user data. This specification defines a generic packet format, where
everything is encapsulated inside an UDP. See Section 5.4.1 and
Section 5.4.2 for detailed illustrations of the corresponding packet
formats.
The Mobile IPv6 service port number, where the HA or the MN expect to
receive UDP packets, is negotiated during the SA bootstrapping or
statically configured. The same port number is used for both binding
management messages and user data packets. The reason for
multiplexing data and control messages over the same port number is
due to the possibility of Network Address and Port Translators
located along the path between the MN and the HA. The Mobile IPv6
service MAY use any ephemeral port number as the UDP source port, and
MUST use the Mobile IPv6 service port number as the UDP destination
port.
The encapsulating UDP header is immediately followed by a 4-bit
Packet Type (PType) field that defines whether the packet contains an
encrypted mobility management message, an encrypted user data packet,
or a plain text user data packet.
The Packet Type field is followed by a 28-bit SPI value, which
identifies the correct SA concerning the encrypted packet. In a case
encryption is not used, the SPI MUST be set to 0 (zero). There is
always only one SPI per mobility session and the same SPI is used for
all types of encrypted packets independent of the direction.
The SPI value is followed by a 32-bit Sequence Number value that is
used to identify retransmissions of encrypted messages. Each
endpoint in the security association maintains two "current" Sequence
Korhonen, et al. Expires January 14, 2010 [Page 12]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Numbers: the next one to be used for a packet it initiates and the
next one it expects to see in a packet from the other end. If the MN
and the HA ends initiate very different numbers of messages, the
Sequence Numbers in the two directions can be very different. In a
case encryption is not used, the Sequence Number MUST be set to 0
(zero). Note that the HA SHOULD initiate a re-establishement of the
SA before any of the Sequence Number cycle.
Finally, the Sequence Number field is followed by the data portion,
whose content is identified by the Packet Type. When the data
portion is protected, it is again encapsulated inside an
Encapsulating Security Payload (ESP) [RFC4303] excluding the SPI and
Sequence Number fields that were already introduced earlier.
Actually, when data protection is used, the construction of the
packet on the wire is the same as an UDP encapsulated ESP packet in a
tunnel mode as defined in [RFC3948].
5.4.1. Binding Management Messages
The binding management messages that are only meant to be exchanged
between the MN and the HA MUST be security protected and MUST use the
packet format shown in Figure 3. All packets that are specific to
the Mobile IPv6 protocol and contain a Mobility Header (as defined in
Section 6.1.1. of RFC 3775) SHOULD use the packet format shown in
Figure 3. (This means that some Mobile IPv6 mobility management
messages, such as the HoTI message, as treated as data packets and
using encapsulation described in Section 5.4.2)
Korhonen, et al. Expires January 14, 2010 [Page 13]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=8| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Encapsulating Security Payload (ESP) after the Sequence :
: Number field as defined in Section 2 of [RFC4303] :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: UDP Encapsulated Binding Management Message Format
The PType value 8 (eight) identifies that the UDP encapsulated packet
contains an encrypted RFC 3775 defined Mobility Header and other
relevant IPv6 extension headers. Note, there is no additional IP
header inside the encapsulated part. The Next Header field in the
ESP header MUST be set to value of the first encapsulated header.
The encapsulated headers follow the natural IPv6 and Mobile IPv6
extension header alignment and formatting rules.
The source and destination IP addresses of the outer IP header (i.e.
the src-addr and the dst-addr in Figure 3) use the current care-of
address of the MN and the HA address.
5.4.2. Reverse Tunneled User Data Packets
There are two types of reverse tunneled user data packets between the
MN and the HA. Those that are encrypted and those that are
plaintext. The MN or the HA MAY switch between the encryption and
plain text at any time based on local policies. It is RECOMMENDED to
apply confidentiality and integrity protection of user data traffic.
The reverse tunneled IPv4 or IPv6 user data packets are encapsulated
as-is inside the ESP.
Korhonen, et al. Expires January 14, 2010 [Page 14]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=1| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Encapsulating Security Payload (ESP) after the Sequence :
: Number field as defined in Section 2. of [RFC4303] :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: UDP Encapsulated Protected User Data Packet Format
The PType value 1 (one) identifies that the UDP encapsulated packet
contains an encrypted tunneled IPv4/IPv6 user data packet. The Next
Header field in the ESP header MUST be set to value corresponding the
tunneled IP packet (e.g., 41 for IPv6).
The source and destination IP addresses of the outer IP header (i.e.,
the src-addr and the dst-addr in Figure 4) use the current care-of
address of the MN and the HA address. The ESP protected inner IP
header, which is not shown in Figure 4, uses the home address of the
MN and the correspondent node (CN) address.
Korhonen, et al. Expires January 14, 2010 [Page 15]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 Packet (plain) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: UDP Encapsulated Non-Protected User Data Packet Format
The PType value 0 (zero) identifies that the UDP encapsulated packet
contains a plaintext tunneled IPv4/IPv6 user data packet. Also the
SPI and the Sequence Number fields MUST be set to 0 (zero).
The source and destination IP addresses of the outer IP header (i.e.,
the src-addr and the dst-addr in Figure 5) use the current care-of
address of the MN and the HA address. The plain text inner IP header
uses the home address of the MN and the CN address.
5.5. Protecting Traffic Between the Mobile Node and the Home Agent
As briefly described in Section 5.4, all traffic between the MN and
the HA can be protected by ESP-over-UDP type encapsulation. Figure 6
shows a detailed structure of the ESP packet, which is slightly
modified from the ESP packet layout found in Section 2 of RFC 4303
[RFC4303]. The only notable difference is that the SPI is prefixed
with 4-bit PType field leaving 28-bit SPI value, although from the
ESP processing point of view, the 4-bit PType and 28-bit SPI are
handled as one "32-bit SPI". Furthermore, only 32-bit Sequence
Numbers are supported.
Korhonen, et al. Expires January 14, 2010 [Page 16]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| PType | Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| IV (optional) | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Rest of Payload Data (variable) | | |
: : | |
| | |Conf.
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | TFC Padding * (optional, variable) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Padding (0-255 bytes) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Substructure of ESP Protected Payload Data with a 28-bit
SPI and 4-bit PType Modifications
* An implementation can add Traffic Flow Confidentiality (TFC)
padding (see Section 2.7 of RFC 4303 [RFC4303]) after the Payload
Data and before the Padding (0-255 bytes) field.
The general processing and construction of the ESP is described in
RFC 4303 [RFC4303]. The used integrity and confidentially protection
algorithms are defined by the ciphersuite that was provided by the
HAC during the TLS-based bootstrapping of the SA.
5.6. Route Optimization
The treatment of MN-CN route optimization is outside the scope of
this document.
6. IANA Considerations
6.1. New Registry: Packet Type
IANA is requested to create a new registry for the Packet Type as
described in Section 5.4.
Korhonen, et al. Expires January 14, 2010 [Page 17]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Packet Type | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8
Following the allocation policies from [RFC5226] new values for the
Packet Type AVP MUST be assigned based on the "RFC Required" policy.
6.2. HTTP Headers
A number of HTTP headers with their respective parameters are
reserved. See Section 5.2 and Section 5.3 for a list of header names
and their parameters.
6.3. Status Codes
A new Status Code (to be used in BA messages) is reserved for the
cases where the HA wants to indicate to the MN that it needs to re-
establish the SA information with the HAC. The Result Code is
reserved from the 0-127 code space:
REINIT_SA_WITH_HAC TBD
7. Security Considerations
This document uses a number of building blocks that need to interwork
in order to secure the key management protocol and data traffic
protection protocol described in this document.
The following aspects need to be considered from a security point of
view:
1. Discovery of the HAC
2. Authentication and Key Exchange executed between the MN and the
HAC
3. Protection of MN and HA communication
4. AAA Interworking
7.1. Discovery of the HAC
No dynamic procedure for discovering the HAC by the MN is described
in this document. As such, any security aspects relevant to the
discovery procedure is outside the scope.
This document assumes that the HTTPS URL of the HAC is available
based on preconfiguration before the start of the protocol.
Korhonen, et al. Expires January 14, 2010 [Page 18]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
7.2. Authentication and Key Exchange executed between the MN and the
HAC
This document re-uses Transport Layer Security to protect HTTP and is
thereby able to re-use Web security techniques.
Authentication: Server-side certificate based authentication MUST
using TLS 1.2 [RFC5246]. No ciphersuite is mandatory to implement
but it is RECOMMENDED to support 'TLS_RSA_WITH_AES_128_CBC_SHA'.
Client-side authentication may depend on the specific deployment
and is therefore not mandated. Examples of possible choices are
client-side certificate based authentication, usage of TLS-PSK
[RFC4279], and HTTP digest authentication [RFC2617], etc.
Dictionary Attacks: The chosen client-side authentication technique
determines the possibility for dictionary attacks. Depending on
the deployment environment an assessment of the the chosen client
authentication technique has to take place.
Replay Protection: TLS provides protection against replays.
Key Derivation and Key Strength: The key derivation technique as
well the strength of the key depend on the negotiated TLS
ciphersuite.
Key Control: For TLS key control depends on the chosen ciphersuite.
Lifetime: The HTTPS exchange between the MN and the HAC is only to
bootstrap keys and other parameters for usage with MN-HA security.
The usage of Transport Layer Security (TLS) Session Resumption
without Server-Side State, described in [RFC5077], provides the
ability for the MN to minimize the latency of future exchanges
towards the HA without having to keep state at the HA itself.
Denial of Service Resistance: The resistance against denial of
service attack can be compared with the resistance of an ordinary
HTTPS server.
Session Independence: Each individual TLS protocol run is
independent from any previous exchange based on the security
properties of the TLS handshake protocol.
Fragmentation: HTTPS runs on top of TCP and hence there are no
concerns regarding fragmentation.
Channel Binding: Channel binding is not provided by this protocol.
Fast Reconnect: This protocol provides session resumption as part of
TLS and optionally the support for [RFC5077]. Since the protocol
between the MN and the HAC is executed only to establish the
security parameters for usage for the actual MN-HA interaction
fast reconnect is not an important feature.
Identity Protection: This protocol provides active and passive user
identity confidentiality when the proper user authentication
procedure and TLS ciphersuites are chosen.
Korhonen, et al. Expires January 14, 2010 [Page 19]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Protected Ciphersuite Negotiation: This protocol provides
ciphersuite negotiation based on TLS.
Confidentiality: Confidentiality protection of payloads exchanged
between the MN and the HAC are protected with the TLS Record
Layer. It is assumed that a TLS ciphersuite with confidentiality
and integrity protection is negotiated in order to exchange
security sensitive material inside HTTP.
Cryptographic Binding: No cryptographic bindings are provided by
this protocol specified in this document.
Perfect Forward Secrecy: Perfect forward secrecy is provided with
appropriate TLS ciphersuites.
Key confirmation: Key confirmation of the keys established with TLS
is provided by the TLS Record Layer when the keys are used to
protect the subsequent HTTP exchange.
7.3. Protection of MN and HA Communication
Authentication: Data origin authentication is provided for the
communication between the MN and the HA. The chosen level of
security of this authentication depends on the selected
ciphersuite. Entity authentication is offered by the MN to HAC
protocol exchange.
Dictionary Attacks: The concept of dictionary attacks is not
applicable to the MN-HA communication as the keying material used
for this communication is randomly created by the HAC and its
length depends on the chosen cryptographic algorithms.
Replay Protection: Replay protection for the communication between
the MN and the HA is provided based on sequence numbers and
follows the design of IPsec ESP.
Key Derivation and Key Strength: The strength of the keying material
established for the communication between the MN and the HA is
selected based on the negotiated ciphersuite (based on the MN-HAC
exchange) and the key created by the HAC. The randomness
requirements for security described in RFC 4086 [RFC4086] are
applicable to the key generation by the HAC.
Key Control: The keying material established during the MN-HAC
protocol exchange for subsequent protection of the MN-HA
communication is created by the HA and therefore no joint key
control is provided for it.
Key Naming: For the MN-HA communication the security associations
are indexed with the help of the SPI and additionally based on the
direction (in-bound communication or out-bound communication).
Lifetime: The lifetime of the MN-HA security associations is based
on the value in the mip6-sa-validity-end HTTP header field
exchanged during the MN-HAC exchange. The HAC controls the SA
lifetime.
Korhonen, et al. Expires January 14, 2010 [Page 20]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Denial of Service Resistance: For the communication between the MN
and the HA there are no heavy cryptographic operations (such as
public key computations). As such, there are no DoS concerns.
Session Independence: Sessions are independent from each other when
new keys are created by via the MN-HAC protocol. A new MN-HAC
protocol run produces fresh and unique keying material for
protection of the MN-HA communication.
Fragmentation: There is no additional fragmentation support provided
beyond what is offered by the network layer.
Channel Binding: Channel binding is not applicable to the MN-HA
communication.
Fast Reconnect: The concept of fast reconnect is not applicable to
the MN-HA communication.
Identity Protection: User identities SHOULD NOT be exchanged between
the MN and the HA. In a case binding management messages contain
the user identity, the messages SHOULD be confidentially
protected.
Protected Ciphersuite Negotiation: This protocol provides
ciphersuite negotiation based on TLS.
Confidentiality: Confidentiality protection of payloads exchanged
between the MN and the HAC (for Mobile IPv6 signaling and
optionally for the data traffic) is provided with the help of the
ESP utilizing algorithms negotiated during the MN-HAC exchange.
Cryptographic Binding: No cryptographic bindings are provided by
this protocol specified in this document.
Perfect Forward Secrecy: Perfect forward secrecy is provided when
the MN bootstraps new keying material with the help of the MN-HAC
protocol (assuming that a proper TLS ciphersuite is used).
Key confirmation: Key confirmation of the MN-HA keying material
conveyed from the HAC to the MN is provided when the first packets
are exchanged between the MN and the HA (in both directions as two
different keys are used).
7.4. AAA Interworking
The AAA backend infrastructure interworking is not defined in this
document and therefore out-of-scope.
8. Acknowledgements
The authors would like to thank Pasi Eronen, Domagoj Premec, and
Christian Bauer for their comments.
9. References
Korhonen, et al. Expires January 14, 2010 [Page 21]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
9.2. Informative References
[I-D.patil-mext-mip6issueswithipsec]
Patil, B., Premec, D., Perkins, C., and H. Tschofenig,
"Problems with the use of IPsec as the security protocol
for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-01
(work in progress), July 2009.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Korhonen, et al. Expires January 14, 2010 [Page 22]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
Korhonen, et al. Expires January 14, 2010 [Page 23]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Authors' Addresses
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
Espoo FIN-02600
Finland
Email: jouni.nospam@gmail.com
Basavaraj Patil
Nokia
6021 Connection Drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Korhonen, et al. Expires January 14, 2010 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 07:40:51 |