PANA Working Group                                       V. Fajardo, Ed.                                    Weihong Wang
Internet-Draft                                                   Y. Ohba            Zhejiang University of Technology, China
Intended status: Informational                                      TARI Experimental                         Tieming Chen
Expires: October 25, 2009                                       R. Lopez
                                                         Univ. of Murcia
                                                          April 23, January 2, 2010 Zhejiang University of Technology, China
                                                        Yubing Lin
                           Zhejiang University of Technology, China
                                                        Yiling Cui
                           Zhejiang University of Technology, China
                                                       July 3, 2009

  State Machines for Protocol for Carrying

Basic Security Requirements of Authentication for Network
                             Access (PANA)
                    draft-ietf-pana-statemachine-12 Protocol on Ad hoc
                 draft-ietf-pana-statemachine-13.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 October 25, 2009. January 3, 2010.

Copyright Notice

   Copyright (c) 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 in effect on the date of
   publication of this 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 the conceptual state machines for the Protocol
   for Carrying Authentication specifies basic security standards for Network Access (PANA). authentication
   protocol on Ad hoc. The state
   machines consist of security standards are based on the PANA Client (PaC) state machine ECDH to
   discover a authentication protocol between two nodes, and on the PANA
   Authentication Agent (PAA) state machine.  The
   TinyOS simulation platform and Mica nodes. This document also
   defines elements of procedure for authentication protocol, including
   System Initialization, Key extract and the identity authentication.
   With these standards, authentication between two state machines
   show how PANA nodes can interface with the EAP state machines.  The state
   machines be
   completed in a certain time and associated model are informative only.  Implementations
   may achieve the same results using different methods. a certain circles.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   3.  Interface Between PANA  Overview of ECC Encryption and EAP TinyOS  . . . . . . . . . . . .  5
     3.1.  ECC Encryption . . . .  6
   4.  Document Authority . . . . . . . . . . . . . . . . . .  5
     3.2.  TinyOS . . . .  8
   5.  Notations . . . . . . . . . . . . . . . . . . . . . .  6
        3.2.1 Struce of TinyOS. . . . .  9
   6.  Common Rules . . . . . . . . . . . . . . .  6
        3.2.2 NesC programming language . . . . . . . . . . 11
     6.1.  Common Procedures . . . . .  7
     3.3 Introduction of TinyECC. . . . . . . . . . . . . . . . 11
     6.2.  Common Variables . . .  8
        3.3.1 System's main modules . . . . . . . . . . . . . . . . .  8
        3.3.2 Working process . 13
     6.3.  Configurable Values . . . . . . . . . . . . . . . . . . . 15
     6.4.  Common Message Initialization Rules  8
   4.  Protocol Description . . . . . . . . . . . 15
     6.5.  Common Retransmition Rules . . . . . . . . . .  9
     4.1.  Flow and Structure . . . . . . 15
     6.6.  Common State Transitions . . . . . . . . . . . . . .  9
     4.2.  Implementation . . . 15
   7.  PaC State Machine . . . . . . . . . . . . . . . . . . .  9
     4.3.  Analysis of Protocol . . . 18
     7.1.  Interface between PaC and EAP Peer . . . . . . . . . . . . 18
       7.1.1.  Delivering EAP Messages from PaC to EAP Peer . . . . 10
        4.3.1 Performance Analysis  . 18
       7.1.2.  Delivering EAP Messages from EAP Peer to PaC . . . . . 18
       7.1.3.  EAP Restart Notification from PaC to EAP Peer . . . . 18
       7.1.4.  EAP Authentication Result Notification from EAP
               Peer to PaC . . . . . . . 10
        4.3.2 Security Analysis . . . . . . . . . . . . . . 19
       7.1.5.  Alternate Failure Notification from PaC to EAP Peer . 19
     7.2.  Configurable Values . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . 19
     7.3.  Variables . . . . 11
     5.1.  Privacy Considerations . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . 19
     7.4.  Procedures . . . . . . . . . . . . . . . . . . . 12
   7.  Contributors . . . . . 20
     7.5.  PaC State Transition Table . . . . . . . . . . . . . . . . 21
   8.  PAA State Machine . . . . 12
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . 27
     8.1.  Interface between PAA and EAP Authenticator . . . . . 13
   9. References  . . 27
       8.1.1.  EAP Restart Notification from PAA to EAP
               Authenticator . . . . . . . . . . . . . . . . . . . . 27
       8.1.2.  Delivering EAP Responses from PAA to EAP
               Authenticator . . . . 13
     9.1. Normative References  . . . . . . . . . . . . . . . . 27
       8.1.3.  Delivering EAP Messages from EAP Authenticator to
               PAA . . . 13
     9.2. Informative References  . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . 27
       8.1.4.  EAP Authentication Result Notification from EAP
               Authenticator to PAA . . . . . . . . . . . . . . . . . 27
     8.2.  Variables . . . . . . . . . . . . . . . . . . . . . . . . 28
     8.3.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . 29
     8.4.  PAA State Transition Table . . . . . . . . . . . . . . . . 29
   9.  Implementation Considerations  . . . . . . . . . . . . . . . . 35
     9.1.  PAA and PaC Interface to Service Management Entity . . . . 35
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 36
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 38
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 39
     13.2. Informative References . . . . . . . . . . . . . . . . . . 39
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40

1.  Introduction

   This document defines the state machines for Protocol Carrying
   Authentication for Network Access (PANA) [RFC5191].  There are state
   machines for the PANA client (PaC) and for the PANA Authentication
   Agent (PAA).  Each state machine is specified through a set of
   variables, procedures and a state transition table.  The state
   machines and associated models described in this document are
   informative only.  Implementations may achieve similar results using
   different models and/or methods.

   A PANA protocol execution consists of several exchanges to carry
   authentication information.  Specifically, EAP PDUs are transported
   inside PANA PDUs between PaC and PAA, that is PANA represents a lower
   layer for EAP protocol.  Thus, a PANA state machine bases its
   execution on an EAP state machine execution and vice versa.  Thus
   this document also shows for each of PaC and PAA an interface between
   an EAP state machine and a PANA state machine and how this interface
   allows to exchange information between them.  Thanks to this
   interface, a PANA state machine can be informed about several events
   generated in an EAP state machine and make its execution conditional
   to its events.

   The details of EAP state machines are out of the scope of this
   document.  Additional information can be found in [RFC4137].
   Nevertheless PANA state machines presented here have been coordinated
   with state machines shown by [RFC4137].

   This document, apart from defining PaC and PAA state machines and
   their interfaces to EAP state machines (running on top of PANA),
   provides some implementation considerations, taking into account that
   it is not a specification but an implementation guideline.

2.  Terminology

   This document reuses the terminology used in [RFC5191].

