GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6618

Internet Engineering Task Force (IETF) J. Korhonen, Ed. Request for Comments: 6618 Nokia Siemens Networks Category: Experimental B. Patil ISSN: 2070-1721 Nokia

                                                         H. Tschofenig
                                                Nokia Siemens Networks
                                                        D. Kroeselberg
                                                               Siemens
                                                              May 2012
   Mobile IPv6 Security Framework Using Transport Layer Security
      for Communication between the Mobile Node and Home Agent

Abstract

 Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent
 (HA) is secured using IPsec.  The security association (SA) between
 an MN and the HA is established using Internet Key Exchange Protocol
 (IKE) version 1 or 2.  The security model specified for Mobile IPv6,
 which relies on IKE/IPsec, requires interaction between the Mobile
 IPv6 protocol component and the IKE/IPsec module of the IP stack.
 This document proposes an alternate security framework for Mobile
 IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer
 Security for establishing keying material and other bootstrapping
 parameters required to protect Mobile IPv6 signaling and data traffic
 between the MN and HA.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6618.

Korhonen, et al. Experimental [Page 1] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

Copyright Notice

 Copyright (c) 2012 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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
 2. Terminology and Abbreviations ...................................4
 3. Background ......................................................5
 4. TLS-Based Security Establishment ................................5
    4.1. Overview ...................................................5
    4.2. Architecture ...............................................7
    4.3. Security Association Management ............................7
    4.4. Bootstrapping of Additional Mobile IPv6 Parameters .........9
    4.5. Protecting Traffic between Mobile Node and Home Agent .....10
 5. MN-to-HAC Communication ........................................10
    5.1. Request-Response Message Framing over TLS-Tunnel ..........10
    5.2. Request-Response Message Content Encoding .................11
    5.3. Request-Response Message Exchange .........................12
    5.4. Home Agent Controller Discovery ...........................13
    5.5. Generic Request-Response Parameters .......................13
         5.5.1. Mobile Node Identifier .............................13
         5.5.2. Authentication Method ..............................13
         5.5.3. Extensible Authentication Protocol Payload .........14
         5.5.4. Status Code ........................................14
         5.5.5. Message Authenticator ..............................14
         5.5.6. Retry After ........................................14
         5.5.7. End of Message Content .............................14
         5.5.8. Random Values ......................................15
    5.6. Security Association Configuration Parameters .............15
         5.6.1. Security Parameter Index ...........................15
         5.6.2. MN-HA Shared Keys ..................................16
         5.6.3. Security Association Validity Time .................16
         5.6.4. Security Association Scope (SAS) ...................16
         5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping ..17
    5.7. Mobile IPv6 Bootstrapping Parameters ......................18
         5.7.1. Home Agent Address .................................18

Korhonen, et al. Experimental [Page 2] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

         5.7.2. Mobile IPv6 Service Port Number ....................18
         5.7.3. Home Addresses and Home Network Prefix .............18
         5.7.4. DNS Server .........................................19
    5.8. Authentication of the Mobile Node .........................19
    5.9. Extensible Authentication Protocol Methods ................22
 6. Mobile Node to Home Agent Communication ........................23
    6.1. General ...................................................23
    6.2. PType and Security Parameter Index ........................25
    6.3. Binding Management Message Formats ........................25
    6.4. Reverse-Tunneled User Data Packet Formats .................27
 7. Route Optimization .............................................29
 8. IANA Considerations ............................................29
    8.1. New Registry: Packet Type .................................29
    8.2. Status Codes ..............................................29
    8.3. Port Numbers ..............................................29
 9. Security Considerations ........................................30
    9.1. Discovery of the HAC ......................................30
    9.2. Authentication and Key Exchange Executed between
         the MN and the HAC ........................................30
    9.3. Protection of MN and HA Communication .....................33
    9.4. AAA Interworking ..........................................35
 10. Acknowledgements ..............................................35
 11. References ....................................................35
    11.1. Normative References .....................................35
    11.2. Informative References ...................................36

1. Introduction

 Mobile IPv6 (MIPv6) [RFC6275] signaling, and optionally user traffic,
 between a Mobile Node (MN) and Home Agent (HA) are 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 and the IKE(v2)/
 IPsec part of the IP stack.  Client implementation experience has
 shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly
 complex.
 This document proposes an alternate security framework for Mobile
 IPv6 and Dual-Stack Mobile IPv6.  The objective is to simplify
 implementations as well as make it easy to deploy the protocol
 without compromising on security.  Transport Layer Security (TLS)
 [RFC5246] is widely implemented in almost all major operating systems
 and extensively used by various applications.  Instead of using IKEv2
 to establish security associations, the security framework proposed
 in this document is based on TLS-protected messages to exchange keys
 and bootstrapping parameters between the MN and a new functional
 entity called the "Home Agent Controller" (HAC).  The Mobile IPv6
 signaling between the mobile node and home agent is subsequently

Korhonen, et al. Experimental [Page 3] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 secured using the resulting keys and negotiated ciphersuite.  The HAC
 can be co-located with the HA, or it can be an independent entity.
 For the latter case, communication between the HAC and HA is not
 defined by this document.  Such communication could be built on top
 of AAA protocols such as Diameter.
 The primary advantage of using TLS for the establishment of Mobile
 IPv6 security associations as compared to the use of IKEv2 is the
 ease of implementation (especially on the mobile nodes) while
 providing an equivalent level of security.  A solution which
 decouples Mobile IPv6 security from IPsec, for securing signaling
 messages and user plane traffic, is proposed herein that reduces
 client implementation complexity.
 The security framework proposed in this document is not intended to
 replace the currently specified architecture that relies on IPsec and
 IKEv2.  It provides an alternative solution that is more optimal for
 certain deployment scenarios.  This and other alternative security
 models have been considered by the MEXT working group at the IETF,
 and it has been decided that the alternative solutions should be
 published as Experimental RFCs, so that more implementation and
 deployment experience with these models can be gathered.  The status
 of this proposal may be reconsidered in the future if it becomes
 clear that it is superior to others.

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
    Mobile IPv6 security associations between a mobile node and one or
    more home agents.  The home agent controller also provides key
    distribution to both mobile nodes and home agents.  Mobile IPv6
    bootstrapping is also performed by the HA in addition to the
    security association bootstrapping between the mobile node and
    home agent controller.
 Binding Management Messages:
    Mobile IPv6 signaling messages between a mobile node and a home
    agent, correspondent node, or mobility access point to manage the
    bindings are referred to as binding management messages.  Binding
    Updates (BUs) and Binding Acknowledgement (BA) messages are
    examples of binding management messages.

Korhonen, et al. Experimental [Page 4] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

