draft-ietf-pana-statemachine-12.txt		draft-ietf-pana-statemachine-13.txt
			PANA Working Group Weihong Wang
			Internet-Draft Zhejiang University of Technology, China
			Intended status: Experimental Tieming Chen
			Expires: 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
	PANA Working Group V. Fajardo, Ed.		Basic Security Requirements of Authentication Protocol on Ad hoc
	Internet-Draft Y. Ohba		draft-ietf-pana-statemachine-13.txt
	Intended status: Informational TARI
	Expires: October 25, 2009 R. Lopez
	Univ. of Murcia
	April 23, 2009
	State Machines for Protocol for Carrying Authentication for Network
	Access (PANA)
	draft-ietf-pana-statemachine-12
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		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		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 25, 2009.		This Internet-Draft will expire on January 3, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	This document defines the conceptual state machines for the Protocol		This document specifies basic security standards for authentication
	for Carrying Authentication for Network Access (PANA). The state		protocol on Ad hoc. The security standards are based on the ECDH to
	machines consist of the PANA Client (PaC) state machine and the PANA		discover a authentication protocol between two nodes, and on the
	Authentication Agent (PAA) state machine. The two state machines		TinyOS simulation platform and Mica nodes. This document also
	show how PANA can interface with the EAP state machines. The state		defines elements of procedure for authentication protocol, including
	machines and associated model are informative only. Implementations		System Initialization, Key extract and the identity authentication.
	may achieve the same results using different methods.		With these standards, authentication between two nodes can be
			completed in a certain time and a certain circles.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Interface Between PANA and EAP . . . . . . . . . . . . . . . . 6		3. Overview of ECC Encryption and TinyOS . . . . . . . . . . . . 5
	4. Document Authority . . . . . . . . . . . . . . . . . . . . . . 8		3.1. ECC Encryption . . . . . . . . . . . . . . . . . . . . . . 5
	5. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.2.1 Struce of TinyOS. . . . . . . . . . . . . . . . . . . . 6
	6.1. Common Procedures . . . . . . . . . . . . . . . . . . . . 11		3.2.2 NesC programming language . . . . . . . . . . . . . . . 7
	6.2. Common Variables . . . . . . . . . . . . . . . . . . . . . 13		3.3 Introduction of TinyECC. . . . . . . . . . . . . . . . . . . 8
	6.3. Configurable Values . . . . . . . . . . . . . . . . . . . 15		3.3.1 System's main modules . . . . . . . . . . . . . . . . . 8
	6.4. Common Message Initialization Rules . . . . . . . . . . . 15		3.3.2 Working process . . . . . . . . . . . . . . . . . . . . 8
	6.5. Common Retransmition Rules . . . . . . . . . . . . . . . . 15		4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
	6.6. Common State Transitions . . . . . . . . . . . . . . . . . 15		4.1. Flow and Structure . . . . . . . . . . . . . . . . . . . . 9
	7. PaC State Machine . . . . . . . . . . . . . . . . . . . . . . 18		4.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Interface between PaC and EAP Peer . . . . . . . . . . . . 18		4.3. Analysis of Protocol . . . . . . . . . . . . . . . . . . . 10
	7.1.1. Delivering EAP Messages from PaC to EAP Peer . . . . . 18		4.3.1 Performance Analysis . . . . . . . . . . . . . . . . . 10
	7.1.2. Delivering EAP Messages from EAP Peer to PaC . . . . . 18		4.3.2 Security Analysis . . . . . . . . . . . . . . . . . . . 11
	7.1.3. EAP Restart Notification from PaC to EAP Peer . . . . 18		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7.1.4. EAP Authentication Result Notification from EAP		5.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 11
	Peer to PaC . . . . . . . . . . . . . . . . . . . . . 19		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7.1.5. Alternate Failure Notification from PaC to EAP Peer . 19		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Configurable Values . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	7.3. Variables . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	7.5. PaC State Transition Table . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	8. PAA State Machine . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Interface between PAA and EAP Authenticator . . . . . . . 27
	8.1.1. EAP Restart Notification from PAA to EAP
	Authenticator . . . . . . . . . . . . . . . . . . . . 27
	8.1.2. Delivering EAP Responses from PAA to EAP
	Authenticator . . . . . . . . . . . . . . . . . . . . 27
	8.1.3. Delivering EAP Messages from EAP Authenticator to
	PAA . . . . . . . . . . . . . . . . . . . . . . . . . 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		1. Introduction
	This document defines the state machines for Protocol Carrying		he main safety problems that are needed to solve in WSN are
	Authentication for Network Access (PANA) [RFC5191]. There are state		confidentiality, node authentication, message integrity,
	machines for the PANA client (PaC) and for the PANA Authentication		freshness etc. Public-key cryptosystem is the most extensive tool
	Agent (PAA). Each state machine is specified through a set of		to solve the problem of information security. Many scholars have
	variables, procedures and a state transition table. The state		token research on the using of public key algorithm on sensor node,
	machines and associated models described in this document are		and obtained someachievements.
	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		Gura and his partner have realized the ECC and RSA
	document. Additional information can be found in [RFC4137].		algorithm on 8-bit microcontroller. R.Watro proposed a TinyPK
	Nevertheless PANA state machines presented here have been coordinated		entity authentication schema based on the low exponent RSA algorithm.
	with state machines shown by [RFC4137].		In 2006 the scholar of NCSU, An Liu and Peng Ning provided an
			Elliptic Curve Cryptography library TinyECC based on TinyOs. This is
			great progress. In 2007, based on TinyECC, Leonardo B and other four
			Brazil scholars realized the Tate paring on the sensor node, this is
			the first implementation of Pairing-based cryptosystem on wireless
			sensor node. With the increase of hardware speed, use of public key
			cryptography in the sensors will become more and more common.
			Identity authentication is an effective way to solve the security
			issues of WSN.
	This document, apart from defining PaC and PAA state machines and		The papers structure is: Section 2 describes the theoretical
	their interfaces to EAP state machines (running on top of PANA),		background we use in this article, as well as the knowledge of the
	provides some implementation considerations, taking into account that		environment of the development platform. In section 3 based on the
	it is not a specification but an implementation guideline.		Tate Pairing, this paper designs a 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 conclusion and future outlook Overview of WSN and
			Authentication.
	2. Terminology		2. Terminology
	This document reuses the terminology used in [RFC5191].		3. Overview of ECC Encryption and TinyOS
	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 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 to TRUE and an MSK is generated by the EAP authentication
	method in use, eapKeyAvailable variable 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 to 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 of 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 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 the EAP-layer does not receive a subsequent EAP
	message from the the EAP-layer in a given period. This provides a
	time limit for certain EAP methods where user interaction maybe
	required.
	EAP_DISCARD
	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. In the case where
	the EAP peer follows the EAP peer state machine defined in
	[RFC4137], 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 the pending PAN message for
	optimization.
	void alt_reject()
	This procedure informs the EAP peer of an authentication failure
	event without accompanying an EAP message.
	void EAP_RespTimerStart()
	A procedure to start a timer to receive an EAP-Response from the
	EAP peer.
	void EAP_RespTimerStop()
	A procedure to stop a timer to receive an EAP-Response from 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
	The interface between a PAA and an EAP authenticator provides a
	mechanism to deliver EAP messages for the EAP authenticator as well
	as a mechanism to notify the EAP authenticator of PAA events and to
	receive notification of EAP authenticator events. These message
	delivery and event notification mechanisms occur only within context
	of their associated states or exit actions.
	8.1.1. EAP Restart Notification from PAA to EAP Authenticator
	An EAP authenticator state machine defined 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. The event notification is done via EAP_Restart()
	procedure in the initialization action of 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 the
	EAP authenticator. This procedure is enabled only after an EAP
	restart event is notified to the EAP authenticator and before any
	event resulting in a termination of 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 of the EAP authenticator state machine and puts the EAP
	response in eapRespData variable of the EAP authenticator state
	machine.
	8.1.3. Delivering EAP Messages from EAP Authenticator to PAA
	An EAP request is delivered from the EAP authenticator to the PAA via
	EAP_REQUEST event variable. The event variable is set when the EAP
	authenticator passes the EAP request to its lower-layer. In the case
	where the EAP authenticator follows the EAP authenticator state
	machines defined in [RFC4137], EAP_REQUEST event variable refers to
	eapReq variable of the EAP authenticator state machine and 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 the EAP authenticator to notify the PAA of the EAP
	authentication result, EAP_SUCCESS, EAP_FAILURE and EAP_TIMEOUT event
	variables are defined. In the case where the EAP authenticator
	follows the EAP authenticator state machines defined in [RFC4137],
	EAP_SUCCESS, EAP_FAILURE and EAP_TIMEOUT event variables refer to
	eapSuccess, eapFail and eapTimeout variables of the EAP authenticator
	state machine, respectively. In this case, if EAP_SUCCESS event
	variable is set to TRUE, an EAP-Success message is contained in
	eapReqData variable of the EAP authenticator state machine, and
	additionally, eapKeyAvailable variable is set to TRUE and eapKeyData
	variable contains an MSK if the MSK is generated as a result of
	successful authentication by the EAP authentication method in use.
	Similarly, if EAP_FAILURE event variable is set to TRUE, an EAP-
	Failure message is contained in eapReqData variable of the EAP
	authenticator state machine. The PAA uses EAP_SUCCESS and
	EAP_FAILURE event variables as a trigger to send a PAR message to the
	PaC.
	8.2. Variables
	OPTIMIZED_INIT
	This variable indicates whether the PAA is able to piggyback an
	EAP-Request in the initial PANA-Auth-Request. Otherwise it is set
	to FALSE.
	PAC_FOUND
	This variable is set to TRUE as a result of a PAA initiated
	handshake.
	REAUTH_TIMEOUT
	This event variable is set to TRUE to indicate that the PAA
	initiates a re-authentication with the PaC. The re-authentication
	timeout should be set to a value less than the session timeout
	carried in the Session-Lifetime AVP if present.
	EAP_SUCCESS
	This event variable is set to TRUE when EAP conversation completes
	with success. This event accompanies an EAP- Success message
	passed from the EAP authenticator.
	EAP_FAILURE
	This event variable is set to TRUE when EAP conversation completes
	with failure. This event accompanies an EAP- Failure message
	passed from the EAP authenticator.
	EAP_REQUEST
	This event variable is set to TRUE when the EAP authenticator
	delivers an EAP Request to the PAA. This event accompanies an
	EAP-Request message received from the EAP authenticator.
	EAP_TIMEOUT		3.1 ECC Encryption
	This event variable is set to TRUE when EAP conversation times out		The basement of Elliptic Curve can be used in Public Key
	without generating an EAP-Success or an EAP-Failure message. This		cryptosystem is: The point set of Elliptic Curve defined on finite
	event does not accompany any EAP message.		domain composite a circulatory loop. Then we can use the discrete
			logarithm problem on the Elliptic Curve point set.Continuous
			Elliptic Curve is not suitable for encryption and decryption.
			The ECC is based on discrete points.
	EAP_DISCARD		3.2 TinyOS
			3.2.1 Struce of TinyOS
			TinyOS is a Micro-OS designed by the University of California,
			Berkeley,which is designed for the WSNs. Because there are many
			nodes in WSN and most of them are work on concurrency, the OS
			adopts technologies of lightweight threads, active information
			communication, event-driven model and components-based programming,
			After the study found that these technologies help to improve the
			performance of wireless sensor networks, enjoy the advantage of
			hardware characteristics, lower power consumption and simplify
			application development. TinyOS uses component model. From bottom
			to up, its components can be divided into: abstract hardware
			components, composite components and high-level software
			components.
	This event variable is set to TRUE when EAP authenticator		TinyOS's high-level components send commands to the low-level
	indicates that it has silently discarded the last received EAP-		components, and the low-level components report events to
	Response message. This event does not accompany any EAP message.		high-level components. The whole structure looks like a Network
	In the case where the EAP authenticator follows the EAP		protocol stack. The bottom level components are responsible to
	authenticator state machines defined in [RFC4137], this event		communicate with the hardware, send and receive the bit stream
	variable refers to eapNoReq.		and map the physic hardware to the TinyOS components (eg: RRM).
			The composite components simulate the senior hardware behavior.Make
			the data communicate with the high-level components in byte unit,
			and communicate with low-level in bit unit. It achieves the
			Encoding and Decoding work in internal. The high-level software
			model achieves the control, route and data transmission.
	8.3. Procedures		3.2.2 NesC programming language
	boolean new_key_available()		TinyOS is Micro-OS code and realized with the NesC programming
			language. NesC's syntax is similar to C programming language,
			and it's a component-based programming language. It is an
			extension of C language. A NesC application is 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
			system reductive.
	A procedure to check whether the PANA session has a new		(1) Interface: Interface is two-way, defined many commands and
	PANA_AUTH_KEY. If the state machine already have a PANA_AUTH_KEY,		events. Commands are realized by the providers and the active
	it returns FALSE. If the state machine does not have a		operation for an event is implements by the users.
	PANA_AUTH_KEY, it tries to retrieve an MSK from the EAP entity.
	If an MSK has been retrieved, it computes a PANA_AUTH_KEY from the
	MSK and returns TRUE. Otherwise, it returns FALSE.
	8.4. PAA State Transition Table		(2) Configuration: The configuration is a component which can
			be used to assemble the components. It is used to connect the
			various components of the interface providers and users. Such
			an act is called conduction or wiring.
	------------------------------		(3) Module: Module provides the application code, implemented
	State: INITIAL (Initial State)		one or more interfaces. The realization of all methods is defined
	------------------------------		in this place. Inside the module, it defines the interface it
			provides and used. And realizes the commands in the interface
			it provides and the events in the interface it uses.
	Initialization Action:		3.3 Introduction of TinyECC
	OPTIMIZED_INIT=Set|Unset;		TinyECC is a code packet provided by a North Carolina State
	NONCE_SENT=Unset;		University develops team. It provides a base arithmetic
	RTX_COUNTER=0;		operation of ECC on TinyOS. It provides all ECC operations
	RtxTimerStop();		on domain, including the point add, double and scalar
			multiplication.
	Exit Condition Exit Action Exit State		3.3.1 System's main modules
	------------------------+--------------------------+------------
	- - - - - - - - (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		(1) NN module: The methods in this module are modified from
	Tx:PAR[S]("EAP-Payload",		RSAREF2.0. It provides the realization of large numbers
	"PRF-Algorithm",		operations in different sensor nodes (Micaz and TELOSB).
	"Integrity-Algorithm");
	else
	Tx:PAR[S]("EAP-Payload");
	RtxTimerStart();
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	- - - - - - - - - - - - - - (PAN Handling) - - - - - - - - - -		(2) ECC module: The ECC module provides many basic operations
	Rx:PAN[S] && if (PAN.exist_avp WAIT_EAP_MSG		on elliptic curve. For example, initialization of an elliptic
	((OPTIMIZED_INIT == ("EAP-Payload"))		curve, point adding, point doubling, point scalar
	Unset) || TxEAP();		multiplication and some operations based on sliding window.
	PAN.exist_avp else {
	("EAP-Payload")) EAP_Restart();
	SessionTimerReStart
	(FAILED_SESS_TIMEOUT);
	}
	Rx:PAN[S] && None(); WAIT_PAN_OR_PAR		(3) ECDSA module: This module realized a signature protocol
	(OPTIMIZED_INIT ==		based on ECC.
	Set) &&
	! PAN.exist_avp
	("EAP-Payload")
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -		ECDSA is 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 initialize an Elliptic Curve and the NN component to realize
			the large number operations.
	-------------------		3.3.2 Working process
	State: WAIT_EAP_MSG
	-------------------
	Exit Condition Exit Action Exit State		(1) Initialize an elliptic curve: The TinyECC provides an
	------------------------+--------------------------+------------		interface CurveParam to initialize an elliptic curve. This
	- - - - - - - - - - - -(Receiving EAP-Request)- - - - - - - - -		interface was implemented by secp128r1, secp128r2, secp160k1,
	EAP_REQUEST if (NONCE_SENT==Unset) { WAIT_PAN_OR_PAR		secp160r2, secp160r2, secp192k1 and secp192r17, which defined
	Tx:PAR[]("Nonce",		7 elliptic curves with 128,160 and 192bits.
	"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		(2) Base operations on elliptical curve: The ECC interface defined
	Authorize() PANA_SUCCESS;		all base operations of the points set on elliptical curve,
	if (new_key_available())		including the point add, double, scalar multiplication and
	Tx:PAR[C]("EAP-Payload",		optimized operation based on sliding window methods.
	"Key-Id");		For example, we can call ECC.win_mul(&myTb,RInv,&pointArray)
	else		to realize a scalar multiplication.
	Tx:PAR[C]("EAP-Payload");
	RtxTimerStart();
	EAP_SUCCESS && PAR.RESULT_CODE = WAIT_FAIL_PAN		4. Protocol Description
	!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();
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	--------------------		4.1 Flow and Structure
	State: WAIT_SUCC_PAN
	--------------------
	Event/Condition Action Exit State		This section describes the nodes authentication based on TinyECC.
	------------------------+--------------------------+------------		Based on TinyECC, we designed a simple node authentication protocol
	- - - - - - - - - - - - - (PAN Processing)- - - - - - - - - - -		on WSNs to realize simple node authentication. The protocol can be
	Rx:PAN[C] RtxTimerStop(); OPEN		divided into the following steps:
	SessionTimerReStart
	(LIFETIME_SESS_TIMEOUT);
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	--------------------		Alice Bob
	State: WAIT_FAIL_PAN		| 1. A selects random number a, and sends Ta=a*P to B. |
	--------------------		+------------------------------------------------------->|
			| |
			| 2. B selects random number b, and sends Tb=b*P to A. |
			|<-------------------------------------------------------+
			| |
			| 3. A calculates Tab=a*b*P, and it to B. |
			+------------------------------------------------------->|
			| |
			| 4. B calculates Tba=b*a*P, and it to A. |
			|<-------------------------------------------------------+
			A calculates Tb and verifies it. B calculates Ta and verifies it.
	Exit Condition Exit Action Exit State		4.2 Implementation
	------------------------+--------------------------+------------
	- - - - - - - - - - - - - - (PAN Processing)- - - - - - - - - -
	Rx:PAN[C] RtxTimerStop(); CLOSED
	Disconnect();
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	-----------		This protocol is based on TinyECC. The call relation between
	State: OPEN		components of this program can be described as:
	-----------
	Event/Condition Action Exit State		main compoment
	------------------------+--------------------------+------------		| |
	- - - - - - - - (re-authentication initiated by PaC) - - - - - -		| |
	Rx:PNR[A] NONCE_SENT=Unset; WAIT_EAP_MSG		| |
	EAP_Restart();		base node compoment |
	Tx:PNA[A]();		| | | |
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -		| | | |
	- - - - - - - - (re-authentication initiated by PAA)- - - - - -		| | | |
	REAUTH || NONCE_SENT=Unset; WAIT_EAP_MSG		| | | |
	REAUTH_TIMEOUT EAP_Restart();		ECC NN Timer, Led, GenericComm
			The main component is entrance of this program. It provides
			the StdControl interface which realizes some hardware initialization
			work. BaseNode is the core of the program. It calls the Timer
			component to trigger event in times; calls the Leds component to
			trigger indicators; uses the GenericComm component to send messages
			and receive messages; calls the ECC and NN components to realize the
			data encryption in the process of the protocol.
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -		4.3 Analysis of Protocol
	- - (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();
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	--------------------		4.3.1 Performance Analysis
	State: WAIT_PNA_PING
	--------------------
	Exit Condition Exit Action Exit State		For the protocol, the largest comustion is the point multiplication.
	------------------------+--------------------------+------------		The number of computing for both sides of communication show as
	- - - - - - - - - - - - - -(PNA processing) - - - - - - - - - -		table 1.
	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		| Node | Counts of Point multiplication |
	----------------------		+-------------------+----------------------------------+
			| A | 3 |
			+-------------------+----------------------------------+
			| B | 3 |
			+-------------------+----------------------------------+
	Exit Condition Exit Action Exit State		Table 1: Number of Computing
	------------------------+--------------------------+------------
	- - - - - - - - - - - - - (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();
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	----------------		The protocol is Lightweight two-way authentication protocol. Though
	State: SESS_TERM		the three times of point multiplication, it completes the two-way
	----------------		authentication and is based on the ECDH.
	Exit Condition Exit Action Exit State		4.3.2 Security Analysis
	------------------------+--------------------------+------------
	- - - - - - - - - - - - - -(PTA processing) - - - - - - - - - -
	Rx:PTA[] RtxTimerStop(); CLOSED
	Disconnect();
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	9. Implementation Considerations		Definition: Passive attack means that enemy just collects information
			in passive way, rather than obtain the data through active access.
			Data legitimate users would not be aware of such activities. Passive
			attacks includesniffer, information-collecting etc.
	9.1. PAA and PaC Interface to Service Management Entity		Conclusion: If the ECDH problem is difficult on the point group G,
			then the authentication scheme is secure against impersonation under
			passive attack.
	In general, it is assumed each device or network equipment has a PANA		5. Security Considerations
	protocol stack available for use by other modules within the device
	or network equipment. One such module is the Service Management
	Entity (SME). The SME 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 the SME, it is
	recommended that a generic interface (i.e., the SME-PANA interface)
	between the SME and the PANA protocol stack be provided by 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 the PAA, the SME-PANA
	interface should also provide a method for communicating filtering
	parameters to the EP(s) when cryptographic filtering is used. The
	filtering parameters include keying material used for bootstrapping
	secured transport such as IPsec. When a PAA device interacts with
	the backend authentication server using a AAA protocol, its SME may
	also provide an interface to the AAA protocol to obtain authorization
	parameters such as the authorization lifetime and additional
	filtering parameters.
	10. Security Considerations		5.1. Privacy Considerations
	This document's intent is to describe the PANA state machines fully.		6. IANA Considerations
	To this end, any security concerns with this document are likely a
	reflection of security concerns with PANA itself.
	11. IANA Considerations		This document does not propose a standard and does not require the
			PANA to do anything.
	This document has no actions for IANA.		7. Contributors
	12. Acknowledgments		This draft is a product of a design team which also included Marcelo
			Bagnulo and Philip Matthews who both have made major contributions to
			this document.
	This work was started from state machines originally made by Dan		8. Acknowledgments
	Forsberg.
	13. References		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.
	13.1. Normative References		Dujuan Yan, Sugang Bai, Liang Ge,
	[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.		9. References
	Yegin, "Protocol for Carrying Authentication for Network
	Access (PANA)", RFC 5191, May 2008.
	13.2. Informative References		9.1. Normative References
	[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,		9.2. Informative References
	"State Machines for Extensible Authentication Protocol
	(EAP) Peer and Authenticator", RFC 4137, August 2005.
	Authors' Addresses		Authors' Addresses
	Victor Fajardo (editor)		Weihong Wang
	Toshiba America Research, Inc.		Zhejiang University of Technology, China
	1 Telcordia Drive
	Piscataway, NJ 08854
	USA
	Phone: +1 732 699 5368		Phone: +86 0571-85290115
	Email: vfajardo@tari.toshiba.com		Email: wwh@zjut.edu.cn
	Yoshihiro Ohba		Tieming Chen
	Toshiba America Research, Inc.		Zhejiang University of Technology, China
	1 Telcordia Drive		Phone: +86 0571-85290110
	Piscataway, NJ 08854		Email:tiemingchen@gmail.com
	USA
	Phone: +1 732 699 5305		Yubing Lin
	Email: yohba@tari.toshiba.com		Zhejiang University of Technology, China
	Rafa Marin Lopez		Phone: +86 0571-85290115
	University of Murcia		Email: yulin@126.com
	30071 Murcia
	Spain
	Email: rafa@dif.um.es		Yiling Cui
			Zhejiang University of Technology, China
			Phone: +86 0571-85294110
			Email: cyllingling_00@126.com
End of changes. 63 change blocks.
	1265 lines changed or deleted		263 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/