Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-preauth-09

PANA Working Group                                               Y. Ohba
Internet-Draft                                                   Toshiba
Intended status: Experimental                                   A. Yegin
Expires: August 14, 2010                                         Samsung
                                                       February 10, 2010

                  Pre-authentication Support for PANA
                       draft-ietf-pana-preauth-09

Abstract

   This document defines an extension to the Protocol for carrying
   Authentication for Network Access (PANA) for proactively establishing
   a PANA security association between a PANA client in one access
   network and a PANA authentication agent in another access network to
   which the PANA client may move.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 14, 2010.

Copyright Notice

   Copyright (c) 2010 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

Ohba & Yegin             Expires August 14, 2010                [Page 1]
Internet-Draft     Pre-authentication Support for PANA     February 2010

   (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 BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Specification of Requirements . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Pre-authentication Procedure  . . . . . . . . . . . . . . . . . 4
   4.  PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Ohba & Yegin             Expires August 14, 2010                [Page 2]
Internet-Draft     Pre-authentication Support for PANA     February 2010

1.  Introduction

   The Protocol for carrying Authentication for Network Access (PANA)
   [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA
   (PANA Authentication Agent) in the access network.  If the PaC is a
   mobile device and is capable of moving from one access network to
   another while running its applications, it is critical for the PaC to
   perform a handover seamlessly without degrading the performance of
   the applications during the handover period.  When the handover
   requires the PaC to establish a PANA session with the PAA in the new
   access network, the signaling to establish the PANA session should be
   completed as fast as possible.  See [I-D.ietf-hokey-preauth-ps] for
   the handover latency requirements.

   This document defines an extension to the PANA protocol [RFC5191]
   used for proactively executing EAP authentication and establishing a
   PANA SA (Security Association) between a PaC in an access network and
   a PAA in another access network to which the PaC may move.  The
   extension to the PANA protocol is designed to realize direct pre-
   authentication defined in [I-D.ietf-hokey-preauth-ps].  How to
   realize authorization and accounting with the use of the pre-
   authentication extension is out of the scope of this document.

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].

2.  Terminology

   The following terms are used in this document in addition to the
   terms defined in [RFC5191].

   Serving Network:  The access network to which the host is currently
      attached.

   Candidate Network:  An access network that is a potential target of
      host's handover.

   Serving PAA (SPAA):  A PAA that resides in the serving network and
      provides network access authentication for a particular PaC.

Ohba & Yegin             Expires August 14, 2010                [Page 3]
Internet-Draft     Pre-authentication Support for PANA     February 2010

   Candidate PAA (CPAA):  A PAA that resides in a candidate network to
      which the PaC may move.  A CPAA for a particular PaC may be a SPAA
      for another PaC.

   Pre-authentication:  Pre-authentication refers to EAP pre-
      authentication and defined as the utilization of EAP to pre-
      establish EAP keying material on an authenticator prior to arrival
      of the peer at the access network served by that authenticator
      [I-D.ietf-hokey-preauth-ps].  In this draft, EAP pre-
      authentication is performed between a PaC and a CPAA.

3.  Pre-authentication Procedure

   A PaC that supports pre-authentication may establish a PANA session
   for each CPAA.

   There may be several mechanisms for a PaC to discover a CPAA.  An IP
   address of the discovered CPAA is the output of those mechanisms.
   PANA pre-authentication is performed between the PaC and CPAA using
   the discovered IP address of the CPAA.  IEEE 802.21 [802.21]
   Information Service MAY be used as a CPAA discovery mechanism.

   There may be a number of criteria for CPAA selection, the timing to
   start pre-authentication and the timing as to when the CPAA becomes
   the SPAA.  Such criteria can be implementation specific and thus are
   outside the scope of this document.

   Pre-authentication is initiated by a PaC in a similar way as normal
   authentication.  A new 'E' (prE-authentication) bit is defined in the
   PANA header.  When pre-authentication is performed, the 'E' (prE-
   authentication) bit of PANA messages is set in order to indicate that
   this PANA run is for pre-authentication.  Use of pre-authentication
   is negotiated as follows.

   o  When a PaC initiates pre-authentication, it sends a PANA-Client-
      Initiation (PCI) message with the 'E' (prE-authentication) bit
      set.  The CPAA responds with a PANA-Auth-Request (PAR) message
      with the 'S' (Start) and 'E' (prE-authentication) bits set only if
      it supports pre-authentication.  Otherwise, the 'E' (prE-
      authentication) bit of the PAR message will be cleared according
      to Section 6.2 of [RFC5191], which results in a negotiation
      failure.

   o  Once the PaC and CPAA have successfully negotiated on performing
      pre-authentication using the 'S' (Start) and 'E' (prE-
      authentication) bits, the subsequent PANA messages exchanged
      between them MUST have the 'E' (prE-authentication) bit set until

Ohba & Yegin             Expires August 14, 2010                [Page 4]
Internet-Draft     Pre-authentication Support for PANA     February 2010

      CPAA becomes SPAA of the PaC.  The PaC may conduct this exchange
      with more than one CPAA.  If the PaC and CPAA have failed to
      negotiate on performing pre-authentication, the PaC or CPAA that
      sent a message with both the 'S' (Start) and 'E' (prE-
      authentication) bits set MUST discard the message received from
      the peer with 'S' (Start) bit set and the 'E' (prE-authentication)
      bit cleared, which will eventually result in PANA session
      termination.

   If IP reconfiguration is needed in the access network associated with
   the CPAA, the 'I' (IP Reconfiguration) bit in PAR messages used for
   pre-authentication between the PaC and CPAA is also set.  The 'I' (IP
   Reconfiguration) bit in these messages takes effect only after the
   CPAA becomes the SPAA.

   When a CPAA of the PaC becomes the SPAA due to, e.g., movement of the
   PaC, the PaC informs the PAA of the change using PANA-Notification-
   Request (PNR) and PANA-Notification-Answer (PNA) messages with the
   'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared.  The
   'E' (prE-authentication) bit MUST be cleared in subsequent PANA
   messages.

   A PANA SA is required for pre-authentication in order to securely
   associate the PNR/PNA exchange to the earlier authentication.

   The PANA session between the PaC and a CPAA is deleted by entering
   the termination phase of the PANA protocol.

   Example call flows for pre-authentication is shown in Figure 1.  Note
   that EAP authentication is performed over PAR and PAN exchanges.

Ohba & Yegin             Expires August 14, 2010                [Page 5]
Internet-Draft     Pre-authentication Support for PANA     February 2010

        PaC                                               CPAA
         |                                                 |
   +------------------+                                    |
   |Pre-authentication|                                    |
   |trigger           |                                    |
   +------------------+                                    |
         |                  PCI w/'E' bit set              |
         |------------------------------------------------>|
         |            PAR w/'S' and 'E' bits set           |
         |<------------------------------------------------|
         |            PAN w/'S' and 'E' bits set           |
         |------------------------------------------------>|
         |           PAR-PAN exchange w/'E' bit set        |
         |<----------------------------------------------->|
         |            PAR w/'C' and 'E' bits set           |
         |<------------------------------------------------|
         |            PAN w/'C' and 'E' bits set           |
         |------------------------------------------------>|
         .                        .                        .
         .                        .                        .
   +----------+                                            |
   | Movement |                                            |
   +----------+                                            |
         |        PNR w/ 'P' bit set and w/o 'E' bit set   |
         |------------------------------------------------>|
         |                                        +-----------------+
         |                                        |CPAA becomes SPAA|
         |                                        +-----------------+
         |        PNA w/ 'P' bit set and w/o 'E' bit set   |
         |<------------------------------------------------|
         |                                                 |

                  Figure 1: Pre-authentication Call Flow

4.  PANA Extensions

   A new 'E' (prE-authentication) bit is defined in Flags field of PANA
   header as follows.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R S C A P I E r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ohba & Yegin             Expires August 14, 2010                [Page 6]
Internet-Draft     Pre-authentication Support for PANA     February 2010

   E(PrE-authentication)  When pre-authentication is performed, the 'E'
      (prE-authentication) bit of PANA messages is set in order to
      indicate whether this PANA run is for pre-authentication.  The
      exact usage of this bit is described in Section 3.  This bit is to
      be assigned by IANA.

5.  Backward Compatibility

   Backward compatibility between a PANA entity that does not support
   the pre-authentication extension and another PANA entity that
   supports the pre-authentication extension is maintained as follows.

   When a PaC that supports the pre-authentication extension initiates
   PANA pre-authentication by sending a PCI message with the 'E' (prE-
   authentication) bit set to a PAA that does not support the pre-
   authentication extension, the PAA will ignore the E-bit according to
   Section 6.2 of [RFC5191], and try to process the message as a normal
   authentication attempt.  As a result, the PaC will receive a PAR
   message with the 'E' (prE-authentication) bit cleared.  In this case,
   the negotiation on the use of pre-authentication will fail and
   eventually the PANA session will be terminated as described in
   Section Section 3.

6.  Security Considerations

   This specification is based on the PANA protocol and it exhibits the
   same security properties, except for one important difference: Pre-
   authenticating PaCs are not physically connected to an access network
   associated with the PAA, but they are connected to some other network
   somewhere else on the Internet.  This distinction can create greater
   DoS vulnerability for systems using PANA pre-authentication if
   appropriate measures are not taken.  An unprotected PAA can be forced
   to create state by an attacker PaC which merely sends PCI messages.

   [RFC5191] describes how PAA can stay stateless while responding to
   incoming PCIs.  PAAs using pre-authentication SHOULD be following
   those guidelines (see [RFC5191] Section 4.1).

   Furthermore, it is recommended that PANA pre-authentication messages
   are only accepted from PaCs originating from well-known IP networks
   (e.g., physically adjacent networks) for a given PAA.  These IP
   networks can be used with a white-list implemented either on the
   firewall protecting the perimeter around the PAA, or on the PAA
   itself.  This prevention measure SHOULD be used whenever it can be
   practically applied to a given deployment.

Ohba & Yegin             Expires August 14, 2010                [Page 7]
Internet-Draft     Pre-authentication Support for PANA     February 2010

7.  IANA Considerations

   As described in Section 4 and following the new IANA allocation
   policy on PANA message [I-D.arkko-pana-iana], bit 6 of the Flags
   field of the PANA Header needs to be assigned by IANA for the 'E'
   (prE-authentication) bit.

8.  Acknowledgments

   The author would like to thank Basavaraj Patil, Ashutosh Dutta,
   Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Lopez,
   Lionel Morand, Victor Fajardo, Glen Zorn, Qin Wu, Jari Arrko, Pasi
   Eronen and Joseph Salowey for their support and valuable feedback.

9.  References

9.1.  Normative References

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [I-D.arkko-pana-iana]
              Arkko, J. and A. Yegin, "IANA Rules for Protocol for
              Carrying Authentication for Network Access (PANA)",
              draft-arkko-pana-iana-00 (work in progress), January 2010.

9.2.  Informative References

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

   [I-D.ietf-hokey-preauth-ps]
              Ohba, Y. and G. Zorn, "Extensible Authentication Protocol
              (EAP) Early Authentication Problem Statement",
              draft-ietf-hokey-preauth-ps-12 (work in progress),
              January 2010.

   [802.21]   IEEE, "Standard for Local and Metropolitan Area Networks:
              Media Independent Handover Services", LAN MAN Standards
              Committee of the IEEE Computer Society 802.21 2008.

Ohba & Yegin             Expires August 14, 2010                [Page 8]
Internet-Draft     Pre-authentication Support for PANA     February 2010

Authors' Addresses

   Yoshihiro Ohba
   Toshiba Corporate Research and Development Center
   1 Komukai-Toshiba-cho
   Saiwai-ku, Kawasaki, Kanagawa  212-8582
   Japan

   Phone: +81 44 549 2230
   Email: yoshihiro.ohba@toshiba.co.jp

   Alper Yegin
   Samsung
   Istanbul
   Turkey

   Email: alper.yegin@yegin.org

Ohba & Yegin             Expires August 14, 2010                [Page 9]