3. Background

 Mobile IPv6 design and specification began in the mid-to-late 90s.
 The security architecture of Mobile IPv6 was based on the
 understanding that IPsec is an inherent and integral part of the IPv6
 stack and any protocol that needs security should use IPsec unless
 there is a good reason not to.  As a result of this mindset, the
 Mobile IP6 protocol relied on the use of IPsec for security between
 the MN and HA.  Reusing security components that are an integral part
 of the IP stack is a good design objective for any protocol; however,
 in the case of Mobile IPv6, it increases implementation complexity.
 It should be noted that Mobile IPv4 [RFC5944], for example, does not
 use IPsec for security and instead has specified its own security
 solution.  Mobile IPv4 has been implemented and deployed on a
 reasonably large scale and the security model has proven itself to be
 sound.
 Mobile IPv6 standardization was completed in 2005 along with the
 security architecture using IKE/IPsec specified in RFC 3776
 [RFC3776].  With the evolution to IKEv2 [RFC5996], Mobile IPv6
 security has also been updated to rely on the use of IKEv2 [RFC4877].
 Implementation exercises of Mobile IPv6 and Dual-Stack Mobile IPv6
 [RFC5555] have identified the complexity of using IPsec and IKEv2 in
 conjunction with Mobile IPv6.  Implementing Mobile IPv6 with IPsec
 and IKEv2 requires modifications to both the IPsec and IKEv2
 components, due to the communication models that Mobile IPv6 uses and
 the changing IP addresses.  For further details, see Section 7.1 in
 [RFC3776].
 This document proposes a security framework based on TLS-protected
 establishment of Mobile IPv6 security associations, which reduces
 implementation complexity while maintaining an equivalent (to IKEv2/
 IPsec) level of security.

4. TLS-Based Security Establishment

4.1. Overview

 The security architecture proposed in this document relies on a
 secure TLS session established between the MN and the HAC for mutual
 authentication and MN-HA security association bootstrapping.
 Authentication of the HAC is done via standard TLS operation wherein
 the HAC uses a TLS server certificate as its credentials.  MN
 authentication is done by the HAC via signaling messages that are
 secured by the TLS connection.  Any Extensible Authentication
 Protocol (EAP) method or Pre-Shared Key (PSK) can be used for
 authenticating the MN to the HAC.  Upon successful completion of
 authentication, the HAC generates keys that are delivered to the MN

Korhonen, et al. Experimental [Page 5] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 through the secure TLS channel.  The same keys are also provided to
 the assigned HA.  The HAC also provides the MN with MIPv6
 bootstrapping information such as the IPv6 and IPv4 address of the
 HA, the home network prefix, the IPv6 and/or IPv4 Home Address (HoA),
 and DNS server address.
 The MN and HA use security associations based on the keys and
 Security Parameter Indexes (SPIs) generated by the HAC and delivered
 to the MN and HA to secure signaling and optionally user plane
 traffic.  Figure 1 below is an illustration of the process.
 Signaling messages and user plane traffic between the MN and HA are
 always UDP encapsulated.  The packet formats for the signaling and
 user plane traffic is described in Sections 6.3 and 6.4.
 MN                            HAC                 HA
 --                            ---                 --
  |                             |                   |
  | /-------------------------\ |                   |
  |/                           \|                   |
  |\    TLS session setup      /|                   |
  | \-------------------------/ |                   |
  |                             |                   |
  | /-------------------------\ |                   |
  |/     MN Authentication     \|                   |
  |\                           /|                   |
  | \-------------------------/ |                   |
  |                             |                   |
  | /-------------------------\ |                   |
  |/   HAC provisions the MN   \|                   |
  |\  keys, SPI, & MIPv6 parms /|                   |
  | \-------------------------/ |                   |
  |                             |--MNID, keys, SPI->|
  |                             |                   |
  | /--------------------------------------------\  |
  |/     MN-HA SA established; Secures            \ |
  |\     signaling and optionally user traffic    / |
  | \--------------------------------------------/  |
  |                                                 |
  |------------BU(encrypted)----------------------->|
  |                                                 |
  |<---------BAck(encrypted)------------------------|
                   Figure 1: High-Level Architecture

Korhonen, et al. Experimental [Page 6] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

4.2. Architecture

 The TLS-based security architecture is shown in Figure 2.  The
 signaling message exchange between the MN and the HAC is protected by
 TLS.  It should be noted that an HAC, a AAA server, and an HA are
 logically separate entities and can be collocated in all possible
 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.
 +------+             +------+            +------+
 |Mobile|     TLS     |Home  |    AAA     | AAA  |
 | Node |<----------->|Agent |<---------->|Server|
 |      |             |Contrl|            |      |
 +------+             +------+            +------+
    ^                     ^                   ^
    |                     |                   |
    | BU/BA/../           | e.g., AAA         | AAA
    | (Data)              |                   |
    |                     v                   |
    |                +---------+              |
    |                | MIPv6   |              |
    +--------------->| Home    |<-------------+
                     | Agent(s)|
                     +---------+
          Figure 2: TLS-Based Security Architecture Overview

4.3. Security Association Management

 Once the MN has contacted the HAC and mutual authentication has taken
 place between the MN and the HAC, the HAC securely provisions the MN
 with all security-related information inside the TLS protected
 tunnel.  This security-related information constitutes a security
 association (SA) between the MN and the HA.  The created SA MUST NOT
 be tied to the Care-of Address (CoA) of the MN.
 The HAC may proactively distribute the SA information to HAs, or the
 HA may query the SA information from the HAC once the MN contacts the
 HA.  If the HA requests SA information from the HAC, then the HA MUST
 be able to query/index the SA information from the HAC based on the
 SPI identifying the correct security association between the MN and
 the HA.

Korhonen, et al. Experimental [Page 7] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 The HA may want the MN to re-establish the SA even if the existing SA
 is still valid.  The HA can indicate this to the MN using a dedicated
 Status Code in a BA (value set to REINIT_SA_WITH_HAC).  As a result,
 the MN SHOULD contact the HAC prior to the SA timing out, and the HAC
 would provision the MN and HAs with a new SA to be used subsequently.
 The SA established between MN and HAC SHALL contain at least the
 following information:
 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.  The SPI values are
    assigned by the HAC.  The HAC MUST ensure uniqueness of the SPI
    values across all MNs controlled by the HAC.
 MN-HA keys for ciphering:
    A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering
    Mobile IPv6 traffic between the MN and the HA.  The HAC is
    responsible for generating these keys.  The key generation
    algorithm is specific to the HAC implementation.
 MN-HA shared key for integrity protection:
    A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity
    protecting Mobile IPv6 traffic between the MN and the HA.  This
    includes both binding management messages and reverse-tunneled
    user data traffic between the MN and the HA.  The HAC is
    responsible for generating these keys.  The key generation
    algorithm is specific to the HAC implementation.  In the case of
    combined algorithms, a separate integrity protection key is not
    needed and may be omitted, i.e., the encryption keys SHALL be
    used.
 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.