3.  Interface Between PANA and EAP

   PANA carries EAP messages exchanged between an EAP peer and an EAP
   authenticator (see Figure 1).  Thus a PANA state machine interacts
   with an EAP state machine.

   Two state machines are defined in this document : the PaC state
   machine (see Section 7) and the PAA state machine (see Section 8).
   The definition of each state machine consists of a set of variables,
   procedures and a state transition table.  A subset of these variables
   and procedures defines the interface between a PANA state machine and
   an EAP state machine and the state transition table defines the PANA
   state machine behavior based on results obtained through them.

   On the one hand, the PaC state machine interacts with an EAP peer
   state machine in order to carry out the PANA protocol on the PaC
   side.  On the other hand, the PAA state machine interacts with an EAP
   authenticator state machine to run the PANA protocol on the PAA side.

                     Peer             |EAP            Auth
                     EAP    <---------|------------>  EAP
                    ^ |               |              ^ |
                    | |               | EAP-Message  | |  EAP-Message
       EAP-Message    | |EAP-Message  |                | |
                      | v             |PANA            | v
                     PaC    <---------|------------>  PAA

                 Figure 1: Interface between PANA and EAP

   Thus two interfaces are needed between PANA state machines and EAP
   state machines, namely:

   o  Interface between the PaC state machine and the EAP peer state
      machine

   o  Interface between the PAA state machine and the EAP authenticator
      state machine

   In general, the PaC and PAA state machines present EAP messages to
   the EAP peer and authenticator state machines through the interface,
   respectively.  The EAP peer and authenticator state machines process
   these messages and sends EAP messages through the PaC and PAA state
   machines that is responsible for actually transmitting this message,
   respectively.

   For example, [RFC4137] specifies four interfaces to lower layers: (i)
   an interface between the EAP peer state machine and a lower layer,
   (ii) an interface between the EAP standalone authenticator state
   machine and a lower layer, (iii) an interface between the EAP full
   authenticator state machine and a lower layer and (iv) an interface
   between the EAP backend authenticator state machine and a lower
   layer.  In this document, the PANA protocol is the lower layer of EAP
   and only the first three interfaces are of interest to PANA.  The
   second and third interfaces are the same.  In this regard, the EAP
   standalone authenticator or the EAP full authenticator and its state
   machine in [RFC4137] are referred to as the EAP authenticator and the
   EAP authenticator state machine, respectively, in this document.  If
   an EAP peer and an EAP authenticator follow the state machines
   defined in [RFC4137], the interfaces between PANA and EAP could be
   based on that document.  Detailed definition of interfaces between
   PANA and EAP are described in the subsequent sections.

4.  Document Authority

   This document is intended to comply with the technical contents of
   any of the related documents ([RFC5191] and [RFC4137]).  When there
   is a discrepancy, the related documents are considered authoritative
   and they take precedence over this document.

5.  Notations

   The following state transition tables are completed mostly based on
   the conventions specified in [RFC4137].  The complete text is
   described below.

   State transition tables are used to represent the operation of the
   protocol by a number of cooperating state machines each comprising a
   group of connected, mutually exclusive states.  Only one state of
   each machine can be active at any given time.

   All permissible transitions from a given state to other states and
   associated actions performed when the transitions occur are
   represented by using triplets of (exit condition, exit action, exit
   state).  All conditions are expressions that evaluate to TRUE or
   FALSE; if a condition evaluates to TRUE, then the condition is met.
   A state "ANY" is a wildcard state that matches any state in each
   state machine except those explicity enumerated as exception states.
   The exit conditions of a wildcard state are evaluated after all other
   exit conditions of specific to the current state are met.

   On exit from a state, the exit actions defined for the state and the
   exit condition are executed exactly once, in the order that they
   appear.  (Note that the procedures defined in [RFC4137] are executed
   on entry to a state, which is one major difference from this
   document.)  Each exit action is deemed to be atomic; i.e., execution
   of an exit action completes before the next sequential exit action
   starts to execute.  No exit action execute outside of a state block.
   The exit actions in only one state block execute at a time even if
   the conditions for execution of state blocks in different state
   machines are satisfied.  All exit actions in an executing state block
   complete execution before the transition to and execution of any
   other state blocks.  The execution of any state block appears to be
   atomic with respect to the execution of any other state block and the
   transition condition to that state from the previous state is TRUE
   when execution commences.  The order of execution of state blocks in
   different state machines is undefined except as constrained by their
   transition conditions.  A variable that is set to a particular value
   in a state block retains this value until a subsequent state block
   executes an exit action that modifies the value.

   On completion of the transition from the previous state to the
   current state, all exit conditions occurring during the current state
   (including exit conditions defined for the wildcard state) are
   evaluated until an exit condition for that state is met.

   Any event variable is set to TRUE when the corresponding event occurs
   and set to FALSE immediately after completion of the action
   associated with the current state and the event.

   The interpretation of the special symbols and operators used is
   defined in [RFC4137].

6.  Common Rules

   There are following procedures, variables, message initializing rules
   and state transitions that are common to both the PaC and PAA state
   machines.

   Throughout this document, the character string "PANA_MESSAGE_NAME"
   matches any one of the abbreviated PANA message names, i.e., "PCI",
   "PAR", "PAN", "PTR", "PTA", "PNR", "PNA".

