MIPv6                                                      H. Tschofenig
Internet-Draft                                          S. Thiruvengadam
Expires: April 18, 2005                                          Siemens
                                                        October 18, 2004

                  Bootstrapping Mobile IPv6 using PANA

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).


   Recently the MIP6 working group has expressed a fair amount of
   interest in developing another Mobile Node <--> Home Agent Binding
   Update security solution.  The currently proposed solution heavily
   focuses on one specific authentication and key exchange protocol.
   Obviously, this approach suffers from some limitations.  This
   document investigates the usage of an EAP based bootstrapping
   approach using PANA.

Tschofenig & Thiruvengadam      Expires                         [Page 1]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Introduction to PANA . . . . . . . . . . . . . . . . . . . . .  6
     3.1   PANA message flow  . . . . . . . . . . . . . . . . . . . .  6
     3.2   Relaxing PANA Assumptions  . . . . . . . . . . . . . . . .  8

   4.  Bootstrapping Issues . . . . . . . . . . . . . . . . . . . . .  9
     4.1   Home Agent Discovery . . . . . . . . . . . . . . . . . . .  9
     4.2   Obtaingin HoA  . . . . . . . . . . . . . . . . . . . . . .  9
     4.3   MN-HA security association . . . . . . . . . . . . . . . .  9

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11

   6.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 13

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14

       Intellectual Property and Copyright Statements . . . . . . . . 15

Tschofenig & Thiruvengadam      Expires                         [Page 2]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

1.  Introduction

   Recently the MIP6 working group has expressed a fair amount of
   interest in developing another Mobile Node <--> Home Agent Binding
   Update security solution.  The currently proposed solution
   [I-D.ietf-mip6-auth-protocol] (referred as MIP6-Auth-Protocol)
   heavily focuses on one specific authentication and key exchange
   protocol.  This protocol requires that the entire message exchange is
   finished in a single roundtrip with the mobile node initiating the
   exchange.  Obviously, this approach suffers from some limitations.
   This document investigates the usage of an Extensible Authentication
   Protocol (EAP) [RFC3748] based approach which offers more
   flexibility.  As in other areas there is the 'one size does not fit
   all' problem.

   IKEv2 [I-D.ietf-ipsec-ikev2] supports the Extensible Authentication
   Protocol.  Unfortuntately, IKEv2 only creates IPsec SAs since the
   concept of Domain of Interpretations (DoIs) was removed due to the
   limited usage in IKEv1.  The authors think that most arguments
   against the IPsec protection of MIPv6 MN<->HA Binding Updates address
   problems caused by IPsec rather than IKEv2.  It might be worth
   mentioning that IKEv2 is far more complex than
   [I-D.ietf-mip6-auth-protocol] .  The extension proposed by
   [I-D.eronen-ipsec-ikev2-eap-auth], which tried to address some
   deployment aspects in certain environments, has not been considered
   by the IPsec working group.

   Following the typical separation between

      (a) Authentication and security association establishment and

      (b) "Data" traffic protection

   which is exercised by a number of protocols today (such as TLS,
   IKEv1, IKEv2) it seems to be reasonable to re-use the MIPv6
   bootstrapping procedure for the former task whereas a simple
   integrity and replay protection mechanism is used to protect the
   Binding Update in a fashion similar to Mobile IPv4
   [I-D.ietf-mip4-rfc3344bis] (or also similar to a modified version of
   the MIPv6-Auth-Protocol [I-D.ietf-mip6-auth-protocol]).  Note that
   the "data" is, in our case, the signaling traffic.

   The MIPv6 bootstrapping problem as described in
   [I-D.ietf-mip6-bootstrap-ps] involves bootstrapping of the following

   o  MN finding HA's address

Tschofenig & Thiruvengadam      Expires                         [Page 3]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

   o  MN obtaining HoA

   o  Setting an IPsec security association (SA) between the MN and the

   With the most recent developments in the MIP6 working group with a
   possible usage of the bootstrapping protocol for authentication and
   security association establishment it seems to be resonable to modify
   the goal of the MIPv6 bootstrapping in the sense that a security
   association has to be established between the mobile node and the
   home agent for protection of the MN <--> HA Binding Update.

   Protocol for Carrying Authentication for Network Access (PANA) is a
   lightweight protocol exchanging EAP payloads over UDP.  This document
   suggests to consider the usage of PANA for bootstrapping of a
   security association between the MN and the HA.

   Note that this document does not aim to replace the
   MIPv6-Auth-Protocol [I-D.ietf-mip6-auth-protocol].

Tschofenig & Thiruvengadam      Expires                         [Page 4]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   Furthermore, we use the same terminology as in [RFC3775],

Tschofenig & Thiruvengadam      Expires                         [Page 5]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

3.  Introduction to PANA

   PANA is a link layer agnostic transport for Extensible Authentication
   Protocol (EAP) to enable network access authentication between
   clients and access networks.  PANA is currently being standardised at
   the IETF PANA working group.  PANA can carry any EAP method and
   thereby allows user authentication and the establishment of a PANA
   security association between the PANA client (PaC) and PANA
   authentication agent (PAA) at the end of successful protocol run.
   The PAA indicates the results of the authentication using the
   PANA-Bind-Answer message.