Korhonen, et al. Experimental [Page 8] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 Security association scope:
    This parameter defines whether the security association is applied
    to Mobile IPv6 signaling messages only or to both Mobile IPv6
    signaling messages and data traffic.
 Selected ciphersuite:
    This parameter is the ciphersuite used to protect the traffic
    between the MN and the HA.  This includes both binding management
    messages and reverse-tunneled user data traffic between the MN and
    the HA.  The selected algorithms SHOULD be one of the mutually
    supported ciphersuites of the negotiated TLS version between the
    MN and the HAC.  The HAC is responsible for choosing the mutually
    supported ciphersuite that complies with the policy of the HAC.
    Obviously, the HAs under HAC's management must have at least one
    ciphersuite with the HAC in common and need to be aware of the
    implemented ciphersuites.  The selected ciphersuite is the same
    for both directions (MN -> HA and HA -> MN).
 Sequence numbers:
    A monotonically increasing unsigned sequence number used in all
    protected packets exchanged between the MN and the HA in the same
    direction.  Sequence numbers are maintained per direction, so each
    SA includes two independent sequence numbers (MN -> HA, HA -> MN).
    The initial sequence number for each direction MUST always be set
    to 0 (zero).  Sequence numbers cycle to 0 (zero) when increasing
    beyond their maximum defined value.

4.4. Bootstrapping of Additional Mobile IPv6 Parameters

 When the MN contacts the HAC to distribute the security-related
 information, the HAC may also provision the MN with various MIPv6-
 related bootstrapping information.  Bootstrapping of the following
 information SHOULD at least be possible:
 Home Agent IP Address:
    The IPv6 and IPv4 address of the home agent assigned by the HAC.
 Mobile IPv6 Service Port Number:
    The port number where the HA is listening to UDP [RFC0768]
    packets.

Korhonen, et al. Experimental [Page 9] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 Home Address:
    The IPv6 and/or IPv4 home address assigned to the mobile node by
    the HAC.
 Home Link Prefix:
    Concerns the IPv6 Home link prefix and the associated prefix
    length.
 DNS Server Address:
    The address of a DNS server that can be reached via the HA.  DNS
    queries in certain cases cannot be routed to the DNS servers
    assigned by the access network to which the MN is attached; hence,
    an additional DNS server address that is reachable via the HA
    needs to be configured.
 The MIPv6-related bootstrapping information is delivered from the HAC
 to the MN over the same TLS protected tunnel as the security related
 information.

4.5. Protecting Traffic between Mobile Node and 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 integrity protected
 and SHOULD be confidentially protected.  The reverse-tunneled user
 data traffic SHOULD be equivalently protected.  Generally, the
 requirements stated in [RFC6275] concerning the protection of the
 traffic between the MN and the HA also apply to the mechanisms
 defined by this specification.

5. MN-to-HAC Communication

5.1. Request-Response Message Framing over TLS-Tunnel

 The MN and the HAC communicate with each other using a simple
 lockstep request-response protocol that is run inside the protected
 TLS-tunnel.  A generic message container framing for the request
 messages and for the response messages is defined.  The message
 containers are only meant to be exchanged on top of a connection-
 oriented TLS-layer.  Therefore, the end of message exchange is
 determined by the other end closing the transport connection
 (assuming the "application layer" has also indicated the completion
 of the message exchange).  The peer initiating the TLS connection is

Korhonen, et al. Experimental [Page 10] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 always sending "Requests", and the peer accepting the TLS connection
 is always sending "Responses".  The format of the message container
 is shown in Figure 3.
 All data inside the Content portion of the message container MUST be
 encoded using octets.  Fragmentation of message containers is not
 supported, which means one request or response at the "application
 layer" MUST NOT exceed the maximum size allowed by the message
 container format.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Ver |  Rsrvd  | Identifier    | Length                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Content portion..                                             ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 3: Request-Response Message Container
 The 3-bit Ver field identifies the protocol version.  The current
 version is 0, i.e., all bits are set to a value of 0 (zero).
 The Rsrvd field MUST be set to a value of 0 (zero),
 The Identifier field is meant to match requests and responses.  The
 valid Identifier values are between 1-255.  The value 0 MUST NOT be
 used.  The first request for each communication session between the
 MN and the HAC MUST have the Identifier values set to 1.
 The Length field tells the length of the Content portion of the
 container (i.e., Reserved octet, Identifier octet, and Length field
 are excluded).  The Content portion length MUST always be at least
 one octet and up to 65535 octets.  The value is in network order.

5.2. Request-Response Message Content Encoding

 The encoding of the message content is similar to HTTP header
 encoding and complies with the augmented Backus-Naur Form (BNF)
 defined in Section 2.1 of [RFC2616].  All presented hexadecimal
 numbers are in network byte order.  From now on, we use the TypeValue
 header (TV-header) term to refer to request-response message content
 HTTP-like headers.

Korhonen, et al. Experimental [Page 11] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

5.3. Request-Response Message Exchange

 The message exchange between the MN and the HAC is a simple lockstep
 request-response type as stated in Section 5.1.  A request message
 includes a monotonically increasing Identifier value that is copied
 to the corresponding response message.  Each request MUST have a
 different Identifier value.  Hence, a reliable connection-oriented
 transport below the message container framing is assumed.  The number
 of request-response message exchanges MUST NOT exceed 255.
 Each new communication session between the MN and the HAC MUST reset
 the Identifier value to 1.  The MN is also the peer that always sends
 only request messages and the HAC only sends response messages.  Once
 the request-response message exchange completes, the HAC and the MN
 MUST close the transport connection and the corresponding TLS-tunnel.
 In the case of an HAC-side error, the HAC MUST send a response back
 to an MN with an appropriate status code and then close the transport
 connection.
 The first request message - MHAuth-Init - (i.e., the Identifier is 1)
 MUST always contain at least the following parameters:
    MN-Identity - See Section 5.5.1.
    Authentication Method - See Section 5.5.2.
 The first response message - MHAuth-Init - (i.e., the Identifier is
 1) MUST contain at minimum the following parameters:
    Selected authentication Method - See Section 5.5.2.
 The last request message from the MN side - MHAuth-Done - MUST
 contain the following parameters:
    Security association scope - See Section 5.6.4.
    Proposed ciphersuites - See Section 5.6.5.
    Message Authenticator - See Section 5.5.5.
 The last response message - MHAuth-Done - that ends the request-
 response message exchange MUST contain the following parameters:
    Status Code - See Section 5.5.4.
    Message Authenticator - See Section 5.5.5.

Korhonen, et al. Experimental [Page 12] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 In the case of successful authentication, the following additional
 parameters:
    Selected ciphersuite - See Section 5.6.5.
    Security association scope - See Section 5.6.4.
    The rest of the security association data - See Section 5.6.

5.4. Home Agent Controller Discovery

 All bootstrapping information, whether for setting up the SA or for
 bootstrapping MIPv6-specific information, is exchanged between the MN
 and the HAC using the framing protocol defined in Section 5.1.  The
 IP address of the HAC MAY be statically configured in the MN or
 alternatively MAY be dynamically discovered using DNS.  In the case
 of DNS-based HAC discovery, the MN queries either an A/AAAA or a SRV
 record for the HAC IP address.  The actual domain name used in
 queries is up to the deployment to decide and out of scope of this
 specification.

