--- 1/draft-ietf-pana-statemachine-08.txt 2009-01-20 20:12:04.000000000 +0100 +++ 2/draft-ietf-pana-statemachine-09.txt 2009-01-20 20:12:04.000000000 +0100 @@ -1,106 +1,115 @@ PANA Working Group V. Fajardo, Ed. Internet-Draft Y. Ohba -Expires: June 7, 2009 TARI - R. Lopez +Intended status: Informational TARI +Expires: July 24, 2009 R. Lopez Univ. of Murcia - December 4, 2008 + January 20, 2009 State Machines for Protocol for Carrying Authentication for Network Access (PANA) - draft-ietf-pana-statemachine-08 + draft-ietf-pana-statemachine-09 Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 7, 2009. + This Internet-Draft will expire on July 24, 2009. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Abstract This document defines the conceptual state machines for the Protocol 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 EAP state machines. The state machines and associated model are informative only. Implementations may achieve the same results using different methods. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Interface Between PANA and EAP . . . . . . . . . . . . . . . . 7 - 4. Document Authority . . . . . . . . . . . . . . . . . . . . . . 9 - 5. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 6.1. Common Procedures . . . . . . . . . . . . . . . . . . . . 12 - 6.2. Common Variables . . . . . . . . . . . . . . . . . . . . . 14 - 6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.4. Common Message Initialization Rules . . . . . . . . . . . 16 - 6.5. Common Retransmition Rules . . . . . . . . . . . . . . . . 16 - 6.6. Common State Transitions . . . . . . . . . . . . . . . . . 16 - 7. PaC State Machine . . . . . . . . . . . . . . . . . . . . . . 18 - 7.1. Interface between PaC and EAP Peer . . . . . . . . . . . . 18 - 7.1.1. Delivering EAP Messages from PaC to EAP Peer . . . . . 18 - 7.1.2. Delivering EAP Messages from EAP Peer to PaC . . . . . 18 - 7.1.3. EAP Restart Notification from PaC to EAP Peer . . . . 18 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Interface Between PANA and EAP . . . . . . . . . . . . . . . . 6 + 4. Document Authority . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Common Procedures . . . . . . . . . . . . . . . . . . . . 11 + 6.2. Common Variables . . . . . . . . . . . . . . . . . . . . . 13 + 6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.4. Common Message Initialization Rules . . . . . . . . . . . 15 + 6.5. Common Retransmition Rules . . . . . . . . . . . . . . . . 15 + 6.6. Common State Transitions . . . . . . . . . . . . . . . . . 15 + 7. PaC State Machine . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Interface between PaC and EAP Peer . . . . . . . . . . . . 17 + 7.1.1. Delivering EAP Messages from PaC to EAP Peer . . . . . 17 + 7.1.2. Delivering EAP Messages from EAP Peer to PaC . . . . . 17 + 7.1.3. EAP Restart Notification from PaC to EAP Peer . . . . 17 7.1.4. EAP Authentication Result Notification from EAP - Peer to PaC . . . . . . . . . . . . . . . . . . . . . 19 - 7.1.5. Alternate Failure Notification from PaC to EAP Peer . 19 - 7.2. Constants . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.3. Variables . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 20 - 7.5. PaC State Transition Table . . . . . . . . . . . . . . . . 20 - 8. PAA State Machine . . . . . . . . . . . . . . . . . . . . . . 26 - 8.1. Interface between PAA and EAP Authenticator . . . . . . . 26 + Peer to PaC . . . . . . . . . . . . . . . . . . . . . 18 + 7.1.5. Alternate Failure Notification from PaC to EAP Peer . 18 + 7.2. Constants . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.3. Variables . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.5. PaC State Transition Table . . . . . . . . . . . . . . . . 19 + 8. PAA State Machine . . . . . . . . . . . . . . . . . . . . . . 25 + 8.1. Interface between PAA and EAP Authenticator . . . . . . . 25 8.1.1. EAP Restart Notification from PAA to EAP - Authenticator . . . . . . . . . . . . . . . . . . . . 26 + Authenticator . . . . . . . . . . . . . . . . . . . . 25 8.1.2. Delivering EAP Responses from PAA to EAP - Authenticator . . . . . . . . . . . . . . . . . . . . 26 + Authenticator . . . . . . . . . . . . . . . . . . . . 25 8.1.3. Delivering EAP Messages from EAP Authenticator to - PAA . . . . . . . . . . . . . . . . . . . . . . . . . 26 + PAA . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1.4. EAP Authentication Result Notification from EAP - Authenticator to PAA . . . . . . . . . . . . . . . . . 26 - 8.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 27 - 8.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.4. PAA State Transition Table . . . . . . . . . . . . . . . . 28 - 9. Implementation Considerations . . . . . . . . . . . . . . . . 33 - 9.1. PAA and PaC Interface to Service Management Entity . . . . 33 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 37 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 - Intellectual Property and Copyright Statements . . . . . . . . . . 39 + Authenticator to PAA . . . . . . . . . . . . . . . . . 25 + 8.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 26 + 8.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.4. PAA State Transition Table . . . . . . . . . . . . . . . . 27 + 9. Implementation Considerations . . . . . . . . . . . . . . . . 32 + 9.1. PAA and PaC Interface to Service Management Entity . . . . 32 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This document defines the state machines for Protocol Carrying Authentication for Network Access (PANA) [RFC5191]. There are state machines for the PANA client (PaC) and for the PANA Authentication Agent (PAA). Each state machine is specified through a set of variables, procedures and a state transition table. A PANA protocol execution consists of several exchanges to carry @@ -186,65 +195,65 @@ 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 - When a discrepancy occurs between any part of this document and any - of the related documents ([RFC5191], [RFC4137] the latter (the other - documents) are considered authoritative and takes precedence. + 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 the current state in - each state machine. The exit conditions of a wildcard state are - evaluated after all other exit conditions of specific to the current - state are 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 on the page. (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. + 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. @@ -278,24 +287,24 @@ 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 a 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. + 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; @@ -307,21 +316,24 @@ 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. + 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. @@ -1191,35 +1203,39 @@ ------------------------+--------------------------+------------ - - - - - - - - - - - - - -(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 in each device that has a PANA protocol - stack that there is a Service Management Entity (SME) that manages - the PANA protocol stack. 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. Especially, common - procedures such as startup, shutdown, re-authenticate signals and - provisions for extracting keying material should be provided by such - an interface. The SME-PANA interface in a PAA device 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 per-packet ciphering. - When a PAA device interacts with the backend authentication server - using a AAA protocol, its SME may also have an interface to the AAA - protocol to obtain authorization parameters such as the authorization - lifetime and additional filtering parameters. + In general, it is assumed 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 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 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. IANA Considerations This document has no actions for IANA. @@ -1262,50 +1278,10 @@ Phone: +1 732 699 5305 Email: yohba@tari.toshiba.com Rafa Marin Lopez University of Murcia 30071 Murcia Spain Email: rafa@dif.um.es - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org.