6.1.  Common Procedures

   void None()

      A null procedure, i.e., nothing is done.

   void Disconnect()

      A procedure to delete the PANA session as well as the
      corresponding EAP session and authorization state.

   boolean Authorize()

      A procedure to create or modify authorization state.  It returns
      TRUE if authorization is successful.  Otherwise, it returns FALSE.
      It is assumed that Authorize() procedure of PaC state machine
      always returns TRUE.  In the case that a non-key-generating EAP
      method is used but a PANA SA is required after successful
      authentication (generate_pana_sa() returns TRUE), Authorize()
      procedure must return FALSE.

   void Tx:PANA_MESSAGE_NAME[flag](AVPs)

      A procedure to send a PANA message to its peering PANA entity.
      The "flag" argument contains one or more flag (e.g., Tx:PAR[C]) to
      be set to the message, except for 'R' (Request) flag.  The "AVPs"
      contains a list of names of optional AVPs to be inserted in the
      message, except for AUTH AVP.

      This procedure includes the following action before actual
      transmission:

             if (flag==S)
               PANA_MESSAGE_NAME.S_flag=Set;
             if (flag==C)
               PANA_MESSAGE_NAME.C_flag=Set;
             if (flag==A)
               PANA_MESSAGE_NAME.A_flag=Set;
             if (flag==P)
               PANA_MESSAGE_NAME.P_flag=Set;
             PANA_MESSAGE_NAME.insert_avp(AVPs);
             if (key_available())
               PANA_MESSAGE_NANE.insert_avp("AUTH");

   void TxEAP()

      A procedure to send an EAP message to the EAP state machine it
      interfaces to.

   void RtxTimerStart()

      A procedure to start the retransmission timer, reset RTX_COUNTER
      variable to zero and set an appropriate value to RTX_MAX_NUM
      variable.  Note that RTX_MAX_NUM is assumed to be set to the same
      default value for all messages.  However, implementations may also
      reset RTX_MAX_NUM in this procedure and its value may vary
      depending on the message that was sent.

   void RtxTimerStop()

      A procedure to stop the retransmission timer.

   void SessionTimerReStart(TIMEOUT)

      A procedure to (re)start PANA session timer.  TIMEOUT specifies
      the expiration time associated of the session timer.  Expiration
      of TIMEOUT will trigger a SESS_TIMEOUT event.

   void SessionTimerStop()

      A procedure to stop the current PANA session timer.

   void Retransmit()

      A procedure to retransmit a PANA message and increment RTX_COUNTER
      by one(1).

   void EAP_Restart()

      A procedure to (re)start an EAP conversation resulting in the re-
      initialization of an existing EAP session.

   void PANA_MESSAGE_NAME.insert_avp("AVP_NAME1", "AVP_NAME2",...)

      A procedure to insert AVPs for each specified AVP name in the list
      of AVP names in the PANA message.  When an AVP name ends with "*",
      zero, one or more AVPs are inserted, otherwise one AVP is
      inserted.

   boolean PANA_MESSAGE_NAME.exist_avp("AVP_NAME")

      A procedure that checks whether an AVP of the specified AVP name
      exists in the specified PANA message and returns TRUE if the
      specified AVP is found, otherwise returns FALSE.

   boolean generate_pana_sa()

      A procedure to check whether the EAP method being used generates
      keys and that a PANA SA will be established on successful
      authentication.  For the PaC, the procedure is also used to check
      and match the PRF and Integrity algorithm AVPs advertised by the
      PAA in PAR[S] message.  For the PAA, it is used to indicate
      whether a PRF and Integrity algorithm AVPs will be sent in the
      PAR[S].  This procedure will return true if a PANA SA will be
      generated.  Otherwise, it returns FALSE.

   boolean key_available()

      A procedure to check whether the PANA session has a PANA_AUTH_KEY.
      If the state machine already has a PANA_AUTH_KEY, it returns TRUE.
      If the state machine does not have a PANA_AUTH_KEY, it tries to
      retrieve an MSK from the EAP entity.  If an MSK is retrieved, it
      computes a PANA_AUTH_KEY from the MSK and returns TRUE.
      Otherwise, it returns FALSE.

6.2.  Common Variables

   PAR.RESULT_CODE

      This variable contains the Result-Code AVP value in the PANA-Auth-
      Request message in process.  When this variable carries
      PANA_SUCCESS it is assumed that the PAR message always contains an
      EAP-Payload AVP which carries an EAP-Success message.

   NONCE_SENT

      This variable is set to TRUE to indicate that a Nonce-AVP has
      already been sent.  Otherwise it is set to FALSE.

   RTX_COUNTER

      This variable contains the current number of retransmissions of
      the outstanding PANA message.

   Rx:PANA_MESSAGE_NAME[flag]

      This event variable is set to TRUE when the specified PANA message
      is received from its peering PANA entity.  The "flag" contains a
      flag (e.g., Rx:PAR[C]), except for 'R' (Request) flag.

   RTX_TIMEOUT

      This event variable is set to TRUE when the retransmission timer
      is expired.

   REAUTH

      This event variable is set to TRUE when an initiation of re-
      authentication phase is triggered.  This event variable can only
      be set while in the OPEN state.

   TERMINATE

      This event variable is set to TRUE when initiation of PANA session
      termination is triggered.  This event variable can only be set
      while in the OPEN state.

   PANA_PING

      This event variable is set to TRUE when initiation of liveness
      test based on PANA-Notification exchange is triggered.  This event
      variable can only be set while in the OPEN state.

   SESS_TIMEOUT

      This event is variable is set to TRUE when the session timer has
      expired.

   LIFETIME_SESS_TIMEOUT

      Configurable value used by the PaC and PAA to close or disconnect
      an established session in the access phase.  This variable
      indicates the expiration of the session and is set to the value of
      Session-Lifetime AVP if present in the last PANA-Auth-Request
      message in the case of the PaC.  Otherwise, it is assumed that the
      value is infinite and therefore has no expiration.  Expiration of
      LIFETIME_SESS_TIMEOUT will cause the event variable SESS_TIMEOUT
      to be set.

   ANY

      This event variable is set to TRUE when any event occurs.

6.3.  Configurable Values

   RTX_MAX_NUM

      Configurable maximum for how many retransmissions should be
      attempted before aborting.

6.4.  Common Message Initialization Rules

   When a message is prepared for sending, it is initialized as follows:

   o  For a request message, R-flag of the header is set.  Otherwise,
      R-flag is not set.

   o  Other message header flags are not set.  They are set explicitly
      by specific state machine actions.

   o  AVPs that are mandatory included in a message are inserted with
      appropriate values set.

6.5.  Common Retransmition Rules

   The state machines defined in this document assumes that the PaC and
   the PAA caches the last transmitted answer message.  This scheme is
   described in Sec 5.2 of [RFC5191].  When the PaC or PAA receives a
   re-transmitted or duplicate request, it would be able to re-send the
   corresponding answer without any aid from the EAP layer.  However, to
   simplify the state machine description, this caching scheme is
   omitted in the state machines below.  In the case that there is not
   corresponding answer to a re-transmitted request, the request will be
   handled by the corresponding statemachine.

6.6.  Common State Transitions

   The following transitions can occur at any state with exemptions
   explicitly noted.

   ----------
   State: ANY
   ----------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - (Re-transmissions)- - - - - - - - - -
   RTX_TIMEOUT &&           Retransmit();              (no change)
   RTX_COUNTER<
   RTX_MAX_NUM
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - (Reach maximum number of transmissions)- - - - - -
   (RTX_TIMEOUT &&          Disconnect();              CLOSED
    RTX_COUNTER>=
    RTX_MAX_NUM) ||
   SESS_TIMEOUT
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   -------------------------
   State: ANY except INITIAL
   -------------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - (liveness test initiated by peer)- - - - - -
   Rx:PNR[P]                Tx:PNA[P]();               (no change)

   -------------------------------
   State: ANY except WAIT_PNA_PING
   -------------------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - (liveness test response) - - - - - - - -
   Rx:PNA[P]                None();                    (no change)

   The following transitions can occur on any exit condition within the
   specified state.

   -------------
   State: CLOSED
   -------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - -(Catch all event on closed state) - - - - - - - -
   ANY                      None();                    CLOSED
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

7.  PaC State Machine

7.1.  Interface between PaC and EAP Peer

   This interface defines the interactions between a PaC and an EAP
   peer.  The interface serves as a mechanism to deliver EAP messages
   for the EAP peer.  It allows the EAP peer to receive EAP requests and
   send EAP responses via the PaC.  It also provides a mechanism to
   notify the EAP peer of PaC events and a mechanism to receive
   notification of EAP peer events.  The EAP message delivery mechanism
   as well as the event notification mechanism in this interface have
   direct correlation with the PaC state transition table entries.
   These message delivery and event notifications mechanisms occur only
   within the context of their associated states or exit actions.