5.5. Generic Request-Response Parameters

 The grammar used in the following sections is the augmented Backus-
 Naur Form (BNF), the same as that used by HTTP [RFC2616].

5.5.1. Mobile Node Identifier

 An identifier that identifies an MN.  The Mobile Node Identifier is
 in the form of a Network Access Identifier (NAI) [RFC4282].
    mn-id = "mn-id" ":" RFC4282-NAI CRLF

5.5.2. Authentication Method

 The HAC is the peer that mandates the authentication method.  The MN
 sends its authentication method proposal to the HAC.  The HAC, upon
 receipt of the MN proposal, returns the selected authentication
 method.  The MN MUST propose at least one authentication method.  The
 HAC MUST select exactly one authentication method or return an error
 and then close the connection.
    auth-method = "auth-method" ":" a-method *("," a-method) CRLF
    a-method =
         "psk" ; PSK-based authentication
       | "eap" ; EAP-based authentication

Korhonen, et al. Experimental [Page 13] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

5.5.3. Extensible Authentication Protocol Payload

 Each Extensible Authentication Protocol (EAP) [RFC3748] message is an
 encoded string of hexadecimal numbers.  The "eap-payload" is
 completely transparent as to which EAP-method or EAP message is
 carried inside it.  The "eap-payload" can appear in both request and
 response messages:
    eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF

5.5.4. Status Code

 The "status-code" MUST only be present in the response message that
 ends the request-response message exchange.  The "status-code"
 follows the principles of HTTP and the definitions found in Section
 10 of RFC 2616 also apply for these status codes listed below:
    status-code = "status-code" ":" status-value CRLF
    status-value =
         "100" ; Continue
       | "200" ; OK
       | "400" ; Bad Request
       | "401" ; Unauthorized
       | "500" ; Internal Server Error
       | "501" ; Not Implemented
       | "503" ; Service Unavailable
       | "504" ; Gateway Time-out

5.5.5. Message Authenticator

 The "auth" header contains data used for authentication purposes.  It
 MUST be the last TV-header in the message and calculated over the
 whole message till the start of the "msg-header":
    msg-auth = "auth" ":" 1*(HEX HEX) CRLF

5.5.6. Retry After

    retry-after = "retry-after" ":" rfc1123-date CRLF

5.5.7. End of Message Content

    end-of-message = 2CRLF

Korhonen, et al. Experimental [Page 14] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

5.5.8. Random Values

 Random numbers generated by the MN and the HAC, respectively.  The
 length of the random number MUST be 32 octets (before TV-header
 encoding):
    mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF
    hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF

5.6. Security Association Configuration 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 allowed ciphersuites for this specification are a subset of
 those in TLS version 1.2 (see Appendix A.5 of [RFC5246]) per
 Section 5.6.5.  This might appear as a constraint as the HA and the
 HAC may have implemented different ciphersuites.  These two nodes
 are, however, assumed to belong to the same administrative domain.
 In order to avoid exchanging supported MN-HA ciphersuites in the MN-
 HAC protocol and to reuse the TLS ciphersuite negotiation procedure,
 we make this simplifying assumption.  The selected ciphersuite MUST
 provide integrity and confidentiality protection.
 Section 5.6.5 provides the mapping from the TLS ciphersuites to the
 integrity and encryption algorithms allowed for MN-HA protection.
 This mapping mainly ignores the authentication algorithm part that is
 not required within the context of this specification.  For example,
 [RFC5246] defines a number of AES-based ciphersuites for TLS
 including 'TLS_RSA_WITH_AES_128_CBC_SHA'.  For this specification,
 the relevant part is 'AES_128_CBC_SHA'.
 All the parameters described in the following sections apply only to
 a request-response protocol response message to the MN.  The MN has
 no way of affecting the provisioning decision of the HAC.

5.6.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 TV-header corresponding to the SPI number is as follows:
    mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF

Korhonen, et al. Experimental [Page 15] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

5.6.2. MN-HA Shared Keys

 The MN-HA shared integrity (ikey) and encryption (ekey) keys are used
 to protect the traffic between the MN and the HA.  The length of
 these keys depend on the selected ciphersuite.
 The TV-headers that carry these two parameters are the following:
    mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF
    mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF
    mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF
    mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF

5.6.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 TV-header corresponding to the SA validity time value is as
 follows:
 mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date CRLF

5.6.4. Security Association Scope (SAS)

 The SA is applied either to Mobile IPv6 signaling messages only or to
 both Mobile IPv6 signaling messages and data traffic.  This policy
 MUST be agreed between the MN and HA prior to using the SA.
 Otherwise, the receiving side will be unaware of whether the SA
 applies to data traffic and hence unable to decide how to act when
 receiving unprotected packets of PType 1 (see Section 6.4).
    mip6-sas = "mip6-sas" ":" 1DIGIT CRLF
 where a value of "O" indicates that the SA does not protect data
 traffic and a value of "1" indicates that all data traffic MUST be
 protected by the SA.  If the mip6-sas value of an SA is set to 1, any
 packet received with a PType value that does not match the mip6-sas
 value of the SA MUST be silently discarded.
 The HAC is the peer that mandates the used security association
 scope.  The MN sends its proposal to the HAC, but eventually the
 security association scope returned from the HAC defines the used
 scope.

Korhonen, et al. Experimental [Page 16] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping

 The ciphersuite negotiation between HAC and MN uses a subset of the
 TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation
 defined in Appendix A.5 of [RFC5246].  The TV-headers corresponding
 to the selected ciphersuite and ciphersuite list are the following:
    mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
    csuite = "{" suite "}"
    suite =
         "00" "," "02" ; CipherSuite NULL_SHA           = {0x00,0x02}
       | "00" "," "3B" ; CipherSuite NULL_SHA256        = {0x00,0x3B}
       | "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA   = {0x00,0x0A}
       | "00" "," "2F" ; CipherSuite AES_128_CBC_SHA    = {0x00,0x2F}
       | "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C}
    mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF
 All other Ciphersuite values are reserved.
 The following integrity algorithms MUST be supported by all
 implementations:
    HMAC-SHA1-96                    [RFC2404]
    AES-XCBC-MAC-96                 [RFC3566]
 The binding management messages between the MN and HA MUST be
 integrity protected.  Implementations MUST NOT use a NULL integrity
 algorithm.
 The following encryption algorithms MUST be supported:
    NULL                            [RFC2410]
    TripleDES-CBC                   [RFC2451]
    AES-CBC with 128-bit keys       [RFC3602]
 Traffic between MN and HA MAY be encrypted.  Any integrity-only
 Ciphersuite makes use of the NULL encryption algorithm.
 Note: This document does not consider combined algorithms.  The
 following table provides the mapping of each ciphersuite to a
 combination of integrity and encryption algorithms that are part of
 the negotiated SA between MN and HA.

