PANA Working Group                                               Y. Ohba
Internet-Draft                                                   Toshiba
Intended status: Standards Track                        December 3, 2008                          April 13, 2009
Expires: June 6, October 15, 2009

                  Pre-authentication Support for PANA
                       draft-ietf-pana-preauth-04
                       draft-ietf-pana-preauth-05

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 June 6, October 15, 2009.

Copyright Notice

   Copyright (c) 2008 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document defines an extension to the Protocol for carrying
   Authentication for Network Access (PANA) for proactively establishing
   a PANA SA (Security Association) security association between a PaC PANA client in one access
   network and a PAA PANA authentication agent in another access network to
   which the PaC PANA client may move.  The
   proposed method operates across multiple administrative domains.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Specification of Requirements . . . . . . . . . . . . . . . 3
   2.  Terminogy .  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Pre-authentication Procedure  . . . . . . . . . . . . . . . . . 4
   4.  PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Authorization and Accounting Considerations  Backward Compatibility  . . . . . . . . . . . . . . . . . . . . 8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

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
   proposed method operates across multiple AAA domains.  The
   extension to the PANA protocol is designed to realize direct pre-authentication 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.  Terminogy  Terminology

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

   Serving Network:  The access network through which the host gains
      access to the Internet/intranet.

   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.  For
      simplicity, this document assumes that there is only one SPAA in
      the serving network while the pre-authentication mechanism
      described in this document is generally applicable to the case
      where there are two or more SPAAs in the serving network.

   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.

   Pre-authorization:  An authorization for a PaC, made by a CPAA for
      the PaC at the time of pre-authentication.

   Post-authorization:  An authorization for a PaC, made by a CPAA for
      the PaC when the CPAA becomes the SPAA for the PaC.

   Pre-authorization SA:  A PANA SA established between a PaC and its
      CPAA.

   Post-authorization SA:  A PANA SA established between the PaC and its
      SPAA.

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 and a CPAA to discover each
   other.  However, such mechanisms are out of the scope of this
   document.

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

   Pre-authentication may be initiated by both a PaC and a CPAA.  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 are is set in order to indicate whether 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 PCI message MUST be unicast.  The CPAA responds with a PANA-Auth-Request (PAR) message
      with the 'S' (Start) and 'E' (prE-
      authentication) (prE-authentication) bits set only if
      it supports pre-authentication.  Otherwise, it MUST silently discard the message. '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  When a CPAA initiates pre-authentication, it sends a PAR message
      with the 'S' (Start) and 'E' (prE-authentication) bits set.  The
      PaC responds with a PANA-Auth-Answer (PAN) message with the 'S'
      (Start) and 'E' (prE-authentication) bits set only if it supports
      pre-authentication.  Otherwise, it MUST silently discard the
      message. 'E' (prE-authentication) bit
      of the PAN message will be cleared according to Section 6.2 of
      [RFC5191], which results in a negotiation failure.

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

   When a set until
      CPAA with which the PaC has a pre-authorization SA becomes the SPAA due to, e.g., movement of the PaC, PaC.  The PaC may conduct this exchange
      with more than one CPAA.  If the PaC performs an IP
   address update procedure defined in Section 5.6 of [RFC5191] in order and CPAA have failed to update
      negotiate on performing pre-authentication, the SPAA PaC or CPAA that
      sent a message with both the PaC's new address obtained 'S' (Start) and 'E' (prE-
      authentication) bits set MUST discard the message received from
      the new
   serving network.  PANA-Notification-Request (PNR) and PANA-
   Notification-Answer (PNA) messages peer with 'P' (Ping) 'S' (Start) bit set are used
   for this purpose.  The completion of the IP address update procedure
   will change the pre-authorization SA to a post-authorization SA.  In
   this case, and the 'E' MUST NOT be set (prE-authentication)
      bit cleared, which will eventually result in the PNR and PNA messages and
   subsequent PANA messages.

   If there is another CPAA with which the PaC has session
      termination.

   When a pre-authorization
   SA and CPAA of the PaC wants to keep the pre-authorization SA after becomes the
   change SPAA due to, e.g., movement of SPAA, the
   PaC, the PaC also performs an IP address update procedure
   defined in Section 5.6 of [RFC5191] in order to update informs the CPAA with PAA of the PaC's new address.  PNR change using PANA-Notification-
   Request (PNR) and PNA PANA-Notification-Answer (PNA) messages with the
   'P' (Ping) bit set
   is used for this purpose.  In this case, and the 'E' (prE-authentication) bit cleared.  The
   'E' (prE-authentication) bit MUST be set cleared in the PNR and PNA messages and subsequent PANA
   messages.

   The IP address update procedure with the CPAA will not
   change the pre-authorization SA to a post-authorization SA.

   The pre-authorization SA and the corresponding PANA session between the PaC and a CPAA is deleted by entering
   the termination phase of the PANA protocol.

   Example call flows for PaC-initiated pre-authentication and PAA-
   initiated pre-authentication are shown in Figure 1 and Figure 2,
   respectively.  Note that EAP authentication is performed over PAR and
   PAN exchanges.

        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        |
         |<----------------------------------------------->|
         |                                        +------------------+
         |                                        |pre-authorization |
         |                                        +------------------+
         |            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   |
         |------------------------------------------------>|
         |                                        +-------------------+
         |                                        |post-authorization |                                        +-----------------+
         |                                        |(CPAA                                        |CPAA becomes SPAA)| SPAA|
         |                                        +-------------------+                                        +-----------------+
         |        PNA w/ 'P' bit set and w/o 'E' bit set   |
         |<------------------------------------------------|
         |                                                 |

           Figure 1: PaC-initiated Pre-authentication Call Flow
        PaC                                               CPAA
         |                                                 |
         |                                        +------------------+
         |                                        |Pre-authentication|
         |                                        |trigger           |
         |                                        +------------------+
         |            PAR w/'S' and 'E' bits set           |
         |<------------------------------------------------|
         |            PAN w/'S' and 'E' bits set           |
         |------------------------------------------------>|
         |           PAR-PAN exchange w/'E' bit set        |
         |<----------------------------------------------->|
         |                                        +------------------+
         |                                        |pre-authorization |
         |                                        +------------------+
         |            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   |
         |------------------------------------------------>|
         |                                        +-------------------+
         |                                        |post-authorization |                                        +-----------------+
         |                                        |(CPAA                                        |CPAA becomes SPAA)| SPAA|
         |                                        +-------------------+                                        +-----------------+
         |        PNA w/ 'P' bit set and w/o 'E' bit set   |
         |<------------------------------------------------|
         |                                                 |

           Figure 2: PAA-initiated 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   E(PrE-authentication)  When pre-authentication is performed, the 'E'
      (prE-authentication) bit of PANA messages are is set in order to
      indicate whether this PANA run is for establishing a pre-
      authorization SA. pre-authentication.  The
      exact usage of this bit is described in Section 3.  This bit is to
      be assigned by IANA.