7.1.1.  Delivering EAP Messages from PaC to EAP Peer

   TxEAP() procedure in the PaC state machine serves as the mechanism to
   deliver EAP messages contained in PANA-Auth-Request messages to the
   EAP peer.  This procedure is enabled only after an EAP restart event
   is notified to the EAP peer and before any event resulting in a
   termination of the EAP peer session.  In the case where the EAP peer
   follows the EAP peer state machine defined in [RFC4137], TxEAP()
   procedure sets eapReq variable of the EAP peer state machine and puts
   the EAP request in eapReqData variable of the EAP peer state machine.

7.1.2.  Delivering EAP Messages from EAP Peer to PaC

   An EAP message is delivered from the EAP peer to the PaC via
   EAP_RESPONSE event variable.  The event variable is set when the EAP
   peer passes the EAP message to its lower-layer.  In the case where
   the EAP peer follows the EAP peer state machine defined in [RFC4137],
   EAP_RESPONSE event variable refers to eapResp variable of the EAP
   peer state machine and the EAP message is contained in eapRespData
   variable of the EAP peer state machine.

7.1.3.  EAP Restart Notification from PaC to EAP Peer

   The EAP peer state machine defined in [RFC4137] has an initialization
   procedure before receiving an EAP message.  To initialize the EAP
   state machine, the PaC state machine defines an event notification
   mechanism to send an EAP (re)start event to the EAP peer.  The event
   notification is done via EAP_Restart() procedure in the
   initialization action of the PaC state machine.

7.1.4.  EAP Authentication Result Notification from EAP Peer to PaC

   In order for the EAP peer to notify the PaC of an EAP authentication
   result, EAP_SUCCESS and EAP_FAILURE event variables 15

1.  Introduction

   he main safety problems that are defined.  In
   the case where the EAP peer follows the EAP peer state machine
   defined in [RFC4137], EAP_SUCCESS and EAP_FAILURE event variables
   refer to eapSuccess and eapFail variables of the EAP peer state
   machine, respectively.  In this case, if EAP_SUCCESS event variable
   is set needed to TRUE and an MSK is generated by the EAP authentication
   method solve in use, eapKeyAvailable variable WSN are
   confidentiality, node authentication, message integrity,
   freshness etc. Public-key cryptosystem is set to TRUE and eapKeyData
   variable contains the MSK.  Note that EAP_SUCCESS and EAP_FAILURE
   event variables may be set to TRUE even before the PaC receives a PAR
   with a 'Complete' flag set from the PAA.

7.1.5.  Alternate Failure Notification from PaC to EAP Peer

   alt_reject() procedure in the PaC state machine serves as the
   mechanism to deliver an authentication failure event most extensive tool
   to solve the EAP peer
   without accompanying an EAP message.  In the case where the EAP peer
   follows the EAP peer state machine defined in [RFC4137], alt_reject()
   procedure sets altReject variable problem of information security. Many scholars have
   token research on the EAP peer state machine.
   Note that the EAP peer state machine in [RFC4137] also defines
   altAccept variable, however, it is never used in PANA in which EAP-
   Success messages are reliably delivered by the last PANA-Auth
   exchange.

7.2.  Configurable Values

   FAILED_SESS_TIMEOUT

      Configurable value that allows the PaC to determine whether a PaC
      authentication and authorization phase has stalled without an
      explicit EAP success or failure notification.

7.3.  Variables

   AUTH_USER

      This event variable is set to TRUE when initiation using of EAP-based
      (re-)authentication is triggered by the application.

   EAP_SUCCESS

      This event variable is set to TRUE when the EAP peer determines
      that EAP conversation completes with success.

   EAP_FAILURE

      This event variable is set to TRUE when the EAP peer determines
      that EAP conversation completes with failure.

   EAP_RESPONSE

      This event variable is set to TRUE when the EAP peer delivers an
      EAP message to the PaC.  This event accompanies an EAP message
      received from the EAP peer.

   EAP_RESP_TIMEOUT

      This event variable is set to TRUE when the PaC that has passed an
      EAP message to public key algorithm on sensor node,
   and obtained someachievements.

   Gura and his partner have realized the EAP-layer does not receive ECC and RSA
   algorithm on 8-bit microcontroller. R.Watro proposed a subsequent EAP
      message from TinyPK
   entity authentication schema based on the low exponent RSA algorithm.
   In 2006 the EAP-layer in a given period.  This provides a
      time limit for certain EAP methods where user interaction maybe
      required.

   EAP_DISCARD scholar of NCSU, An Liu and Peng Ning provided an
   Elliptic Curve Cryptography library TinyECC based on TinyOs. This event variable is set to TRUE when the EAP peer indicates
      that it has silently discarded the last received EAP-Request.
      This event does not accompany any EAP message.
   great progress. In 2007, based on TinyECC, Leonardo B and other four
   Brazil scholars realized the case where Tate paring on the EAP peer follows the EAP peer state machine defined in
      [RFC4137], sensor node, this event variable refers to eapNoResp.

7.4.  Procedures

   boolean eap_piggyback()

      This procedures returns TRUE to indicate whether the next EAP
      response will be carried in is
   the pending PAN message for
      optimization.

   void alt_reject()

      This procedure informs first implementation of Pairing-based cryptosystem on wireless
   sensor node. With the EAP peer increase of an hardware speed, use of public key
   cryptography in the sensors will become more and more common.
   Identity authentication failure
      event without accompanying an EAP message.

   void EAP_RespTimerStart()

      A procedure to start a timer to receive is an EAP-Response from the
      EAP peer.

   void EAP_RespTimerStop()

      A procedure to stop a timer effective way to receive an EAP-Response from solve the
      EAP peer.