Korhonen, et al. Experimental [Page 17] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 +-------------------+-----------------+--------------------------+
 |Ciphersuite        |Integ. Algorithm |Encr. Algorithm           |
 +-------------------+-----------------+--------------------------+
 |NULL_SHA           |HMAC-SHA1-96     |NULL                      |
 |NULL_SHA256        |AES-XCBC-MAC-96  |NULL                      |
 |3DES_EDE_CBC_SHA   |HMAC-SHA1-96     |TripleDES-CBC             |
 |AES_128_CBC_SHA    |HMAC-SHA1-96     |AES-CBC with 128-bit keys |
 |AES_128_CBC_SHA256 |AES-XCBC-MAC-96  |AES-CBC with 128-bit keys |
 +-------------------+----------------+---------------------------+
                   Ciphersuite-to-Algorithm Mapping

5.7. Mobile IPv6 Bootstrapping Parameters

 In parallel with the SA bootstrapping, the HAC SHOULD provision the
 MN with relevant MIPv6-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 CRLF
    word       = 1*4HEX
    ip6-prefix = ip6-addr "/" 1*2DIGIT
    ip4-addr   = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
    ip4-subnet = ip4-addr "/" 1*2DIGIT

5.7.1. Home Agent Address

 The HAC MAY provision the MN with an IPv4 or an IPv6 address of an
 HA, or both.
    mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF
    mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF

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 (mipv6tls) 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
 both.  The HAC MAY also provision the MN with its home network
 prefix.

Korhonen, et al. Experimental [Page 18] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

    mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF
    mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF
    mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF
    mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF

5.7.4. DNS Server

 The HAC may also provide the MN with DNS server configuration
 options.  These DNS servers are reachable via the home agent.
    dns-ip6 = "dns-ip6" ":" ip6-addr CRLF
    dns-ip4 = "dns-ip4" ":" ip4-addr CRLF

5.8. Authentication of the Mobile Node

 This section describes the basic operation required for the MN-HAC
 mutual authentication and the channel binding.  The authentication
 protocol described as part of this section is a simple exchange that
 follows the Generalized Pre-Shared Key (GPSK) exchange used by EAP-
 GPSK [RFC5433].  It is secured by the TLS tunnel and is
 cryptographically bound to the TLS tunnel through channel binding
 based on [RFC5056] and on the channel binding type 'tls-server-
 endpoint' described in [RFC5929].  As a result of the channel binding
 type, this method can only be used with TLS ciphersuites that use
 server certificates and the Certificate handshake message.  For
 example, TLS ciphersuites based on PSK or anonymous authentication
 cannot be used.
 The authentication exchange MUST be performed through the encrypted
 TLS tunnel.  It performs mutual authentication between the MN and the
 HAC based on a PSK or based on an EAP-method (see Section 5.9).  Note
 that an HAC MUST NOT allow MNs to renegotiate TLS sessions.  The PSK
 protocol is described in this section.  It consists of the message
 exchanges (MHAuth-Init, MHAuth-Mid, MHAuth-Done) in which both sides
 exchange nonces and their identities, and compute and exchange a
 message authenticator 'auth' over the previously exchanged values,
 keyed with the pre-shared key.  The MHAuth-Done messages are used to
 deal with error situations.  Key binding with the TLS tunnel is
 ensured by channel binding of the type "tls-server-endpoint" as
 described by [RFC5929] where the hash of the TLS server certificate
 serves as input to the 'auth' calculation of the MHAuth messages.
 Note: The authentication exchange is based on the GPSK exchange used
 by EAP-GPSK.  In comparison to GPSK, it does not support exchanging
 an encrypted container (it always runs through an already protected
 TLS tunnel).  Furthermore, the initial request of the authentication
 exchange (MHAuth-Init) is sent by the MN (client side) and is

Korhonen, et al. Experimental [Page 19] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 comparable to EAP-Response/Identity, which reverses the roles of
 request and response messages compared to EAP-GPSK.  Figure 4 shows a
 successful protocol exchange.
 MN                                                      HAC
  |                                                       |
  | Request/MHAuth-Init (...)                             |
  |------------------------------------------------------>|
  |                                                       |
  |                            Response/MHAuth-Init (...) |
  |<------------------------------------------------------|
  |                                                       |
  | Request/MHAuth-Done (...)                             |
  |------------------------------------------------------>|
  |                                                       |
  |                            Response/MHAuth-Done (...) |
  |<------------------------------------------------------|
  |                                                       |
   Figure 4: Authentication of the Mobile Node Using Shared Secrets
 1)  Request/MHAuth-Init: (MN -> HAC)
        mn-id, mn-rand, auth-method=psk
 2)  Response/MHAuth-Init: (MN <- HAC)
        [mn-rand, hac-rand, auth-method=psk, [status],] auth
 3)  Request/MHAuth-Done: (MN -> HAC)
        mn-rand, hac-rand, sa-scope, ciphersuite-list, auth
 4)  Response/MHAuth-Done: (MN <- HAC)
        [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand,
        hac-rand, status, auth
 Where 'auth' for MN -> HAC direction is as follows:
    auth = HMAC-SHA256(PSK, "MN" | msg-octets | CB-octets)
 Where 'auth' for MN <- HAC direction is as follows:
    auth = HMAC-SHA256(PSK, "HAC" | msg-octets | CB-octets)
 In the above, "MN" is 2 ASCII characters without null termination and
 "HAC" is 3 ASCII characters without null termination.

Korhonen, et al. Experimental [Page 20] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 The length "mn-rand", "hac-rand" is 32 octets.  Note that "|"
 indicates concatenation and optional parameters are shown in square
 brackets [..].  The square brackets can be nested.
 The shared secret PSK can be variable length. 'msg-octets' includes
 all payload parameters of the respective message to be signed except
 the 'auth' payload.  CB-octets is the channel binding input to the
 auth calculation that is the "TLS-server-endpoint" channel binding
 type.  The content and algorithm (only required for the "TLS-server-
 endpoint" type) are the same as described in [RFC5929].
 The MN starts by selecting a random number 'mn-rand' and choosing a
 list of supported authentication methods coded in 'auth-method'.  The
 MN sends its identity 'mn-id', 'mn-rand', and 'auth-method' to the
 HAC in MHAuth-Init.  The decision of which authentication method to
 offer and which to pick is policy and implementation dependent and,
 therefore, outside the scope of this document.
 In MHAuth-Done, the HAC sends a random number 'hac-rand' and the
 selected ciphersuite.  The selection MUST be one of the MN-supported
 ciphersuites as received in 'ciphersuite-list'.  Furthermore, it
 repeats the received parameters of the MHAuth-Init message 'mn-rand'.
 It computes a message authenticator 'auth' over all the transmitted
 parameters except 'auth' itself.  The HAC calculates 'auth' over all
 parameters and appends it to the message.
 The MN verifies the received Message Authentication Code (MAC) and
 the consistency of the identities, nonces, and ciphersuite parameters
 transmitted in MHAuth-Auth.  In case of successful verification, the
 MN computes a MAC over the session parameter and returns it to the
 HAC in MHAuth-Done.  The HAC verifies the received MAC and the
 consistency of the identities, nonces, and ciphersuite parameters
 transmitted in MHAuth-Init.  If the verification is successful,
 MHAuth-Done is prepared and sent by the HAC to confirm successful
 completion of the exchange.

Korhonen, et al. Experimental [Page 21] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

5.9. Extensible Authentication Protocol Methods

 Basic operation required for the MN-HAC mutual authentication using
 EAP-based methods.
 MN                                                      HAC
  |                                                       |
  | Request/MHAuth-Init (...)                             |
  |------------------------------------------------------>|
  |                                                       |
  |                            Response/MHAuth-Init (..., |
  |                     eap-payload=EAP-Request/Identity) |
  |<------------------------------------------------------|
  |                                                       |
  | Request/MHAuth-Mid (eap-payload=                      |
  |              EAP-Response/Identity)                   |
  |------------------------------------------------------>|
  |                                                       |
  |     Response/MHAuth-Mid (eap-payload=EAP-Request/...) |
  |<------------------------------------------------------|
  |                                                       |
  :                                                       :
  :        ..EAP-method specific exchanges..              :
  :                                                       :
  |                                                       |
  | Request/MHAuth-Done (eap-payload=EAP-Response/...,    |
  |                      ..., auth)                       |
  |------------------------------------------------------>|
  |                                                       |
  |        Response/MHAuth-Done (eap-payload=EAP-Success, |
  |                              ..., auth)               |
  |<------------------------------------------------------|
  |                                                       |
         Figure 5: Authentication of the Mobile Node Using EAP
 1)  Request/MHAuth-Init: (MN -> HAC)
        mn-id, mn-rand, auth-method=eap
 2)  Response/MHAuth-Init: (MN <- HAC)
        [auth-method=eap, eap, [status,]] auth
 3)  Request/MHAuth-Mid: (MN -> HAC)
        eap, auth

