draft-ietf-pana-statemachine-13.txt		rfc5609.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
	Basic Security Requirements of Authentication Protocol on Ad hoc
	draft-ietf-pana-statemachine-13.txt
	Status of this Memo		Network Working Group V. Fajardo, Ed.
			Request for Comments: 5609 Telcordia Technologies
	This Internet-Draft is submitted to IETF in full conformance with the		Category: Informational Y. Ohba
	provisions of BCP 78 and BCP 79. This document may contain material		Toshiba
	from IETF Documents or IETF Contributions published or made publicly		R. Marin-Lopez
	available before November 10, 2008. The person(s) controlling the		Univ. of Murcia
	copyright in some of this material may not have granted the IETF		August 2009
	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		State Machines for
	Task Force (IETF), its areas, and its working groups. Note that		the Protocol for Carrying Authentication for Network Access (PANA)
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Abstract
	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		This document defines the conceptual state machines for the Protocol
	http://www.ietf.org/ietf/1id-abstracts.txt.		for Carrying Authentication for Network Access (PANA). The state
			machines consist of the PANA Client (PaC) state machine and the PANA
			Authentication Agent (PAA) state machine. The two state machines
			show how PANA can interface with the Extensible Authentication
			Protocol (EAP) state machines. The state machines and associated
			models are informative only. Implementations may achieve the same
			results using different methods.
	The list of Internet-Draft Shadow Directories can be accessed at		Status of This Memo
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 3, 2010.		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	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
	This document specifies basic security standards for authentication
	protocol on Ad hoc. The security standards are based on the ECDH to
	discover a authentication protocol between two nodes, and on 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 nodes can be
	completed in a certain time and a certain circles.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction ....................................................3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology .....................................................3
	3. Overview of ECC Encryption and TinyOS . . . . . . . . . . . . 5		3. Interface between PANA and EAP ..................................3
	3.1. ECC Encryption . . . . . . . . . . . . . . . . . . . . . . 5		4. Document Authority ..............................................5
	3.2. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Notations .......................................................5
	3.2.1 Struce of TinyOS. . . . . . . . . . . . . . . . . . . . 6		6. Common Rules ....................................................6
	3.2.2 NesC programming language . . . . . . . . . . . . . . . 7		6.1. Common Procedures ..........................................6
	3.3 Introduction of TinyECC. . . . . . . . . . . . . . . . . . . 8		6.2. Common Variables ...........................................9
	3.3.1 System's main modules . . . . . . . . . . . . . . . . . 8		6.3. Configurable Values .......................................10
	3.3.2 Working process . . . . . . . . . . . . . . . . . . . . 8		6.4. Common Message Initialization Rules .......................10
	4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9		6.5. Common Retransmission Rules ...............................10
	4.1. Flow and Structure . . . . . . . . . . . . . . . . . . . . 9		6.6. Common State Transitions ..................................11
	4.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 9		7. PaC State Machine ..............................................12
	4.3. Analysis of Protocol . . . . . . . . . . . . . . . . . . . 10		7.1. Interface between PaC and EAP Peer ........................12
	4.3.1 Performance Analysis . . . . . . . . . . . . . . . . . 10		7.1.1. Delivering EAP Messages from PaC to EAP Peer .......12
	4.3.2 Security Analysis . . . . . . . . . . . . . . . . . . . 11		7.1.2. Delivering EAP Messages from EAP Peer to PaC .......12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7.1.3. EAP Restart Notification from PaC to EAP Peer ......13
	5.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 11		7.1.4. EAP Authentication Result Notification from
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		EAP Peer to PaC ....................................13
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12		7.1.5. Alternate Failure Notification from PaC to
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		EAP Peer ...........................................13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.2. Configurable Values .......................................13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		7.3. Variables .................................................14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		7.4. Procedures ................................................15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		7.5. PaC State Transition Table ................................15
			8. PAA State Machine ..............................................21
			8.1. Interface between PAA and EAP Authenticator ...............21
			8.1.1. EAP Restart Notification from PAA to EAP
			Authenticator ......................................21
			8.1.2. Delivering EAP Responses from PAA to EAP
			Authenticator ......................................22
			8.1.3. Delivering EAP Messages from EAP
			Authenticator to PAA ...............................22
			8.1.4. EAP Authentication Result Notification from
			EAP Authenticator to PAA ...........................22
			8.2. Variables .................................................23
			8.3. Procedures ................................................24
			8.4. PAA State Transition Table ................................24
			9. Implementation Considerations ..................................29
			9.1. PAA and PaC Interface to Service Management Entity ........29
			10. Security Considerations .......................................29
			11. Acknowledgments ...............................................29
			12. References ....................................................29
			12.1. Normative References .....................................29
			12.2. Informative References ...................................30
	1. Introduction		1. Introduction
	he main safety problems that are needed to solve in WSN are		This document defines the state machines for the Protocol for
	confidentiality, node authentication, message integrity,		Carrying Authentication for Network Access (PANA) [RFC5191]. There
	freshness etc. Public-key cryptosystem is the most extensive tool		are state machines for the PANA Client (PaC) and for the PANA
	to solve the problem of information security. Many scholars have		Authentication Agent (PAA). Each state machine is specified through
	token research on the using of public key algorithm on sensor node,		a set of variables, procedures, and a state transition table. The
	and obtained someachievements.		state machines and associated models described in this document are
			informative only. Implementations may achieve similar results using
			different models and/or methods.
	Gura and his partner have realized the ECC and RSA		A PANA protocol execution consists of several exchanges to carry
	algorithm on 8-bit microcontroller. R.Watro proposed a TinyPK		authentication information. Specifically, EAP PDUs are transported
	entity authentication schema based on the low exponent RSA algorithm.		inside PANA PDUs between PaC and PAA; that is, PANA represents a
	In 2006 the scholar of NCSU, An Liu and Peng Ning provided an		lower layer for EAP. Thus, a PANA state machine bases its execution
	Elliptic Curve Cryptography library TinyECC based on TinyOs. This is		on an EAP state machine execution and vice versa. Thus, this
	great progress. In 2007, based on TinyECC, Leonardo B and other four		document also shows for each of PaC and PAA an interface between an
	Brazil scholars realized the Tate paring on the sensor node, this is		EAP state machine and a PANA state machine and how this interface
	the first implementation of Pairing-based cryptosystem on wireless		allows to exchange information between them. Thanks to this
	sensor node. With the increase of hardware speed, use of public key		interface, a PANA state machine can be informed about several events
	cryptography in the sensors will become more and more common.		generated in an EAP state machine and make its execution conditional
	Identity authentication is an effective way to solve the security		to its events.
	issues of WSN.
	The papers structure is: Section 2 describes the theoretical		The details of EAP state machines are out of the scope of this
	background we use in this article, as well as the knowledge of the		document. Additional information can be found in [RFC4137].
	environment of the development platform. In section 3 based on the		Nevertheless, PANA state machines presented here have been
	Tate Pairing, this paper designs a safe and effective ID-based node		coordinated with state machines shown by [RFC4137].
	authentication scheme. In The fourth quarter, this paper implements
	the authentication scheme, and analyzes its results. Finally,		This document, apart from defining PaC and PAA state machines and
	its the conclusion and future outlook Overview of WSN and		their interfaces to EAP state machines (running on top of PANA),
	Authentication.		provides some implementation considerations, taking into account that
			it is not a specification but an implementation guideline.
	2. Terminology		2. Terminology
	3. Overview of ECC Encryption and TinyOS		This document reuses the terminology used in [RFC5191].
	3.1 ECC Encryption		3. Interface between PANA and EAP
	The basement of Elliptic Curve can be used in Public Key		PANA carries EAP messages exchanged between an EAP peer and an EAP
	cryptosystem is: The point set of Elliptic Curve defined on finite		authenticator (see Figure 1). Thus, a PANA state machine interacts
	domain composite a circulatory loop. Then we can use the discrete		with an EAP state machine.
	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.
	3.2 TinyOS		Two state machines are defined in this document: the PaC state
	3.2.1 Struce of TinyOS		machine (see Section 7) and the PAA state machine (see Section 8).
	TinyOS is a Micro-OS designed by the University of California,		The definition of each state machine consists of a set of variables,
	Berkeley,which is designed for the WSNs. Because there are many		procedures, and a state transition table. A subset of these
	nodes in WSN and most of them are work on concurrency, the OS		variables and procedures defines the interface between a PANA state
	adopts technologies of lightweight threads, active information		machine and an EAP state machine, and the state transition table
	communication, event-driven model and components-based programming,		defines the PANA state machine behavior based on results obtained
	After the study found that these technologies help to improve the		through them.
	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.
	TinyOS's high-level components send commands to the low-level		On the one hand, the PaC state machine interacts with an EAP peer
	components, and the low-level components report events to		state machine in order to carry out the PANA protocol on the PaC
	high-level components. The whole structure looks like a Network		side. On the other hand, the PAA state machine interacts with an EAP
	protocol stack. The bottom level components are responsible to		authenticator state machine to run the PANA protocol on the PAA side.
	communicate with the hardware, send and receive the bit stream
	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.
	3.2.2 NesC programming language		Peer |EAP Auth
			EAP <---------|------------> EAP
			^ | | ^ |
			| | | EAP-Message | | EAP-Message
			EAP-Message | |EAP-Message | | |
			| v |PANA | v
			PaC <---------|------------> PAA
	TinyOS is Micro-OS code and realized with the NesC programming		Figure 1: Interface between PANA and EAP
	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.
	(1) Interface: Interface is two-way, defined many commands and		Thus, two interfaces are needed between PANA state machines and EAP
	events. Commands are realized by the providers and the active		state machines, namely:
	operation for an event is implements by the users.
	(2) Configuration: The configuration is a component which can		o Interface between the PaC state machine and the EAP peer state
	be used to assemble the components. It is used to connect the		machine
	various components of the interface providers and users. Such
	an act is called conduction or wiring.
	(3) Module: Module provides the application code, implemented		o Interface between the PAA state machine and the EAP authenticator
	one or more interfaces. The realization of all methods is defined		state machine
	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.
	3.3 Introduction of TinyECC		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 send EAP messages through the PaC and PAA state
			machines that are responsible for actually transmitting this message,
			respectively.
	TinyECC is a code packet provided by a North Carolina State		For example, [RFC4137] specifies four interfaces to lower layers: (i)
	University develops team. It provides a base arithmetic		an interface between the EAP peer state machine and a lower layer,
	operation of ECC on TinyOS. It provides all ECC operations		(ii) an interface between the EAP standalone authenticator state
	on domain, including the point add, double and scalar		machine and a lower layer, (iii) an interface between the EAP full
	multiplication.		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.
	3.3.1 System's main modules		4. Document Authority
	(1) NN module: The methods in this module are modified from		This document is intended to comply with the technical contents of
	RSAREF2.0. It provides the realization of large numbers		any of the related documents ([RFC5191] and [RFC4137]). When there
	operations in different sensor nodes (Micaz and TELOSB).		is a discrepancy, the related documents are considered authoritative
			and they take precedence over this document.
	(2) ECC module: The ECC module provides many basic operations		5. Notations
	on elliptic curve. For example, initialization of an elliptic
	curve, point adding, point doubling, point scalar
	multiplication and some operations based on sliding window.
	(3) ECDSA module: This module realized a signature protocol		The following state transition tables are completed mostly based on
	based on ECC.		the conventions specified in [RFC4137]. The complete text is
			described below.
	ECDSA is based on ECC component, SHA1 hash component and NN		State transition tables are used to represent the operation of the
	component. It realized a signature protocol based on ECC.		protocol by a number of cooperating state machines each comprising a
	ECC is the core of TinyECC. It calls the CurveParam component		group of connected, mutually exclusive states. Only one state of
	to initialize an Elliptic Curve and the NN component to realize		each machine can be active at any given time.
	the large number operations.
	3.3.2 Working process		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 explicitly enumerated as exception states.
			The exit conditions of a wildcard state are evaluated after all other
			exit conditions specific to the current state are met.
	(1) Initialize an elliptic curve: The TinyECC provides an		On exit from a state, the exit actions defined for the state and the
	interface CurveParam to initialize an elliptic curve. This		exit condition are executed exactly once, in the order that they
	interface was implemented by secp128r1, secp128r2, secp160k1,		appear. (Note that the procedures defined in [RFC4137] are executed
	secp160r2, secp160r2, secp192k1 and secp192r17, which defined		on entry to a state, which is one major difference from this
	7 elliptic curves with 128,160 and 192bits.		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 executes 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.
	(2) Base operations on elliptical curve: The ECC interface defined		On completion of the transition from the previous state to the
	all base operations of the points set on elliptical curve,		current state, all exit conditions occurring during the current state
	including the point add, double, scalar multiplication and		(including exit conditions defined for the wildcard state) are
	optimized operation based on sliding window methods.		evaluated until an exit condition for that state is met.
	For example, we can call ECC.win_mul(&myTb,RInv,&pointArray)
	to realize a scalar multiplication.
	4. Protocol Description		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.
	4.1 Flow and Structure		The interpretation of the special symbols and operators used is
			defined in [RFC4137].
	This section describes the nodes authentication based on TinyECC.		6. Common Rules
	Based on TinyECC, we designed a simple node authentication protocol
	on WSNs to realize simple node authentication. The protocol can be
	divided into the following steps:
	Alice Bob		There are following procedures, variables, message initializing
	| 1. A selects random number a, and sends Ta=a*P to B. |		rules, and state transitions that are common to both the PaC and PAA
	+------------------------------------------------------->|		state machines.
	| |
	| 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.
	4.2 Implementation		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".
	This protocol is based on TinyECC. The call relation between		6.1. Common Procedures
	components of this program can be described as:
	main compoment		void None()
	| |
	| |
	| |
	base node compoment |
	| | | |
	| | | |
	| | | |
	| | | |
	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		A null procedure, i.e., nothing is done.
	4.3.1 Performance Analysis		void Disconnect()
	For the protocol, the largest comustion is the point multiplication.		A procedure to delete the PANA session as well as the
	The number of computing for both sides of communication show as		corresponding EAP session and authorization state.
	table 1.
	+-------------------+----------------------------------+		boolean Authorize()
	| Node | Counts of Point multiplication |
	+-------------------+----------------------------------+
	| A | 3 |
	+-------------------+----------------------------------+
	| B | 3 |
	+-------------------+----------------------------------+
	Table 1: Number of Computing		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.
	The protocol is Lightweight two-way authentication protocol. Though		void Tx:PANA_MESSAGE_NAME[flag](AVPs)
	the three times of point multiplication, it completes the two-way
	authentication and is based on the ECDH.
	4.3.2 Security Analysis		A procedure to send a PANA message to its peering PANA entity.
			The "flag" argument contains one or more flags (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.
	Definition: Passive attack means that enemy just collects information		This procedure includes the following action before actual
	in passive way, rather than obtain the data through active access.		transmission:
	Data legitimate users would not be aware of such activities. Passive
	attacks includesniffer, information-collecting etc.
	Conclusion: If the ECDH problem is difficult on the point group G,		if (flag==S)
	then the authentication scheme is secure against impersonation under		PANA_MESSAGE_NAME.S_flag=Set;
	passive attack.		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");
	5. Security Considerations		void TxEAP()
	5.1. Privacy Considerations		A procedure to send an EAP message to the EAP state machine to
			which it interfaces.
	6. IANA Considerations		void RtxTimerStart()
	This document does not propose a standard and does not require the		A procedure to start the retransmission timer, reset RTX_COUNTER
	PANA to do anything.		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.
	7. Contributors		void RtxTimerStop()
	This draft is a product of a design team which also included Marcelo		A procedure to stop the retransmission timer.
	Bagnulo and Philip Matthews who both have made major contributions to
	this document.
	8. Acknowledgments		void SessionTimerReStart(TIMEOUT)
	The following people have contributed to this document. Listing their		A procedure to (re)start the PANA session timer. TIMEOUT
	names here does not mean that they endorse the document, but that		specifies the expiration time associated with the session timer.
	they have contributed to its substance.		Expiration of TIMEOUT will trigger a SESS_TIMEOUT event.
	Dujuan Yan, Sugang Bai, Liang Ge,		void SessionTimerStop()
	9. References		A procedure to stop the current PANA session timer.
	9.1. Normative References		void Retransmit()
	9.2. Informative References		A procedure to retransmit a PANA message and increment RTX_COUNTER
			by one(1).
	Authors' Addresses		void EAP_Restart()
	Weihong Wang		A procedure to (re)start an EAP conversation resulting in the re-
	Zhejiang University of Technology, China		initialization of an existing EAP session.
	Phone: +86 0571-85290115		void PANA_MESSAGE_NAME.insert_avp("AVP_NAME1", "AVP_NAME2",...)
	Email: wwh@zjut.edu.cn
	Tieming Chen		A procedure to insert AVPs for each specified AVP name in the list
	Zhejiang University of Technology, China		of AVP names in the PANA message. When an AVP name ends with "*",
	Phone: +86 0571-85290110		zero, one, or more AVPs are inserted; otherwise, one AVP is
	Email:tiemingchen@gmail.com		inserted.
	Yubing Lin		boolean PANA_MESSAGE_NAME.exist_avp("AVP_NAME")
	Zhejiang University of Technology, China
	Phone: +86 0571-85290115		A procedure that checks whether an AVP of the specified AVP name
	Email: yulin@126.com		exists in the specified PANA message and returns TRUE if the
			specified AVP is found, otherwise returns FALSE.
	Yiling Cui		boolean generate_pana_sa()
	Zhejiang University of Technology, China
	Phone: +86 0571-85294110		A procedure to check whether the EAP method being used generates
	Email: cyllingling_00@126.com		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 a Master Session Key (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 that 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 to be included in a message are inserted
			with appropriate values set.
			6.5. Common Retransmission Rules
			The state machines defined in this document assume that the PaC and
			the PAA cache the last transmitted answer message. This scheme is
			described in Section 5.2 of [RFC5191]. When the PaC or PAA receives
			a retransmitted or duplicate request, it would be able to resend 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 a
			corresponding answer to a retransmitted request, the request will be
			handled by the corresponding state machine.
			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
			This is a 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 an EAP conversation completes with success.
			EAP_FAILURE
			This event variable is set to TRUE when the EAP peer determines
			that an 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 EAP layer in a given period. This provides a
			time limit for certain EAP methods where user interaction may be
			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. Note that
			this specification does not support silently discarding EAP
			messages. They are treated as fatal errors instead. This may
			have an impact on denial-of-service resistance.
			7.4. Procedures
			boolean eap_piggyback()
			This procedure 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()
			This is a procedure to start a timer to receive an EAP-Response
			from the EAP peer.
			void EAP_RespTimerStop()
			This is 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 an 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 an 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
			This event variable is set to TRUE when an EAP conversation times
			out without generating an EAP-Success or an EAP-Failure message.
			This event does not accompany any EAP message.
			EAP_DISCARD
			This event variable is set to TRUE when the EAP authenticator
			indicates that it has silently discarded the last received EAP-
			Response message. This event does not accompany any EAP message.
			In the case where the EAP authenticator follows the EAP
			authenticator state machines defined in [RFC4137], this event
			variable refers to eapNoReq.
			8.3. Procedures
			boolean new_key_available()
			This is a procedure to check whether the PANA session has a new
			PANA_AUTH_KEY. If the state machine already has a PANA_AUTH_KEY,
			it returns FALSE. If the state machine does not have a
			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
			------------------------------
			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 initiated from PAA)- - - -
			TERMINATE Tx:PTR[](); SESS_TERM
			SessionTimerStop();
			RtxTimerStart();
			- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
			- - - - - - - - (Session termination initiated 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 initiated 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 and PaC Interface to Service Management Entity
			In general, it is assumed that each device or network equipment has a
			PANA 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
			manage different services (including network protocols) that are
			installed on a device or equipment. To integrate the 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 provide for extracting keying material. For the PAA,
			the SME-PANA interface should also provide a method for communicating
			filtering parameters to the Enforcement Point(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
			This document's intent is to describe 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. Acknowledgments
			This work was started from state machines originally made by Dan
			Forsberg.
			12. References
			12.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.
			12.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)
			Telcordia Technologies
			1 Telcordia Drive
			Piscataway, NJ 08854
			USA
			Phone: +1 732 699 5368
			EMail: vfajardo@research.telcordia.com
			Yoshihiro Ohba
			Toshiba Corporate Research and Development Center
			1 Komukai-Toshiba-cho, Saiwai-ku
			Kawasaki, Kanagawa 212-8582
			Japan
			Phone: +81 44 549 2230
			EMail: yoshihiro.ohba@toshiba.co.jp
			Rafa Marin-Lopez
			University of Murcia
			Campus de Espinardo S/N, Facultad de Informatica
			Murcia 30100
			Spain
			Phone: +34 868 888 501
			EMail: rafa@um.es
End of changes. 68 change blocks.
	285 lines changed or deleted		273 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/