7.5.  PaC State Transition Table

   ------------------------------
   State: INITIAL (Initial State)
   ------------------------------

   Initialization Action:

     NONCE_SENT=Unset;
     RTX_COUNTER=0;
     RtxTimerStop();

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+-----------
   - - - - - - - - - - (PaC-initiated Handshake) - - - - - - - - -
   AUTH_USER                Tx:PCI[]();                INITIAL
                            RtxTimerStart();
                            SessionTimerReStart
                              (FAILED_SESS_TIMEOUT);
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   - - - - - - -(PAA-initiated Handshake, not optimized) - - - - -
   Rx:PAR[S] &&             EAP_Restart();             WAIT_PAA
   !PAR.exist_avp           SessionTimerReStart
   ("EAP-Payload")              (FAILED_SESS_TIMEOUT);
                            if (generate_pana_sa())
                                Tx:PAN[S]("PRF-Algorithm",
                                   "Integrity-Algorithm");
                            else
                                Tx:PAN[S]();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - -
   Rx:PAR[S] &&             EAP_Restart();             INITIAL
   PAR.exist_avp            TxEAP();
   ("EAP-Payload") &&       SessionTimerReStart
   eap_piggyback()            (FAILED_SESS_TIMEOUT);

   Rx:PAR[S] &&             EAP_Restart();             WAIT_EAP_MSG
   PAR.exist_avp            TxEAP();
   ("EAP-Payload") &&       SessionTimerReStart
   !eap_piggyback()           (FAILED_SESS_TIMEOUT);
                            if (generate_pana_sa())
                                Tx:PAN[S]("PRF-Algorithm",
                                  "Integrity-Algorithm");
                            else
                                Tx:PAN[S]();

   EAP_RESPONSE             if (generate_pana_sa())    WAIT_PAA
                                Tx:PAN[S]("EAP-Payload",
                                  "PRF-Algorithm",
                                  "Integrity-Algorithm");
                            else
                                Tx:PAN[S]("EAP-Payload");
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   ---------------
   State: WAIT_PAA
   ---------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - - -(PAR-PAN exchange) - - - - - - - -
   Rx:PAR[] &&              RtxTimerStop();            WAIT_EAP_MSG
   !eap_piggyback()         TxEAP();
                            EAP_RespTimerStart();
                            if (NONCE_SENT==Unset) {
                              NONCE_SENT=Set;
                              Tx:PAN[]("Nonce");
                            }
                            else
                              Tx:PAN[]();

   Rx:PAR[] &&              RtxTimerStop();            WAIT_EAP_MSG
   eap_piggyback()          TxEAP();
                            EAP_RespTimerStart();

   Rx:PAN[]                 RtxTimerStop();            WAIT_PAA

   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - - - - - - -(PANA result) - - - - - - - - - -
   Rx:PAR[C] &&             TxEAP();                   WAIT_EAP_RESULT
   PAR.RESULT_CODE==
     PANA_SUCCESS

   Rx:PAR[C] &&             if (PAR.exist_avp          WAIT_EAP_RESULT_
   PAR.RESULT_CODE!=          ("EAP-Payload"))         CLOSE
     PANA_SUCCESS             TxEAP();
                            else
                               alt_reject();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   -------------------
   State: WAIT_EAP_MSG
   -------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - (Return PAN/PAR from EAP) - - - - - - - - -
   EAP_RESPONSE &&          EAP_RespTimerStop()        WAIT_PAA
   eap_piggyback()          if (NONCE_SENT==Unset) {
                              Tx:PAN[]("EAP-Payload",
                                       "Nonce");
                              NONCE_SENT=Set;
                            }
                            else
                              Tx:PAN[]("EAP-Payload");

   EAP_RESPONSE &&          EAP_RespTimerStop()        WAIT_PAA
   !eap_piggyback()         Tx:PAR[]("EAP-Payload");
                            RtxTimerStart();

   EAP_RESP_TIMEOUT &&      Tx:PAN[]();                WAIT_PAA
   eap_piggyback()

   EAP_DISCARD &&           Tx:PAN[]();                CLOSED
   eap_piggyback()          SessionTimerStop();
                            Disconnect();

   EAP_FAILURE ||           SessionTimerStop();        CLOSED
   (EAP_DISCARD &&          Disconnect();
   !eap_piggyback())
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   ----------------------
   State: WAIT_EAP_RESULT
   ----------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - (EAP Result) - - - - - - - - - - - - -
   EAP_SUCCESS             if (PAR.exist_avp           OPEN
                              ("Key-Id"))
                             Tx:PAN[C]("Key-Id");
                           else
                             Tx:PAN[C]();
                           Authorize();
                           SessionTimerReStart
                             (LIFETIME_SESS_TIMEOUT);

   EAP_FAILURE             Tx:PAN[C]();                CLOSED
                           SessionTimerStop();
                           Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   ----------------------------
   State: WAIT_EAP_RESULT_CLOSE
   ----------------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - (EAP Result) - - - - - - - - - - - - -
   EAP_SUCCESS ||          if (EAP_SUCCESS &&         CLOSED
   EAP_FAILURE               PAR.exist_avp("Key-Id"))
                             Tx:PAN[C]("Key-Id");
                           else
                             Tx:PAN[C]();
                           SessionTimerStop();
                           Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   -----------
   State: OPEN
   -----------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - (liveness test initiated by PaC)- - - - - -
   PANA_PING                Tx:PNR[P]();               WAIT_PNA_PING
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - (re-authentication initiated by PaC)- - - - - -
   REAUTH                   NONCE_SENT=Unset;          WAIT_PNA_REAUTH
                            Tx:PNR[A]();
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - (re-authentication initiated by PAA)- - - - - -
   Rx:PAR[]                 EAP_RespTimerStart();      WAIT_EAP_MSG
                            TxEAP();
                            if (!eap_piggyback())
                              Tx:PAN[]("Nonce");
                            else
                              NONCE_SENT=Unset;
                            SessionTimerReStart
                              (FAILED_SESS_TIMEOUT);
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - -(Session termination initiated by PAA) - - - - - -
   Rx:PTR[]                 Tx:PTA[]();                CLOSED
                            SessionTimerStop();
                            Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - -(Session termination initiated by PaC) - - - - - -
   TERMINATE                Tx:PTR[]();                SESS_TERM
                            RtxTimerStart();
                            SessionTimerStop();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   ----------------------
   State: WAIT_PNA_REAUTH
   ----------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - -(re-authentication initiated by PaC) - - - - -
   Rx:PNA[A]                RtxTimerStop();            WAIT_PAA
                            SessionTimerReStart
                              (FAILED_SESS_TIMEOUT);
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - -(Session termination initiated by PAA) - - - - - -
   Rx:PTR[]                 RtxTimerStop();            CLOSED
                            Tx:PTA[]();
                            SessionTimerStop();
                            Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   --------------------
   State: WAIT_PNA_PING
   --------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - -(liveness test initiated by PaC) - - - - - - -
   Rx:PNA[P]                RtxTimerStop();            OPEN
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - (re-authentication initiated by PAA)- - - - -
   Rx:PAR[]                 RtxTimerStop();            WAIT_EAP_MSG
                            EAP_RespTimerStart();
                            TxEAP();
                            if (!eap_piggyback())
                              Tx:PAN[]("Nonce");
                            else
                              NONCE_SENT=Unset;
                            SessionTimerReStart
                              (FAILED_SESS_TIMEOUT);
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - -(Session termination initiated by PAA) - - - - - -
   Rx:PTR[]                 RtxTimerStop();            CLOSED
                            Tx:PTA[]();
                            SessionTimerStop();
                            Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   ----------------
   State: SESS_TERM
   ----------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - -(Session termination initiated by PaC) - - - - -
   Rx:PTA[]                 Disconnect();              CLOSED
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

8.  PAA State Machine

8.1.  Interface between PAA and EAP Authenticator security
   issues of WSN.

   The interface between a PAA and an EAP authenticator provides a
   mechanism to deliver EAP messages for papers structure is: Section 2 describes the EAP authenticator theoretical
   background we use in this article, as well as the knowledge of the
   environment of the development platform. In section 3 based on the
   Tate Pairing, this paper designs a mechanism to notify safe and effective ID-based node
   authentication scheme. In The fourth quarter, this paper implements
   the authentication scheme, and analyzes its results. Finally,
   its the EAP authenticator conclusion and future outlook Overview of PAA events WSN and to
   receive notification
   Authentication.

2.  Terminology