Korhonen, et al. Experimental [Page 22] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 4)  Response/MHAuth-Mid: (MN <- HAC)
        eap, auth
     MHAuth-Mid exchange is repeated as many times as needed by the
     used EAP-method.
 5)  Request/MHAuth-Done: (MN -> HAC)
        sa-scope, ciphersuite-list, eap, auth
 6)  Response/MHAuth-Done: (MN <- HAC)
        [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap,
        status, auth
 Where 'auth' for MN -> HAC direction is as follows:
    auth = HMAC-SHA256(shared-key, "MN" | msg-octets | CB-octets)
 Where 'auth' for MN <- HAC direction is as follows:
    auth = HMAC-SHA256(shared-key, "HAC" | msg-octets | CB-octets)
 In the above, "MN" is 2 ASCII characters without null termination and
 "HAC" is 3 ASCII characters without null termination.
 In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1".  If
 the EAP-method is key-deriving and creates a shared Master Session
 Key (MSK) as a side effect of Authentication shared-key MUST be the
 MSK in all MHAuth-Done messages.  This MSK MUST NOT be used for any
 other purpose.  In case the EAP method does not generate an MSK,
 shared-key is set to "1".
 'msg-octets' includes all payload parameters of the respective
 message to be signed except the 'auth' payload.  CB-octets is the
 channel binding input to the AUTH calculation that is the "TLS-
 server-endpoint" channel binding type.  The content and algorithm
 (only required for the "TLS-server-endpoint" type) are the same as
 described in [RFC5929].

6. Mobile Node to Home Agent Communication

6.1. General

 The following subsections 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-

Korhonen, et al. Experimental [Page 23] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 tunneled and encrypted user data, and reverse-tunneled plaintext user
 data.  This specification defines a generic packet format, where
 everything is encapsulated inside UDP.  See Sections 6.3 and 6.4 for
 detailed illustrations of the corresponding packet formats.
 The Mobile IPv6 service port number is where the HA expects to
 receive UDP packets.  The same port number is used for both binding
 management messages and user data packets.  The reason for
 multiplexing data and control messages over the same port number is
 due to the possibility of Network Address and Port Translators
 located along the path between the MN and the HA.  The Mobile IPv6
 service MAY use any ephemeral port number as the UDP source port, and
 it MUST use the Mobile IPv6 service port number as the UDP
 destination port.  The Mobile IPv6 service port is 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 (mipv6tls) MUST be used.
 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 plaintext user data packet.
 The Packet Type field is followed by a 28-bit SPI value, which
 identifies the correct SA concerning the encrypted packet.  For any
 packet that is neither integrity protected nor encrypted (i.e., no SA
 is applied by the originator), the SPI MUST be set to 0 (zero).
 Mobility management messages MUST always be at least integrity
 protected.  Hence, mobility management messages MUST NOT be sent with
 an SPI value of 0 (zero).
 There is always only one SPI per MN-HA mobility session and the same
 SPI is used for all types of protected packets independent of the
 direction.
 The SPI value is followed by a 32-bit Sequence Number value that is
 used to identify retransmissions of protected messages (integrity
 protected or both integrity protected and encrypted, see Figures 7
 and 8) .  Each endpoint in the security association maintains two
 "current" Sequence Numbers: the next one to be used for a packet it
 initiates and the next one it expects to see in a packet from the
 other end.  If the MN and the HA ends initiate very different numbers
 of messages, the Sequence Numbers in the two directions can be very
 different.  In the case data protection is not used (see Figure 9),
 the Sequence Number MUST be set to 0 (zero).  Note that the HA SHOULD
 initiate a re-establishment of the SA before any of the Sequence
 Number cycle.

Korhonen, et al. Experimental [Page 24] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 Finally, the Sequence Number field is followed by the data portion,
 whose content is identified by the Packet Type.  The data portion may
 be protected.

6.2. PType and Security Parameter Index

 The PType is a 4-bit field that indicates the Packet Type (PType) of
 the UDP encapsulated packet.  The PType is followed by a 28-bit SPI
 value.  The PType and the SPI fields are treated as one 32-bit field
 during the integrity protection calculation.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | PType |                        SPI                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 6: Security Parameter Index with Packet Type
 A SPI value of 0 (zero) indicates a plaintext packet.  If the packet
 is integrity protected or both integrity protected and encrypted, the
 SPI value MUST be different from 0.  When the SPI value is set to 0,
 then the PType MUST also be 0.

6.3. Binding Management Message Formats

 The binding management messages that are only meant to be exchanged
 between the MN and the HA MUST be integrity protected and MAY be
 encrypted.  They MUST use the packet format shown in Figure 7.
 All packets that are specific to the Mobile IPv6 protocol, contain a
 Mobility Header (as defined in Section 6.1.1. of RFC 6275) and are
 used between the MN and the HA shall use the packet format shown in
 Figure 7.  (This means that some Mobile IPv6 mobility management
 messages, such as the Home Test Init (HoTI) message, are treated as
 data packets and using encapsulation described in Section 6.4 and
 shown in Figures 8 and 9).

Korhonen, et al. Experimental [Page 25] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-

Sequence Number

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | —-

Payload Data (variable)

: : | |

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-

Padding (0-255 bytes)

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |

Pad Length Next Header

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ——

Integrity Check Value-ICV (variable)

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7: UDP-Encapsulated Binding Management Message Format
 The PType value 8 (eight) identifies that the UDP-encapsulated packet
 contains a Mobility Header (defined by RFC 6275) and other relevant
 IPv6 extension headers.  Note, there is no additional IP header
 inside the encapsulated part.  The Next Header field MUST be set to
 value of the first encapsulated header.  The encapsulated headers
 follow the natural IPv6 and Mobile IPv6 extension header alignment
 and formatting rules.
 The Padding, Pad Length, Next Header, and ICV fields follow the rules
 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this
 document.  For an SPI value of 0 (zero) that indicates an unprotected
 packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT
 be present.
 The source and destination IP addresses of the outer IP header (i.e.,
 the src-addr and the dst-addr in Figure 7) use the current CoA of the
 MN and the HA address.

Korhonen, et al. Experimental [Page 26] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

6.4. Reverse-Tunneled User Data Packet Formats

 There are two types of reverse-tunneled user data packets between the
 MN and the HA: those that are integrity protected and/or encrypted
 and those that are sent in the clear.  The MN or the HA decides
 whether to apply integrity protection and/or encryption to a packet
 or to send it in the clear based on the mip6-sas value in the SA.  If
 the mip6-sas is set to 1, the originator MUST NOT send any user data
 packets in the clear, and the receiver MUST silently discard any
 packet with the PType set to 0 (unprotected).  It is RECOMMENDED that
 confidentiality and integrity protection of user data traffic be
 applied.  The reverse-tunneled IPv4 or IPv6 user data packets are
 encapsulated as is inside the 'Payload Data' shown in Figures 8 and
 9.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-

Sequence Number

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | —-

Payload Data (variable)

: : | |

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-

Padding (0-255 bytes)

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |

Pad Length Next Header

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ——

Integrity Check Value-ICV (variable)

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8: UDP-Encapsulated Protected User Data Packet Format

Korhonen, et al. Experimental [Page 27] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 The PType value 1 (one) identifies that the UDP-encapsulated packet
 contains an encrypted-tunneled IPv4/IPv6 user data packet.  The Next
 Header field header MUST be set to value corresponding the tunneled
 IP packet (e.g., 41 for IPv6).
 The Padding, Pad Length, Next Header, and ICV fields follow the rules
 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this
 document.  For an SPI value of 0 (zero) that indicates an unprotected
 packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT
 be present.
 The source and destination IP addresses of the outer IP header (i.e.,
 the src-addr and the dst-addr in Figure 8) use the current CoA of the
 MN and the HA address.  The ESP-protected inner IP header, which is
 not shown in Figure 8, uses the home address of the MN and the
 correspondent node (CN) address.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :         IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya)        :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :            UDP header (src-port=Xp,dst-port=Yp)               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |PType=0|                        0                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                0                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :           Payload Data (plain IPv4 or IPv6 Packet)            :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 9: 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 9) use the current CoA of the
 MN and the HA address.  The plaintext inner IP header uses the home
 address of the MN and the CN address.