5.  Authorization and Accounting Considerations

   A pre-authorization and  Backward Compatibility

   Backward compatibility between a post-authorization for 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 may have
   different authorization policies.  For example, that supports the pre-authorization
   policy may 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 allow support the PaC pre-
   authentication extension, the PAA will ignore the E-bit according to sent or
   Section 6.2 of [RFC5191], and try to process the message as a normal
   authentication attempt.  As a result, the PaC will receive packets through an
   Enforcement Point (EP) a PAR
   message with the 'E' (prE-authentication) bit cleared.

   Similarly, when a PAA that is under control of supports the CPAA, while both pre-authentication extension
   initiates PANA pre-authentication by sending a PAR message with the
   'E' (prE-authentication) bit set to a PaC that does not support the
   pre-authentication extension, the PaC will ignore the pre-authorization E-bit, and post-authorization policies may allow
   installing credentials try
   to process the EP, where message as a normal authentication attempt.  As a
   result, the credentials are used for
   establishing PAA will receive a security association for per-packet cryptographic
   filtering.

   In an access network where accounting is performed, accounting starts
   when PAN message with the pre-authorization SA becomes 'E' (prE-
   authentication) bit cleared.

   In both cases, the post-authorization SA by
   default.  Depending negotiation on the pre-authorization policy, accounting may
   start immediately after use of pre-authentication will
   fail and eventually the pre-authorization SA is established. PANA session will be terminated as described
   in Section Section 3.

6.  Security Considerations

   Since the mechanism described in this document is designed to work
   across multiple access networks, each EP in the serving an access network
   SHOULD may be configured
   to allow or disallow PANA messages to be forwarded between a
   PaC and a CPAA only if the PaC has a post-authorization SA with the
   SPAA in order to avoid an unauthorized PaC to initiate pre-
   authentication.  Also, each access network that supports pre-
   authentication SHOULD block pre-authentication attempts from networks
   from which a handover is not likely to occur. set of access networks.

   When pre-authentication is initiated by a CPAA, it is possible that
   the PaC simultaneously communicates with
   multiple CPAAs initiating
   pre-authentication. simultaneously initiate pre-authentication for the
   same PaC.  In order to avoid possible resource consumption attacks on
   the PaC caused by a blind an attacker initiating pre-
   authentication pre-authentication for the
   PaC by changing source addresses, the PaC SHOULD limit the maximum
   number of CPAAs allowed to communicate.

   The pre-authentication mechanism defined in this document does not
   have an issue on context binding in which link-layer independent
   context carried over pre-authentication signaling is bound to the
   link-layer specific context [I-D.ietf-hokey-preauth-ps], because the
   same EAP transport protocol (i.e., PANA) is used for normal
   authentication and pre-authentication in the candidate network.

7.  IANA Considerations

   As described in Section 4, 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 Alper Yegin, Basavaraj Patil, Ashutosh
   Dutta, Julien
   Bournelle and Bournelle, Sasikanth Bharadwaj Bharadwaj, Subir Das, Rafa Marin
   Lopez, Lionel Morand, Victor Fajardo, Glen Zorn and Qin Wu for their
   support and valuable comments. 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.

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]
              Wu, W. and Y. Ohba, Y., "EAP Pre-authentication Problem
              Statement",
              draft-ietf-hokey-preauth-ps-04 draft-ietf-hokey-preauth-ps-06 (work in
              progress),
              September 2008. March 2009.

Author's Address

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscateway, NJ  08854
   USA

   Phone: +1 732 699 5305
   Email: yohba@tari.toshiba.com