3.  Overview of EAP authenticator events.  These message
   delivery ECC Encryption and event notification mechanisms occur only within context TinyOS

3.1 ECC Encryption

   The basement of their associated states or exit actions.

8.1.1.  EAP Restart Notification from PAA to EAP Authenticator

   An EAP authenticator state machine defined Elliptic Curve can be used in [RFC4137] has an
   initialization procedure before sending the first EAP request.  To
   initialize the EAP state machine, the PAA state machine defines an
   event notification mechanism to send an EAP (re)start event to the
   EAP authenticator. Public Key
   cryptosystem is: The event notification is done via EAP_Restart()
   procedure in the initialization action point set of Elliptic Curve defined on finite
   domain composite a circulatory loop. Then we can use the PAA state machine.

8.1.2.  Delivering EAP Responses from PAA to EAP Authenticator

   TxEAP() procedure in the PAA state machine serves as the mechanism to
   deliver EAP-Responses contained in PANA-Auth-Answer messages to discrete
   logarithm problem on the
   EAP authenticator.  This procedure is enabled only after an EAP
   restart event Elliptic Curve point set.Continuous
   Elliptic Curve is notified to the EAP authenticator not suitable for encryption and before any
   event resulting in a termination decryption.
   The ECC is based on discrete points.

3.2 TinyOS
3.2.1 Struce of TinyOS
   TinyOS is a Micro-OS designed by the EAP authenticator session.
   In the case where the EAP authenticator follows the EAP authenticator
   state machines defined in [RFC4137], TxEAP() procedure sets eapResp
   variable University of California,
   Berkeley,which is designed for the EAP authenticator state machine and puts the EAP
   response WSNs. Because there are many
   nodes in eapRespData variable WSN and most of them are work on concurrency, the EAP authenticator state
   machine.

8.1.3.  Delivering EAP Messages from EAP Authenticator to PAA

   An EAP request is delivered from OS
   adopts technologies of lightweight threads, active information
   communication, event-driven model and components-based programming,
   After the EAP authenticator study found that these technologies help to improve the PAA via
   EAP_REQUEST event variable.  The event variable is set when the EAP
   authenticator passes
   performance of wireless sensor networks, enjoy the EAP request advantage of
   hardware characteristics, lower power consumption and simplify
   application development. TinyOS uses component model. From bottom
   to up, its lower-layer.  In components can be divided into: abstract hardware
   components, composite components and high-level software
   components.

   TinyOS's high-level components send commands to the case
   where low-level
   components, and the EAP authenticator follows the EAP authenticator state
   machines defined in [RFC4137], EAP_REQUEST event variable refers low-level components report events to
   eapReq variable of
   high-level components. The whole structure looks like a Network
   protocol stack. The bottom level components are responsible to
   communicate with the EAP authenticator state machine hardware, send and receive the EAP
   request is contained in eapReqData variable of the EAP authenticator
   state machine.

8.1.4.  EAP Authentication Result Notification from EAP Authenticator to
        PAA

   In order for bit stream
   and map the EAP authenticator physic hardware to notify the PAA of TinyOS components (eg: RRM).
   The composite components simulate the EAP
   authentication result, EAP_SUCCESS, EAP_FAILURE and EAP_TIMEOUT event
   variables are defined.  In senior hardware behavior.Make
   the case where data communicate with the EAP authenticator
   follows the EAP authenticator state machines defined high-level components in [RFC4137],
   EAP_SUCCESS, EAP_FAILURE byte unit,
   and EAP_TIMEOUT event variables refer to
   eapSuccess, eapFail communicate with low-level in bit unit. It achieves the
   Encoding and eapTimeout variables of Decoding work in internal. The high-level software
   model achieves the EAP authenticator
   state machine, respectively.  In this case, if EAP_SUCCESS event
   variable control, route and data transmission.

3.2.2 NesC programming language

   TinyOS is Micro-OS code and realized with the NesC programming
   language. NesC's syntax is set similar to TRUE, C programming language,
   and it's a component-based programming language. It is an EAP-Success message
   extension of C language. A NesC application is contained in
   eapReqData variable consisted of
   many components connected together. These components include
   configuration components and module components. Every relatively
   independent hardware or software modules can be realized with one
   or more components to.
   TinyOS is built on such idea which makesthe application of the EAP authenticator state machine, and
   additionally, eapKeyAvailable variable
   system reductive.

   (1) Interface: Interface is set to TRUE two-way, defined many commands and eapKeyData
   variable contains
   events. Commands are realized by the providers and the active
   operation for an MSK if event is implements by the MSK users.

   (2) Configuration: The configuration is generated as a result of
   successful authentication by component which can
   be used to assemble the EAP authentication method in use.
   Similarly, if EAP_FAILURE event variable components. It is set used to TRUE, connect the
   various components of the interface providers and users. Such
   an EAP-
   Failure message act is contained in eapReqData variable of called conduction or wiring.

   (3) Module: Module provides the EAP
   authenticator state machine. application code, implemented
   one or more interfaces. The PAA uses EAP_SUCCESS realization of all methods is defined
   in this place. Inside the module, it defines the interface it
   provides and
   EAP_FAILURE event variables as a trigger to send a PAR message to used. And realizes the
   PaC.

8.2.  Variables

   OPTIMIZED_INIT

      This variable indicates whether commands in the PAA is able to piggyback an
      EAP-Request interface
   it provides and the events in the initial PANA-Auth-Request.  Otherwise interface it uses.

3.3 Introduction of TinyECC

   TinyECC is set
      to FALSE.

   PAC_FOUND

      This variable is set to TRUE as a result of code packet provided by a PAA initiated
      handshake.

   REAUTH_TIMEOUT

      This event variable is set to TRUE to indicate that the PAA
      initiates North Carolina State
   University develops team. It provides a re-authentication with base arithmetic
   operation of ECC on TinyOS. It provides all ECC operations
   on domain, including the PaC. point add, double and scalar
   multiplication.

3.3.1 System's main modules

  (1) NN module: The re-authentication
      timeout should be set to a value less than the session timeout
      carried methods in this module are modified from
      RSAREF2.0. It provides the Session-Lifetime AVP if present.

   EAP_SUCCESS

      This event variable is set to TRUE when EAP conversation completes
      with success.  This event accompanies realization of large numbers
      operations in different sensor nodes (Micaz and TELOSB).

  (2) ECC module: The ECC module provides many basic operations
      on elliptic curve. For example, initialization of an EAP- Success message
      passed from the EAP authenticator.

   EAP_FAILURE elliptic
      curve, point adding, point doubling, point scalar
      multiplication and some operations based on sliding window.

  (3) ECDSA module: This event variable module realized a signature protocol
      based on ECC.

   ECDSA is set based on ECC component, SHA1 hash component and NN
   component. It realized a signature protocol based on ECC.
   ECC is the core of TinyECC. It calls the CurveParam component
   to TRUE when EAP conversation completes
      with failure.  This event accompanies initialize an EAP- Failure message
      passed from Elliptic Curve and the EAP authenticator.

   EAP_REQUEST

      This event variable is set NN component to TRUE when realize
   the EAP authenticator
      delivers large number operations.