Korhonen, et al. Experimental [Page 28] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

7. Route Optimization

 Mobile IPv6 route optimization as described in [RFC6275] is not
 affected by this specification.  Route optimization is possible only
 between an IPv6 MN and CN.  UDP encapsulation of signaling and data
 traffic is only between the MN and HA.  The return routability
 signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are
 treated as data packets and encapsulation, when needed, is per the
 description in Section 6.4 of this specification.  The data packets
 between an MN and CN that have successfully completed the return
 routability test and created the appropriate entries in their binding
 cache are not UDP encapsulated using the packet formats defined in
 this specification but follow the [RFC6275] specification.

8. IANA Considerations

8.1. New Registry: Packet Type

 IANA has created a new registry under the [RFC6275] Mobile IPv6
 parameters registry for the Packet Type as described in Section 6.1.
 Description                       | 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.

8.2. 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 following value is
 reserved in the [RFC6275] Status Codes registry:
     REINIT_SA_WITH_HAC       176

8.3. Port Numbers

 A new port number (mipv6tls) for UDP packets is reserved from the
 existing PORT NUMBERS registry.
     mipv6tls 7872

Korhonen, et al. Experimental [Page 29] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

9. Security Considerations

 This document describes and uses a number of building blocks that
 introduce security mechanisms and need to interwork in a secure
 manner.
 The following building blocks are considered from a security point of
 view:
 1.  Discovery of the HAC
 2.  Authentication and MN-HA SA establishment executed between the MN
     and the HAC (PSK- or EAP-based) through a TLS tunnel
 3.  Protection of MN-HA communication
 4.  AAA interworking

9.1. Discovery of the HAC

 No dynamic procedure for discovering the HAC by the MN is described
 in this document.  As such, no specific security considerations apply
 to the scope of this document.

9.2. Authentication and Key Exchange Executed between the MN and the

    HAC
 This document describes a simple authentication and MN-HA SA
 negotiation exchange over TLS.  The TLS procedures remain unchanged;
 however, channel binding is provided.
 Authentication:  Server-side certificate-based authentication MUST be
    performed using TLS version 1.2 [RFC5246].  The MN MUST verify the
    HAC's TLS server certificate, using either the subjectAltName
    extension [RFC5280] dNSName identities as described in [RFC6125]
    or subjectAltName iPAddress identities.  In case of iPAddress
    identities, the MN MUST check the IP address of the TLS connection
    against these iPAddress identities and SHOULD reject the
    connection if none of the iPAddress identities match the
    connection.  In case of dNSName identities, the rules and
    guidelines defined in [RFC6125] apply here, with the following
    considerations:
  • Support for DNS-ID identifier type (the dNSName identity in the

subjectAltName extension) is REQUIRED in the HAC and the MN TLS

       implementations.

Korhonen, et al. Experimental [Page 30] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

  • DNS names in the HAC server certificates MUST NOT contain the

wildcard character "*".

  • The CN-ID MUST NOT be used for authentication within the rules

described in [RFC6125].

  • The MN MUST set its "reference identifier" to the DNS name of