3.1  PANA message flow

   The protocol has four phases, which are explained briefly below.  For
   detailed explanation and message formats, the reader should see

   Discovery phase: This is the initial handshake phase.  The PaC
      discovers the PAA in this phase.  The PaC sends a multicast
      discovery packet and the PAA responds to it with a
      PANA-start-request (PSR) message.  The PaC responds with a
      PANA-start-answer (PSA) message.  The PaC is also allowed to send
      a unicast discovery message if it knows the PAA in advance.

   Authentication phase: A PANA-authentication-request is sent by the
      PAA and the PaC replies with PANA-authentication-answer.  This
      message-pair may be repeated many times according to the EAP
      method in use.  But finally PANA-bind-request message and
      PANA-bind-answer message pairs are exchanged.  The
      PANA-bind-request would convey whether PaC is successfully
      authenticated or not.  After the exchange of this message pair,
      the PAA would enforce the policy rules at the EP.

   Termination phase: Either the PaC or the PAA could request
      termination of the PANA session.  The PANA-termination-request
      message would initiate session termination and
      PANA-termination-answer would acknowledge the teardown of session.

   Re-authentication phase: The PaC may have to re-authenticate
      periodically.  For the reauthentication phase, the PAA sends the
      PANA-reauthentication-request message to PaC.  It is acknowledged
      with PANA-reauthentication-answer and the PAA sends
      PANA-start-request message to trigger the authentication phase

   An example message flow using the EAP-AKA [I-D.arkko-pppext-eap-aka]

Tschofenig & Thiruvengadam      Expires                         [Page 6]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

   is shown in Figure 1.  The re-authentication and the termination
   phase are optional.

           PaC      PAA  Message[AVPs]

      ~~~ Discovery and initial handshake phase ~~~

         ----->     PANA-PAA-Discover

         <-----     PANA-Start-Request[Cookie]

         ----->     PANA-Start-Request-Answer[Cookie]

                      Figure 1: PANA message flow

      ~~~ Authentication phase ~~~

         <-----     PANA-Auth-Request
            [EAP(EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC))]

         ----->     PANA-Auth-Answer
            [EAP(EAP-Response/AKA-Challenge(AT_RES, AT_MAC))]

         <-----     PANA-Bind-Request        // F-flag set
            [EAP(EAP-Success), Device-Id, Data-Protection, MAC]

         ----->     PANA-Bind-Answer         // F-flag set
            [Device-Id, Data-Protection, MAC]

      ~~~ Re-authentication ~~~

         <-----     PANA-Reauth-Request[MAC]

         ----->     PANA-Reauth-Answer[MAC]

      ~~~ Termination phase ~~~

         ----->     PANA-Termination-Request[MAC]

         <-----     PANA-Termination-Answer[MAC]

Tschofenig & Thiruvengadam      Expires                         [Page 7]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

3.2  Relaxing PANA Assumptions

   PANA was designed with a focus on network access authentication.
   This fact is reflected in the discovery mechanism whereby a multicast
   address is used (see Section 8.2 of [I-D.ietf-pana-pana]) whereby it
   is assumed that the PAA is only one IP hop away from the PaC.

   This assumption is not applicable to this environment.  The PaC might
   address the PAA directly via a unicast message or a new discovery
   message needs to be added.  In the former case the PAA would be
   co-located with the home agent.

Tschofenig & Thiruvengadam      Expires                         [Page 8]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

4.  Bootstrapping Issues

   We assume that the MN will act as a PaC and some agent in the network
   will act as the PAA, most likely the home agent itself.  After mutual
   authentication, a security association will be established between
   PaC and the HA, which is comparable to an enforcement point (EP).
   Note, the PAA and the EP may be co-located as well.

4.1  Home Agent Discovery

   Finding the address of the HA will be regarded as out of scope of
   this document.  The MN could learn about the HA either by manual
   configuration, DNS or some other mechanism (such as the MIPv6 anycast
   mechanism).  Even a discovery mechanism incorporated into the PANA
   discovery mechanism is possible and for further investigation.