3.3.2 Working process

   (1) Initialize an EAP Request to the PAA.  This event accompanies elliptic curve: The TinyECC provides an
      EAP-Request message received from the EAP authenticator.

   EAP_TIMEOUT

      This event variable is set
       interface CurveParam to TRUE when EAP conversation times out
      without generating an EAP-Success or initialize an EAP-Failure message.  This
      event does not accompany any EAP message.

   EAP_DISCARD elliptic curve. This event variable is
       interface was implemented by secp128r1, secp128r2, secp160k1,
       secp160r2, secp160r2, secp192k1 and secp192r17, which defined
       7 elliptic curves with 128,160 and 192bits.

   (2) Base operations on elliptical curve: The ECC interface defined
       all base operations of the points set on elliptical curve,
       including the point add, double, scalar multiplication and
       optimized operation based on sliding window methods.
       For example, we can call ECC.win_mul(&myTb,RInv,&pointArray)
       to TRUE when EAP authenticator
      indicates that it has silently discarded the last received EAP-
      Response message. realize a scalar multiplication.

4.  Protocol Description

4.1 Flow and Structure

   This event does not accompany any EAP message.
      In section describes the case where the EAP authenticator follows the EAP
      authenticator state machines defined in [RFC4137], this event
      variable refers nodes authentication based on TinyECC.
   Based on TinyECC, we designed a simple node authentication protocol
   on WSNs to eapNoReq.

8.3.  Procedures

   boolean new_key_available() realize simple node authentication. The protocol can be
   divided into the following steps:

      Alice                                                     Bob
        |   1. A procedure selects random number a, and sends Ta=a*P to check whether the PANA session has a new
      PANA_AUTH_KEY.  If the state machine already have a PANA_AUTH_KEY,
      it returns FALSE.  If the state machine does not have a
      PANA_AUTH_KEY, it tries B. |
        +------------------------------------------------------->|
        |                                                        |
        |   2. B selects random number b, and sends Tb=b*P to retrieve an MSK from the EAP entity.
      If an MSK has been retrieved, it computes a PANA_AUTH_KEY from the
      MSK A. |
        |<-------------------------------------------------------+
        |                                                        |
        |   3. A calculates Tab=a*b*P, and returns TRUE.  Otherwise, it returns FALSE.

8.4.  PAA State Transition Table

   ------------------------------
   State: INITIAL (Initial State)
   ------------------------------

   Initialization Action:

     OPTIMIZED_INIT=Set|Unset;
     NONCE_SENT=Unset;
     RTX_COUNTER=0;
     RtxTimerStop();

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
    - - - - - - - - (PCI and PAA initiated PANA) - - - - - - - - -
   (Rx:PCI[] ||             if (OPTIMIZED_INIT ==      INITIAL
    PAC_FOUND)                  Set) {
                              EAP_Restart();
                              SessionTimerReStart
                               (FAILED_SESS_TIMEOUT);
                            }
                            else {
                              if (generate_pana_sa())
                                   Tx:PAR[S]("PRF-Algorithm",
                                      "Integrity-Algorithm");
                              else
                                   Tx:PAR[S]();
                            }

   EAP_REQUEST              if (generate_pana_sa())    INITIAL
                                Tx:PAR[S]("EAP-Payload",
                                   "PRF-Algorithm",
                                   "Integrity-Algorithm");
                            else
                                Tx:PAR[S]("EAP-Payload");
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   - - - - - - - - - - - - - - (PAN Handling)  - - - - - - - - - -
   Rx:PAN[S] &&             if (PAN.exist_avp          WAIT_EAP_MSG
   ((OPTIMIZED_INIT ==         ("EAP-Payload"))
     Unset) ||                TxEAP();
   PAN.exist_avp            else {
     ("EAP-Payload"))         EAP_Restart();
                              SessionTimerReStart
                               (FAILED_SESS_TIMEOUT);
                            }

   Rx:PAN[S] &&             None();                    WAIT_PAN_OR_PAR
   (OPTIMIZED_INIT ==
     Set) &&
   ! PAN.exist_avp
    ("EAP-Payload")

   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   -------------------
   State: WAIT_EAP_MSG
   -------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - -(Receiving EAP-Request)- - - - - - - - -
   EAP_REQUEST              if (NONCE_SENT==Unset) {   WAIT_PAN_OR_PAR
                              Tx:PAR[]("Nonce",
                                       "EAP-Payload");
                              NONCE_SENT=Set;
                            }
                            else
                              Tx:PAR[]("EAP-Payload");
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - - -(Receiving EAP-Success/Failure) - - - - -
   EAP_FAILURE              PAR.RESULT_CODE =          WAIT_FAIL_PAN
                              PANA_AUTHENTICATION_
                                  REJECTED;
                            Tx:PAR[C]("EAP-Payload");
                            RtxTimerStart();
                            SessionTimerStop();

   EAP_SUCCESS &&           PAR.RESULT_CODE =          WAIT_SUCC_PAN
   Authorize()                PANA_SUCCESS;
                            if (new_key_available())
                              Tx:PAR[C]("EAP-Payload",
                                   "Key-Id");
                            else
                              Tx:PAR[C]("EAP-Payload");
                            RtxTimerStart();

   EAP_SUCCESS &&           PAR.RESULT_CODE =          WAIT_FAIL_PAN
   !Authorize()               PANA_AUTHORIZATION_
                                REJECTED;
                            if (new_key_available())
                              Tx:PAR[C]("EAP-Payload",
                                   "Key-Id");
                            else
                              Tx:PAR[C]("EAP-Payload");
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - - - - (Receiving EAP-Timeout or invalid message) - - - - -
   EAP_TIMEOUT ||           SessionTimerStop();        CLOSED
   EAP_DISCARD              Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   --------------------
   State: WAIT_SUCC_PAN
   --------------------

   Event/Condition          Action                     Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - (PAN Processing)- - - - - - - - - - -
   Rx:PAN[C]                RtxTimerStop();            OPEN
                            SessionTimerReStart
                              (LIFETIME_SESS_TIMEOUT);
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   --------------------
   State: WAIT_FAIL_PAN
   --------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - - (PAN Processing)- - - - - - - - - -
   Rx:PAN[C]                RtxTimerStop();            CLOSED
                            Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   -----------
   State: OPEN
   -----------

   Event/Condition          Action                     Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - (re-authentication initiated by PaC) - - - - - -
   Rx:PNR[A]                NONCE_SENT=Unset;          WAIT_EAP_MSG
                            EAP_Restart();
                            Tx:PNA[A]();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - (re-authentication initiated by PAA)- - - - - -
   REAUTH ||                NONCE_SENT=Unset;          WAIT_EAP_MSG
   REAUTH_TIMEOUT           EAP_Restart();

   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - (liveness test based on PNR-PNA exchange initiated by PAA)-
   PANA_PING                Tx:PNR[P]();               WAIT_PNA_PING
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - (Session termination initated from PAA) - - - -
   TERMINATE                Tx:PTR[]();                SESS_TERM
                            SessionTimerStop();
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - (Session termination initated from PaC) - - - -
   Rx:PTR[]                 Tx:PTA[]();                CLOSED
                            SessionTimerStop();
                            Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   --------------------
   State: WAIT_PNA_PING
   --------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - -(PNA processing) - - - - - - - - - -
   Rx:PNA[P]                RtxTimerStop();            OPEN
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - (re-authentication initiated by PaC) - - - - - -
   Rx:PNR[A]                RtxTimerStop();            WAIT_EAP_MSG
                            NONCE_SENT=Unset;
                            EAP_Restart();
                            Tx:PNA[A]();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - (Session termination initated from PaC) - - - -
   Rx:PTR[]                 RtxTimerStop();            CLOSED
                            Tx:PTA[]();
                            SessionTimerStop();
                            Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   ----------------------
   State: WAIT_PAN_OR_PAR
   ----------------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - (PAR Processing)- - - - - - - - - - -
   Rx:PAR[]                 TxEAP();                   WAIT_EAP_MSG
                            RtxTimerStop();
                            Tx:PAN[]();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - (Pass EAP Response to the EAP authenticator)- - - -
   Rx:PAN[] &&              TxEAP();                   WAIT_EAP_MSG
   PAN.exist_avp            RtxTimerStop();
   ("EAP-Payload")
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - - (PAN without an EAP response) - - - - - - -
   Rx:PAN[] &&              RtxTimerStop();            WAIT_PAN_OR_PAR
   !PAN.exist_avp
   ("EAP-Payload")
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - - - -(EAP retransmission) - - - - - - - - - -
   EAP_REQUEST              RtxTimerStop();            WAIT_PAN_OR_PAR
                            Tx:PAR[]("EAP-Payload");
                            RtxTimerStart();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - (EAP authentication timeout or failure)- - - - -
   EAP_FAILURE ||           RtxTimerStop();            CLOSED
   EAP_TIMEOUT ||           SessionTimerStop();
   EAP_DISCARD              Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   ----------------
   State: SESS_TERM
   ----------------

   Exit Condition           Exit Action                Exit State
   ------------------------+--------------------------+------------
   - - - - - - - - - - - - - -(PTA processing) - - - - - - - - - -
   Rx:PTA[]                 RtxTimerStop();            CLOSED
                            Disconnect();
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

