MIPv6 H. Tschofenig
Internet-Draft S. Thiruvengadam
Expires: April 18, 2005 Siemens
October 18, 2004
Bootstrapping Mobile IPv6 using PANA
draft-tschofenig-mip6-bootstrapping-pana-00.txt
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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
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
parameters:
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
HA
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Furthermore, we use the same terminology as in [RFC3775],
[I-D.ietf-seamoby-mobility-terminology],
[I-D.ietf-pana-requirements].
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
[I-D.ietf-pana-pana].
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
again.
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
SASL).
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
number)
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
Bootstrapping.
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
[I-D.ietf-mip6-bootstrap-ps]
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.
[I-D.ietf-pana-pana]
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.
[I-D.ietf-mip6-auth-protocol]
"Authentication Protocol for Mobile IPv6",
draft-ietf-mip6-auth-protocol-00 (work in progress), July
2004.
7.2 Informative References
[I-D.ietf-mip6-bootstrap-ps]
Patel, A., "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress),
July 2004.
[I-D.ietf-seamoby-mobility-terminology]
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.
[I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-08 (work in progress), June
2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[I-D.eronen-ipsec-ikev2-eap-auth]
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
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-16 (work in progress), September
2004.
[I-D.ietf-mip4-rfc3344bis]
"IP Mobility Support for IPv4, revised",
draft-ietf-mip4-rfc3344bis-00 (work in progress), July
2004.
[I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication",
draft-arkko-pppext-eap-aka-12 (work in progress), April
2004.
[I-D.ietf-ipsec-nat-t-ike]
Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-08 (work in progress), February
2004.
[I-D.blanchet-v6ops-tunnelbroker-tsp]
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
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Srinath Thiruvengadam
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig & Thiruvengadam Expires [Page 15]