4.2  Obtaingin HoA

   The payload of any PANA message consists of zero or more Attribute
   Value Pairs (AVP).  [I-D.ietf-pana-pana] describes a number of AVPs
   for different purposes.  This draft proposes a new AVP for carrying
   the HoA of the MN.

   HoA AVP: Contains the MIPv6 home address of the mobile node that
      wishes to setup a security association with the corresponding home
      agent.  The HoA AVP is integrity protected by PANA and either
      randomly selected or selected based on user authentication.

   To deal with UDP encapsulation in case of NAT traversal or even with
   IPv4/IPv6 transition the same procedure as suggested with an
   extension for IKEv1 [I-D.ietf-ipsec-nat-t-ike] and in IKEv2
   [I-D.ietf-ipsec-ikev2] can be applied.  Support for this
   functionality requires the introduction of a new AVP in PANA.  In
   context of IPv4/IPv6 transition scenario this proposal provides an
   alternative solution for a tunnel broker (see also
   [I-D.blanchet-v6ops-tunnelbroker-tsp] for a different approach using

4.3  MN-HA security association

   As motivated in Section 1 a security association is required for
   subsequent protection of Mobile IPv6 Binding Update messages sent
   between the MN and the HA.  We refer to this security association as
   the MIPv6 SA.  Since the details of the MIPv6-Auth-Protocol
   [I-D.ietf-mip6-auth-protocol] are subject to change we assume that
   the following parameters have to be established as part of the
   bootstrapping procedure:

Tschofenig & Thiruvengadam      Expires                         [Page 9]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

   o  Security Parameter Index (SPI) - possibly for both directions

   o  Replay Protection Parameter (such as a timestamp or a sequence

   o  Algorithms (if a negotiation procedure is desired)

   Finally, a session key needs to be derived.  Since a PANA SA needs to
   be established based on the EAP method provided session key it is
   also useful to apply the same procedure for deriving a session key
   for the MIPv6 SA.  Section 4.1.5 of [I-D.ietf-pana-pana] describes
   the session key derivation for the PANA SA.

   It might be worth noting that the PANA protocol also allows rekeying
   of the security association (both the PANA SA and the MIPv6 SA).
   Section 4.4 of [I-D.ietf-pana-pana] discusses this aspect in the
   context of re-authentication.

   The lifetime of the MIPv6 SA can either be negotiated or indicated by
   the MN's home network.  As another alternative the periodic
   retransmission of "refresh" messages is benefial to deal with NATs,
   stateful packet filtering firewalls and orphan state at the HA.  PANA
   provides such a refresh message as described in Section 4.5 of
   [I-D.ietf-pana-pana].  Furthermore, a Session-Lifetime AVP is offered
   by PANA as described in Section 4.10 of [I-D.ietf-pana-pana].

Tschofenig & Thiruvengadam      Expires                        [Page 10]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

5.  Security Considerations

   This document tries to raise some additional aspects for the MIPv6 MN
   <-> HA Binding Update security discussions in context of Mobile IPv6

   The security considerations of the following documents are directly
   applicable to this draft: PANA [I-D.ietf-pana-pana],
   MIPv6-Auth-Protocol [I-D.ietf-mip6-auth-protocol], MIPv4
   [I-D.ietf-mip4-rfc3344bis], MIPv6 [RFC3775] and MIPv6 Boostrapping

   A future version of this document will extract the relevant security
   issues from these documents in order to present them in more details
   once further steps have been taken within the MIPv6 working group.

Tschofenig & Thiruvengadam      Expires                        [Page 11]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

6.  Contributors

   Many parts of this documents are the result of some discussions
   within the PANA WG team.  In particular the authors would like to
   thank D.  Forsberg, Y.  Ohba, B.  Patil and A.  Yegin.

   Furthermore, we would like to thank Udo Schilcher and Thomas
   Hambrusch for their contributions to this document.

Tschofenig & Thiruvengadam      Expires                        [Page 12]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

7.  References

7.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

              Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", draft-ietf-pana-pana-05 (work in
              progress), July 2004.

              "Authentication Protocol for Mobile IPv6",
              draft-ietf-mip6-auth-protocol-00 (work in progress), July

7.2  Informative References

              Patel, A., "Problem Statement for bootstrapping Mobile
              IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress),
              July 2004.

              Manner, J. and M. Kojo, "Mobility Related Terminology",
              draft-ietf-seamoby-mobility-terminology-06 (work in
              progress), February 2004.

   [RFC3775]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

              Yegin, A. and Y. Ohba, "Protocol for Carrying
              Authentication for Network Access (PANA)Requirements",
              draft-ietf-pana-requirements-08 (work in progress), June

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
              3748, June 2004.

              Eronen, P., "Extension for EAP Authentication in IKEv2",
              draft-eronen-ipsec-ikev2-eap-auth-01 (work in progress),
              May 2004.

Tschofenig & Thiruvengadam      Expires                        [Page 13]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-16 (work in progress), September

              "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-00 (work in progress), July

              Arkko, J. and H. Haverinen, "EAP AKA Authentication",
              draft-arkko-pppext-eap-aka-12 (work in progress), April

              Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
              draft-ietf-ipsec-nat-t-ike-08 (work in progress), February

              Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup
              Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00
              (work in progress), February 2004.

Authors' Addresses

   Hannes Tschofenig
   Otto-Hahn-Ring 6
   Munich, Bayern  81739

   EMail: Hannes.Tschofenig@siemens.com

   Srinath Thiruvengadam
   Otto-Hahn-Ring 6
   Munich, Bayern  81739

   EMail: srinath@mytum.de

Tschofenig & Thiruvengadam      Expires                        [Page 14]

Internet-Draft       Bootstrapping MIPv6 using PANA         October 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Tschofenig & Thiruvengadam      Expires                        [Page 15]