9.  Implementation Considerations

9.1.  PAA B.              |
        +------------------------------------------------------->|
        |                                                        |
        |   4. B calculates Tba=b*a*P, and PaC Interface to Service Management Entity

   In general, it is assumed each device or network equipment has a PANA to A.              |
        |<-------------------------------------------------------+
     A calculates Tb and verifies it.  B calculates Ta and verifies it.

4.2 Implementation

   This protocol stack available for use by other modules within the device
   or network equipment.  One such module is the Service Management
   Entity (SME). based on TinyECC. The call relation between
   components of this program can be described as:

                            main compoment
                              |       |
                             |        |
                            |         |
             base node compoment      |
               |      |      |        |
              |       |      |        |
             |        |      |        |
            |         |      |        |
           ECC        NN     Timer, Led, GenericComm
    The SME main component is a generic term for modules that manages
   different services (including network protocols) that installed on a
   device or equipment.  To integrate PANA protocol with entrance of this program. It provides
    the SME, it is
   recommended that a generic StdControl interface (i.e., which realizes some hardware initialization
    work. BaseNode is the SME-PANA interface)
   between core of the SME and program. It calls the PANA protocol stack be provided by Timer
    component to trigger event in times; calls the
   implementation.  This interface should include common procedures such
   as startup, shutdown and re-authenticate signals.  It should also
   provision for extracting keying material.  For Leds component to
    trigger indicators; uses the PAA, GenericComm component to send messages
    and receive messages; calls the SME-PANA
   interface should also provide a method for communicating filtering
   parameters ECC and NN components to realize the
    data encryption in the process of the protocol.

4.3 Analysis of Protocol

4.3.1 Performance Analysis

    For the protocol, the EP(s) when cryptographic filtering largest comustion is used. the point multiplication.
    The
   filtering parameters include keying material used number of computing for bootstrapping
   secured transport such both sides of communication show as IPsec.  When a PAA device interacts with
    table 1.

   +-------------------+----------------------------------+
   | Node              | Counts of Point multiplication   |
   +-------------------+----------------------------------+
   |         A         |   3                              |
   +-------------------+----------------------------------+
   |         B         |   3                              |
   +-------------------+----------------------------------+

                   Table 1: Number of Computing

   The protocol is Lightweight two-way authentication protocol. Though
   the three times of point multiplication, it completes the backend two-way
   authentication server using a AAA protocol, its SME may
   also provide an interface to and is based on the AAA protocol to ECDH.

4.3.2 Security Analysis

   Definition: Passive attack means that enemy just collects information
   in passive way, rather than obtain authorization
   parameters the data through active access.
   Data legitimate users would not be aware of such as activities. Passive
   attacks includesniffer, information-collecting etc.

   Conclusion: If the authorization lifetime and additional
   filtering parameters.

10.  Security Considerations

   This document's intent ECDH problem is to describe difficult on the PANA state machines fully.
   To this end, any security concerns with this document are likely a
   reflection of security concerns with PANA itself.

11. point group G,
   then the authentication scheme is secure against impersonation under
   passive attack.

5.  Security Considerations

5.1.  Privacy Considerations

6.  IANA Considerations

   This document has no actions for IANA.

12.  Acknowledgments does not propose a standard and does not require the
   PANA to do anything.

7.  Contributors

   This work was started from state machines originally draft is a product of a design team which also included Marcelo
   Bagnulo and Philip Matthews who both have made by Dan
   Forsberg.

13. major contributions to
   this document.

8.  Acknowledgments

   The following people have contributed to this document. Listing their
   names here does not mean that they endorse the document, but that
   they have contributed to its substance.

   Dujuan Yan, Sugang Bai, Liang Ge,

9.  References

13.1.

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.

13.2.

9.2.  Informative References

   [RFC4137]  Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
              "State Machines for Extensible Authentication Protocol
              (EAP) Peer and Authenticator", RFC 4137, August 2005.

Authors' Addresses

   Victor Fajardo (editor)
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Weihong Wang
   Zhejiang University of Technology, China

   Phone: +1 732 699 5368 +86 0571-85290115
   Email: vfajardo@tari.toshiba.com

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA wwh@zjut.edu.cn

   Tieming Chen
  Zhejiang University of Technology, China
   Phone: +1 732 699 5305 +86 0571-85290110
   Email:tiemingchen@gmail.com

   Yubing Lin
   Zhejiang University of Technology, China

   Phone: +86 0571-85290115
   Email: yohba@tari.toshiba.com

   Rafa Marin Lopez yulin@126.com

   Yiling Cui
   Zhejiang University of Murcia
   30071 Murcia
   Spain Technology, China

   Phone: +86 0571-85294110
   Email: rafa@dif.um.es cyllingling_00@126.com