the HAC.

    The client-side authentication may depend on the specific
    deployment and is therefore not mandated.  Note that TLS-PSK
    [RFC4279] cannot be used in conjunction with the methods described
    in Sections 5.8 and 5.9 of this document due to the limitations of
    the channel binding type used.
    Through the protected TLS tunnel, an additional authentication
    exchange is performed that provides client-side or mutual
    authentication and exchanges SA parameters and optional
    configuration data to be used in the subsequent protection of
    MN-HA communication.  The additional authentication exchange can
    be either PSK-based (Section 5.8) or EAP-based (Section 5.9).
    Both exchanges are always performed within the protected TLS
    tunnel and MUST NOT be used as standalone protocols.
    The simple PSK-based authentication exchange provides mutual
    authentication and follows the GPSK exchange used by EAP-GPSK
    [RFC5433] and has similar properties, although some features of
    GPSK like the exchange of a protected container are not supported.
    The EAP-based authentication exchange simply defines message
    containers to allow carrying the EAP packets between the MN and
    the HAC.  In principle, any EAP method can be used.  However, it
    is strongly recommended to use only EAP methods that provide
    mutual authentication and that derive keys including an MSK in
    compliance with [RFC3748].
    Both exchanges use channel binding with the TLS tunnel.  The
    channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be
    used.
 Dictionary Attacks:  All messages of the authentication exchanges
    specified in this document are protected by TLS.  However, any
    implementation SHOULD assume that the properties of the
    authentication exchange are the same as for GPSK [RFC5433], in
    case the PSK-based method per Section 5.8 is used, and are the
    same as those of the underlying EAP method, in case the EAP-based
    exchange per Section 5.9 is used.

Korhonen, et al. Experimental [Page 31] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 Replay Protection:  The underlying TLS protection provides protection
    against replays.
 Key Derivation and Key Strength:  For TLS, the TLS-specific
    considerations apply unchanged.  For the authentication exchanges
    defined in this document, no key derivation step is performed as
    the MN-HA keys are generated by the HAC and are distributed to the
    MN through the secure TLS connection.
 Key Control:  No joint key control for MN-HA keys is provided by this
    version of the specification.
 Lifetime:  The TLS-protected authentication exchange between the MN
    and the HAC is only to bootstrap keys and other parameters for
    usage with MN-HA security.  The SAs that contain the keys have an
    associated lifetime.  The usage of Transport Layer Security (TLS)
    Session Resumption without Server-Side State, described in
    [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 (DoS) Resistance:  The level of resistance against
    DoS attacks SHOULD be considered the same as for common TLS
    operation, as TLS is used unchanged.  For the PSK-based
    authentication exchange, no additional factors are known.  For the
    EAP-based authentication exchange, any considerations regarding
    DoS resistance specific to the chosen EAP method are expected to
    be applicable and need to be taken into account.
 Session Independence:  Each individual TLS protocol run is
    independent from any previous exchange based on the security
    properties of the TLS handshake protocol.  However, several PSK-
    or EAP-based authentication exchanges can be performed across the
    same TLS connection.
 Fragmentation:  TLS runs on top of TCP and no fragmentation-specific
    considerations apply to the MN-HAC authentication exchanges.
 Channel Binding:  Both the PSK and the EAP-based exchanges use
    channel binding with the TLS tunnel.  The channel binding type
    'TLS-server-endpoint' per [RFC5929] MUST be used.
 Fast Reconnect:  This protocol provides session resumption as part of
    TLS and optionally the support for [RFC5077].  No fast reconnect
    is supported for the PSK-based authentication exchange.  For the
    EAP-based authentication exchange, availability of fast reconnect
    depends on the EAP method used.

Korhonen, et al. Experimental [Page 32] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 Identity Protection:  Based on the security properties of the TLS
    tunnel, passive user identity protection is provided.  An attacker
    acting as man-in-the-middle in the TLS connection would be able to
    observe the MN identity value sent in MHAuth-Init messages.
 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.  TLS ciphersuites with confidentiality and integrity
    protection MUST be negotiated and used in order to exchange
    security sensitive material inside the TLS connection.
 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 TLS exchange.

9.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 [RFC4086] are applicable to
    the key generation by the HAC.

Korhonen, et al. Experimental [Page 33] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 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 (inbound communication or outbound communication).
 Lifetime:  The lifetime of the MN-HA security associations is based
    on the value in the mip6-sa-validity-end header field exchanged
    during the MN-HAC exchange.  The HAC controls the SA lifetime.
 DoS 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 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 the case where binding management messages
    contain the user identity, the messages SHOULD be confidentiality
    protected.
 Protected Ciphersuite Negotiation:  The MN-HAC protocol provides
    protected ciphersuite negotiation through a secure TLS connection.
 Confidentiality:  Confidentiality protection of payloads exchanged
    between the MN and the HAC (for Mobile IPv6 signaling and
    optionally for the data traffic) is provided utilizing algorithms
    negotiated during the MN-HAC exchange.
 Cryptographic Binding:  No cryptographic bindings are provided by
    this protocol specified in this document.

Korhonen, et al. Experimental [Page 34] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 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).

9.4. AAA Interworking

 The AAA backend infrastructure interworking is not defined in this
 document and is therefore out of scope.

10. Acknowledgements

 The authors would like to thank Pasi Eronen, Domagoj Premec, Julien
 Laganier, Jari Arkko, Stephen Farrell, Peter Saint-Andre and
 Christian Bauer for their comments.

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
            ESP and AH", RFC 2404, November 1998.
 [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
            Its Use With IPsec", RFC 2410, November 1998.
 [RFC2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
            Algorithms", RFC 2451, November 1998.
 [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.
 [RFC3566]  Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
            and Its Use With IPsec", RFC 3566, September 2003.
 [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
            Algorithm and Its Use with IPsec", RFC 3602,
            September 2003.

Korhonen, et al. Experimental [Page 35] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
            Network Access Identifier", RFC 4282, December 2005.
 [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
            Channels", RFC 5056, November 2007.
 [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.
 [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
            Housley, R., and W. Polk, "Internet X.509 Public Key
            Infrastructure Certificate and Certificate Revocation List
            (CRL) Profile", RFC 5280, May 2008.
 [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
            for TLS", RFC 5929, July 2010.
 [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
            in IPv6", RFC 6275, July 2011.

11.2. Informative References

 [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
            August 1980.
 [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
            Levkowetz, "Extensible Authentication Protocol (EAP)",
            RFC 3748, June 2004.
 [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.
 [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.

Korhonen, et al. Experimental [Page 36] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

 [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
            RFC 4303, December 2005.
 [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.
 [RFC5433]  Clancy, T. and H. Tschofenig, "Extensible Authentication
            Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
            RFC 5433, February 2009.
 [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
            Routers", RFC 5555, June 2009.
 [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
            RFC 5944, November 2010.
 [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
            "Internet Key Exchange Protocol Version 2 (IKEv2)",
            RFC 5996, September 2010.
 [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
            Verification of Domain-Based Application Service Identity
            within Internet Public Key Infrastructure Using X.509
            (PKIX) Certificates in the Context of Transport Layer
            Security (TLS)", RFC 6125, March 2011.

Korhonen, et al. Experimental [Page 37] RFC 6618 TLS-Based MIPv6 Security Framework May 2012

Authors' Addresses

 Jouni Korhonen (editor)
 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
 Dirk Kroeselberg
 Siemens
 Otto-Hahn-Ring 6
 Munich  81739
 Germany
 EMail: dirk.kroeselberg@siemens.com

Korhonen, et al. Experimental [Page 38]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6618.txt · Last modified: 2012/05/29 16:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki