--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/HOKEY/drafts/draft-ietf-hokey-arch-design.xml	Fri Nov 05 14:21:19 2010 +0900
@@ -0,0 +1,867 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet type='text/xsl'
+href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY rfc2119 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY rfc2828 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2828.xml">
+<!ENTITY rfc2865 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
+<!ENTITY rfc3588 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
+<!ENTITY rfc3748 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
+<!ENTITY rfc4306 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
+<!ENTITY rfc4962 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml">
+<!ENTITY rfc5169 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5169.xml">
+<!ENTITY rfc5295 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml">
+<!ENTITY rfc5296 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
+<!ENTITY rfc5749 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5749.xml">
+<!ENTITY rfc5836 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5836.xml">
+<!ENTITY rfc5873 PUBLIC ""
+"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5873.xml">
+]>
+<?rfc toc="yes"?>
+<?rfc symrefs="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<rfc category="info" docName="draft-ietf-hokey-arch-design-01"
+     ipr="trust200902">
+  <front>
+    <title abbrev="Architecture Design">Handover Keying (HOKEY) Architecture
+    Design</title>
+
+    <author fullname="Katrin Hoeper" initials="K." surname="Hoeper">
+      <organization abbrev="Motorola">Motorola, Inc.</organization>
+
+      <address>
+        <postal>
+          <street>1301 E. Algonquin Road</street>
+
+          <city>Schaumburg</city>
+
+          <region>IL</region>
+
+          <code>60196</code>
+
+          <country>USA</country>
+        </postal>
+
+        <email>khoeper@motorola.com</email>
+      </address>
+    </author>
+
+    <author fullname="Sebastien Decugis" initials="S." surname="Decugis">
+      <organization abbrev="NICT">NICT</organization>
+
+      <address>
+        <postal>
+          <street>4-2-1 Nukui-Kitamachi</street>
+
+          <city>Tokyo</city>
+
+          <region>Koganei</region>
+
+          <code>184-8795</code>
+
+          <country>Japan</country>
+        </postal>
+
+        <email>sdecugis@nict.go.jp</email>
+      </address>
+    </author>
+
+    <author fullname="Glen Zorn" initials="G." surname="Zorn">
+      <organization abbrev="Network Zen">Network Zen</organization>
+
+      <address>
+        <postal>
+          <street>1310 East Thomas Street</street>
+
+          <city>Seattle</city>
+
+          <region>Washington</region>
+
+          <code>98102</code>
+
+          <country>USA</country>
+        </postal>
+
+        <email>gwz@net-zen.net</email>
+      </address>
+    </author>
+
+    <author fullname="Qin Wu" initials="Q." surname="Wu">
+      <organization abbrev="Huawei">Huawei Technologies Co.,Ltd</organization>
+
+      <address>
+        <postal>
+          <street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia
+          Rd.</street>
+
+          <city>Nanjing</city>
+
+          <region>JiangSu</region>
+
+          <code>210001</code>
+
+          <country>China</country>
+        </postal>
+
+        <phone>+86-25-84565892</phone>
+
+        <email>sunseawq@huawei.com</email>
+      </address>
+    </author>
+
+    <author fullname="Tom Taylor" initials="T." surname="Taylor">
+      <organization abbrev="Huawei">Huawei Technologies Co., Ltd</organization>
+
+      <address>
+        <postal>
+
+          <street></street>
+
+          <city>Ottawa </city>
+
+          <country>Canada</country>
+        </postal>
+
+        <email>tom111.taylor@bell.net </email>
+      </address>
+    </author>
+
+    <date year="2010" />
+
+    <workgroup>Network Working Group</workgroup>
+
+    <abstract>
+	<t>The Handover Keying (HOKEY) Working Group seeks to minimize handover delay
+due to authentication when a peer moves from one point of attachment to another.
+Work has progressed on two different approaches to reduce handover delay:
+early authentication (so that authentication does not need to be performed
+during handover), and reuse of cryptographic material generated during an
+initial authentication to save time during re-authentication. A starting
+assumption is that the mobile host or "peer" is initially authenticated using
+the Extensible Authentication Protocol (EAP), executed between the peer and an
+EAP server as defined in RFC 3748.</t>
+
+	<t>This document documents the HOKEY architecture. Specifically, it describes
+design objectives, the functional environment within which handover keying
+operates, the functions to be performed by the HOKEY architecture itself, and
+the assignment of those functions to architectural components. It goes on to
+illustrate the operation of the architecture within various deployment
+scenarios that are described more fully in other
+documents produced by the HOKEY Working Group. </t>
+    </abstract>
+  </front>
+
+  <middle>
+    <section title="Introduction">
+
+      <t>The Extensible Authentication Protocol (EAP) <xref
+target="RFC3748"></xref> is an authentication framework that supports different
+types of authentication methods. Originally designed for dial-up connections,
+EAP is now commonly used for authentication in wireless access networks.</t> 
+
+	<t>When a host (or "peer", the term used from this point onward) changes its
+point of attachment to the network, it must be re-authenticated. If a full EAP
+authentication must be repeated, several message round-trips between the peer
+and the home EAP server may be involved. The resulting delay will result in
+degradation or in the worst case loss of any service session in progress if
+communication is suspended while re-authentication is carried out. The delay is
+worse if the new point of attachment is in a visited network rather than the
+peer's home network, because of the extra procedural steps involved as well as
+because of the probable increase in round-trip time. </t>
+
+	<t><xref target="RFC5169"/> describes this problem more fully and establishes
+design goals for solutions to reduce re-authentication delay for transfers
+within a single administrative domain. <xref target="RFC5169"/> also suggests a
+number of ways to achieve a solution:
+<list style="symbols">
+  <t>specification of a method-independent, efficient, re-authentication
+  protocol;</t>
+
+  <t>reuse of keying material from the initial authentication;</t>
+
+  <t>deployment of re-authentication servers local to the peer to reduce 
+  round-trip delay; and</t>
+
+  <t>specification of the additional protocol needed to allow the EAP
+  server to pass authentication information to the local re-authentication
+  servers.</t>
+</list>
+ </t>
+	<t><xref target="RFC5295"/> tackles the problem of reuse of keying material
+by specifying how to derive a hierarchy of cryptographically independent
+purpose-specific keys from the results of the original EAP authentication.
+<xref target="RFC5296"/> specifies a method-independent re-authentication
+protocol (ERP) applicable to two specific deployment scenarios:
+	  <list style="symbols">
+	    <t>where the peer's home EAP server also performs re-authentication;
+and</t>
+	    <t>where a local re-authentication server exists but is collocated with a
+             AAA proxy within the domain.</t>
+	  </list>
+</t>
+
+	<t>Other work provides further pieces of the solution or insight
+into the problem. For the purpose of this draft, <xref target="RFC5749"/> provides an abstract mechanism  
+for distribution of keying material from the EAP server to re-authentication servers. <xref target="RFC5836"/> 
+contrasts the EAP re-authentication (ER) strategy provided by <xref target="RFC5296"/> with an alternative strategy called "early  authentication". 
+<xref target="RFC5836"></xref> defines EAP early
+authentication as the use of EAP by a mobile peer to establish authenticated
+keying material on a target attachment point prior to its arrival. Here, a full
+EAP execution occurs before the handover of the peer takes place. Hence, the
+goal of EAP early authentication is to complete all EAP-related communications,
+including AAA signaling, in preparation for the handover, before the mobile
+device actually moves. Early authentication includes direct and indirect pre-authentication as well as Authenticated Anticipatory Keying (AKK). 
+All three mechanims provide means to execute a full EAP authentication with a Candidate Access Point (CAP) while still being connected to the Serving
+ Access Point (SAP) but vary in their 
+respective system assumptions and communication paths. In particular, direct pre-authentication assumes that clients are capable of discovering candidate
+ access points  and all communications are routed through the serving access point. On the other hand, indirect pre-authentication assumes an
+ existing relationship betweem SAP and CAP, whereas in AAK the client interacts with the AAA to discover and connect to CAPs.</t>
+
+
+
+
+      <t>Both EAP re-authentication and early authentication enable faster
+inter-authenticator handovers. However, it is currently unclear how the
+necessary handover infrastructure is deployed and can be integrated into existing
+EAP infrastructures. In particular, previous work has not described how ER
+servers that act as endpoints in the re-authentication process should be integrated into local and home domain
+networks. Furthermore, it is currently unspecified how EAP infrastructure can 
+support the timely triggering of early authentications and aid with the selection of candidate  access points.</t>
+
+      <t>This document proposes a general HOKEY architecture and demonstrates
+how it can be adapted to different deployment scenarios. To begin with, <xref
+target="goals"/> recalls the design objectives for the HOKEY architecture. <xref
+target="fncns"/> reviews the functions that must be supported within the
+architecture. <xref target="compon"/> describes the components of the HOKEY
+architecture. Finally, <xref target="scen"/> describes the different deployment
+scenarios that the HOKEY Working Group has addressed and the information flows
+that must occur within those scenarios, by reference to the documents
+summarized above where possible and otherwise within this document itself.</t>
+    
+</section><!-- Introduction -->
+
+    <section anchor="terms" title="Terminology">
+
+      <t>This document contains no normative language, hence 
+<xref target="RFC2119"/> language does not apply.</t>
+
+      <t>This document reuses most of the terms defined in Section 2.2 of 
+      <xref target="RFC5836"/>. In addition, it defines the following:
+      
+<list style="hanging">
+   <t hangText="EAP Early Authentication"><vspace blankLines="0" />
+     The use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival, 
+     see <xref target="RFC5836"></xref>.
+   </t>
+
+   <t hangText="EAP Re-authentication (ER)"><vspace blankLines="0" />
+   The use of keying material derived from an initial EAP authentication
+   to enable single-roundtrip re-authentication of a mobile peer. For a
+   detailed description of the keying material see Section 3 of
+   <xref target="RFC5296"/>.
+   </t>
+
+   <t hangText="ER Server"><vspace blankLines="0" />
+   A component of the HOKEY architecture that terminates the EAP 
+   re-authentication exchange with the peer.
+   </t>
+
+   <t hangText="ER Key Management"><vspace blankLines="0" />
+   An instantiation of the mechanism provided by <xref target="RFC5749"/> for
+   creating and delivering root keys from an EAP server to an ER server.  
+   </t>
+
+</list>
+</t>
+    </section>
+
+    <section anchor="goals" title="Design Goals">
+
+      <t>This section investigates the design goals for the HOKEY
+architecture. These include reducing the signaling overhead for re-
+authentication and early authentication, integrating local domain name
+discovery, 
+and improving deployment scalability.
+These goals supplement the discussion in <xref target="RFC5169"/>.</t>
+
+      <section anchor="sigOvhd" title="Reducing Signalling Overhead">
+
+<section title="Minimized Communications with Home Servers">
+
+        <t>ERP requires only one round trip, however, this roundtrip may
+require communications between a peer and its home ER and/or home AAA server
+even if the peer is currently attached to a visited (local) network. As a
+result, even this one round trip may introduce long delays because home ER and
+home AAA servers may be distant from the peer. To lower the signaling overhead,
+communication with the home ER server and home AAA server should be minimized.
+Ideally, a peer should only need to communicate with local servers and other
+local entities.</t>
+
+      </section>
+
+      <section title="Integrated Local Domain Name (LDN) Discovery">
+
+        <t> ERP bootstrapping must occur before (implicit) or during (explicit) a
+handover to transport the necessary re-authentication root keys to the local ER
+server involved. Implicit bootstrapping is preferable because it does not
+require communication with the home ER server during handover (see previous
+section), but it requires the peer to know the domain name of the ER server in
+order to derive the necessary re-authentication keying material. <xref
+target="RFC5296"></xref> does not specify such a domain name discovery
+mechanism and suggests that the peer may learn the domain name through the EAP-
+Initiate/Re-auth-Start message or via lower layer announcements. To allow more
+efficient handovers, a HOKEY architecture should support an efficient domain
+name discovery mechanism and allow its integration with ERP implicit
+bootstrapping. Even in the case of explicit bootstrapping, local domain name
+discovery should be optimized such that it does not require contacting the home
+AAA server, as is currently the case.</t>
+
+      </section>
+
+</section><!-- sigOvhd -->
+
+      <section title="Better Deployment Scalability">
+
+        <t>To provide better deployment scalability, it should not be required
+that the HOKEY server and AAA servers or proxies are collocated. Separation of
+these entities may cause problems with routing, but allows flexibility in
+deployment and implementation.</t>
+
+      </section>
+
+    </section>
+
+    <section anchor="fncns" title="Functions That Must Be Supported">
+      <section title="System Overview">
+
+<t>This section views the HOKEY architecture as the implementation of a
+subsystem providing authentication services to AAA. Not only does AAA depend on
+the authentication subsystem, but the latter also depends on AAA as a means for
+the routing and secure transport of messages internal to the operation of
+network access authentication.</t>
+
+<t>The operation of the authentication subsystem also depends on the 
+availability of a number of discovery functions:
+<list style="symbols">
+<t>discovery of candidate access points, by the peer, by the serving attachment 
+point, or by some other entity;</t>
+<t>discovery of the authentication services supported at a given candidate
+access 
+point;</t>
+<t>discovery of the required server in the home domain when a candidate
+access point is not in the same domain as the serving attachment point, or
+no local server is available;</t>
+<t>peer discovery of the local domain name (LDN) when EAP re-authentication
+is used with a local server. </t>
+</list>
+It is assumed that
+these functions are provided by the environment within which the 
+authentication subsystem operates, and are outside the scope of the
+authentication subsystem itself. Local domain name discovery is
+a possible exception. </t>
+
+<t><xref target="fig_fctlOver"/> shows the major functions comprising
+the authentication subsystem and their interdependencies. These functions
+are described below.
+[EDITOR'S NOTE: These probably need refinement. The relationship
+of pre-authentication to EAP authentication, for instance, is
+currently not totally correct, when one takes account of the
+roles described in <xref target="compon"/>. AAK also needs
+an extension of ER key management.]</t>
+
+<figure anchor="fig_fctlOver" title="Authentication Subsystem 
+ Functional Overview">
+          <artwork>
++------------------------------------------------------------+
+|   AAA Network Access Authentication and Authorization      |
++---+-------------.----------------------------+-------------+
+    |            /|\                           |
+    |             |  Authentication subsystem  |
++===|=============|============================|=============+
+|   |   +---------+----------+   +-------------V---------+   |
+|   |   |    Direct and      |   | EAP Re-authentication |   |
+|   |   |      Indirect      |   +--+------+-------------+   |
+|   |   | Pre-Authentication |     /      /                  |
+|   |   +--------------------+    /      /                   |
+|   |                            /      / +---------------+  |
+|   |                           /      |  | Authenticated |  |
+|   |                          /       |  | Anticipatory  |  |
+|   |                         /        |  | Keying (AAK)  |  |
+|   |                        /         |  +-------+-------+  |
+|   |                       /          |          |          |
+| +-V------------------+   / +---------V----------V--------+ |
+| | EAP Authentication |  |  |       ER Key Management     | |
+| +---------+----------+  |  |+------------+ +------------+| |
+|           |             |  ||Handover Key| |Handover Key|| |
+|           |             |  || Derivation | |Distribution|| |
+|           |             |  |+------------+ +------+-----+| |
+|           |             |  +----------------------|------+ |
++===========|=============|=========================|========+
+            |             |                         |
++-----------V-------------V-------------------------V--------+
+|             AAA routing and secure transport               |
++------------------------------------------------------------+
+</artwork>
+<postamble>Arrows show the direction of functional dependency.</postamble>
+        </figure>
+
+        <t><xref target="fig_fctlOver"/> shows the following dependencies:
+<list style="symbols">
+<t>When AAA is invoked to authenticate and authorize network access, it uses one
+of two services offered by the authentication subsystem: full EAP
+authentication, or EAP re-authentication.</t>
+
+<t>Pre-authentication triggers AAA network access authentication and
+authorization at each candidate access point, which in turn causes full EAP
+authentication to be invoked. </t>
+
+<t>   EAP re-authentication invokes ER key management at the time of 
+authentication to create and distribute keying material to ER servers.</t>
+
+<t>Authenticated anticipatory keying (AAK) relies on ER key management to
+establish keying material on ER/AAK servers, but uses an extension
+to ER key management to derive and establish keying material on
+candidate authenticators.</t>
+</list>
+</t>
+
+<t>EAP authentication, EAP re-authentication, and handover key distribution
+depend on the routing and secure transport service 
+provided by AAA. Discovery functions and the function of authentication and
+authorization of network entities (access points, ER servers)
+are not shown. As stated above, these are external to the authentication
+subsystem.</t>
+
+      </section><!-- System Overview -->
+
+<section anchor="preauth" title="Pre-Authentication Function (Direct or
+Indirect)">
+
+<t>The pre-authentication function is responsible for discovery of candidate 
+access points and completion of network access authentication and
+authorization at each candidate access point in advance of handover. The operation of this function
+is described in general terms in <xref target="RFC5836"/>. No document is 
+yet available to describe the implementation of pre-authentication
+in terms of specific protocols. <xref target="RFC5873"/>
+could be part of the solution, but is Experimental rather
+than Standards Track.</t>
+
+</section><!-- preauth -->
+
+<section anchor="reauth" title="EAP Re-authentication Function">
+
+<t>The EAP re-authentication function is responsible for authenticating
+the peer at a specific access point using keying material 
+derived from a prior full EAP authentication. <xref target="RFC5169"/>
+provides the design objectives for an implementation of this function.
+<xref target="RFC5296"/> describes a protocol to implement EAP
+re-authentication subject to the architectural restrictions noted
+above. Work is in progress to relax those restrictions.</t>
+
+</section><!-- reauth -->
+
+<section anchor="EAPauthen" title="EAP Authentication Function">
+
+<t>The EAP authentication function is responsible for authenticating 
+the peer at a specific access point using a full EAP exchange.
+<xref target="RFC3748"/> defines the associated protocol. 
+<xref target="RFC5836"/> shows the use of EAP as part of 
+pre-authentication. Note that the HOKEY Working Group has not specified
+the non-AAA protocol required
+to transport EAP frames over IP that is shown in Figures 3 and 5
+of <xref target="RFC5836"/>, although <xref target="RFC5873"/>
+is a candidate.
+</t>
+
+</section><!-- EAPauthen -->
+
+<section anchor="AAKfcn" title="Authenticated Anticipatory Keying (AAK)
+Function">
+
+<t>The authenticated anticipatory keying function is responsible for 
+pre-placing keying material derived from an initial full EAP authentication
+on candidate access points. The operation is carried out in two steps: 
+ER key management (with trigger not currently specified) places root
+keys derived from initial EAP authentication onto an ER/AAK server 
+associated with the peer. When requested by the peer, the ER/AAK server
+derives and pushes predefined master session keys to a list of
+candidate access points. The operation
+of the authenticated anticipatory keying function is described in very
+general terms in <xref target="RFC5836"/>. 
+A protocol implementation is being specified
+in <xref target="I-D.ietf-hokey-erp-aak"/>.</t>
+
+</section><!-- AAKfcn -->
+
+<section anchor="keyMgmt" title="EAP-Based Handover Key Management">
+
+        <t>EAP-based handover key management consists of EAP method
+independent key derivation and distribution and comprises the following
+specific functions:
+<list style="symbols">
+  <t>handover key derivation; and</t>
+  <t>handover key distribution.</t>
+</list>
+The derivation of handover keys is specified in <xref
+target="RFC5295"></xref>, and key distribution is specified in <xref 
+target="RFC5749"></xref>.</t>
+
+</section><!-- keyMgmt -->
+
+    </section><!-- fncns -->
+
+<section anchor="compon" title="Components of the HOKEY Architecture">
+
+<t>This section describes the components of the HOKEY architecture, in terms
+of the functions they perform. The components cooperate as described in 
+this section to carry out the functions described in the previous section.
+<xref target="scen"/> describes the different
+deployment scenarios that are possible using these functions.</t>
+
+<t>The components of the HOKEY architecture are as follows:
+<list style="symbols">
+   <t>the peer;</t>
+   <t>the authenticator, which is a part of the serving access point 
+    and candidate access points;</t>
+   <t>the EAP server; and</t>
+   <t>the ER server, either in the home domain or local to the
+    authenticator.</t>
+</list>
+[EDITOR'S NOTE: probably have to add the ER/AAK server named 
+in <xref target="I-D.ietf-hokey-erp-aak"/> to this list.]
+</t>
+
+<section anchor="peerFnc" title="Functions of the Peer">
+
+<t>The peer participates in the functions described in <xref target="fncns"/> 
+as shown in <xref target="tab_peerFnc"/>.</t>
+
+<texttable anchor="tab_peerFnc" title="Functions of the Peer">
+<ttcol>Function</ttcol>
+<ttcol>Peer Role</ttcol>
+
+<c>EAP authentication</c>
+<c>Determines that full EAP authentication is needed based on context
+(e.g., initial authentication), prompting from the authenticator, or
+discovery that only EAP authentication is supported. Participates
+in the EAP exchange with the EAP server.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Direct pre-authentication</c>
+<c>Discovers candidate access points. Initiates pre-authentication
+with each, followed by EAP authentication as above, but using IP
+rather than L2 transport for the EAP frames.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Indirect pre-authentication</c>
+<c>Enters into a full EAP exchange when triggered, using either L2 
+or L3 transport for the frames. </c>
+<c>-</c>
+<c>-</c>
+
+<c>EAP re-authentication</c>
+<c>Determines that EAP re-authentication is possible based on
+discovery or authenticator prompting. Discovers ER server.
+Participates in ERP exchange with ER server.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Authenticated anticipatory keying</c>
+<c>Determines that AAK is possible based on discovery or 
+serving authenticator prompting. Discovers candidate access points.
+Sends request to serving authenticator to distribute keying
+material to the candidate access points.
+</c>
+<c>-</c>
+<c>-</c>
+
+<c>ER key management</c>
+<c>No role.</c>
+</texttable>
+
+
+</section><!-- peerFnc -->
+
+<section anchor="saFnc" title="Functions of the Serving Authenticator">
+
+<t>The serving authenticator participates in the functions described 
+in  <xref target="fncns"/> 
+as shown in <xref target="tab_saFnc"/>.</t>
+
+<texttable anchor="tab_saFnc" title="Functions of the Serving Authenticator">
+<ttcol>Function</ttcol>
+<ttcol>Serving Authenticator Role</ttcol>
+
+<c>EAP authentication</c>
+<c>No role. </c>
+<c>-</c>
+<c>-</c>
+
+<c>Direct pre-authentication</c>
+<c>No role.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Indirect pre-authentication</c>
+<c>Discovers candidate access points. Initiates an EAP exchange
+between the peer and the EAP server through each candidate
+authenticator. Mediates between L2 transport of EAP frames on the peer
+side and a non-AAA protocol over IP toward the candidate access point.</c>
+<c>-</c>
+<c>-</c>
+
+<c>EAP re-authentication</c>
+<c>No role.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Authenticated anticipatory keying</c>
+<c>Mediates between L2 transport of AAK frames on the peer side
+and AAA transport toward the ER/AAK server.</c>
+<c>-</c>
+<c>-</c>
+
+<c>ER key management</c>
+<c>No role.</c>
+</texttable>
+
+</section><!-- saFnc -->
+
+<section anchor="caFnc" title="Functions of the Candidate Authenticator">
+
+<t>The candidate authenticator participates in the functions described 
+in  <xref target="fncns"/> 
+as shown in <xref target="tab_caFnc"/>.</t>
+
+<texttable anchor="tab_caFnc" title="Functions of the Candidate Authenticator">
+<ttcol>Function</ttcol>
+<ttcol>Candidate Authenticator Role</ttcol>
+
+<c>EAP authentication</c>
+<c>Invokes AAA network access authentication and authorization
+upon handover/initial attachment. 
+Mediates between L2 transport of EAP frames on the peer link and AAA
+transport toward the EAP server.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Direct pre-authentication</c>
+<c>Invokes AAA network access authentication and authorization
+when the peer initiates authentication. 
+Mediates between non-AAA L3 transport of EAP frames on the peer side and AAA
+transport toward the EAP server. </c>
+<c>-</c>
+<c>-</c>
+
+<c>Indirect pre-authentication</c>
+<c>Same as direct pre-authentication, except that it communicates with
+the serving authenticator rather than the peer.</c>
+<c>-</c>
+<c>-</c>
+
+<c>EAP re-authentication</c>
+<c>Invokes AAA network access authentication and authorization upon handover.
+Discovers or is configured with the address of the ER server.
+Mediates between L2 transport of a ERP frames on the peer side
+and AAA transport toward the ER server.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Authenticated anticipatory keying</c>
+<c>Receives and saves pMSK.</c>
+<c>-</c>
+<c>-</c>
+
+<c>ER key management</c>
+<c>No role.</c>
+</texttable>
+
+</section><!-- caFnc -->
+
+<section anchor="EAPsrvFnc" title="Functions of the EAP Server">
+
+<t>The EAP server participates in the functions described in 
+<xref target="fncns"/> 
+as shown in <xref target="tab_EAPsrvFnc"/>.</t>
+
+<texttable anchor="tab_EAPsrvFnc" title="Functions of the EAP Server">
+<ttcol>Function</ttcol>
+<ttcol>EAP Server Role</ttcol>
+
+<c>EAP authentication</c>
+<c>Authenticates and authorizes the candidate access point to act as
+authenticator.
+Terminates EAP signalling between it and the peer via the candidate
+authenticator. Determines whether
+network access authentication succeeds or fails. Provides MSK
+to authenticator.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Direct pre-authentication</c>
+<c>As for EAP authentication.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Indirect pre-authentication</c>
+<c>As for EAP authentication.</c>
+<c>-</c>
+<c>-</c>
+
+<c>EAP re-authentication</c>
+<c>Mutually authenticates with the ER server and authorizes it for
+receiving keying amterial. Provides rRK or DSrRK to the ER server.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Authenticated anticipatory keying</c>
+<c>As for EAP re-authentication.</c>
+<c>-</c>
+<c>-</c>
+
+<c>ER key management</c>
+<c>Creates rRK or DSrRK and distributes it to ER server requesting the
+information.</c>
+</texttable>
+
+</section><!-- EAPsrvFnc -->
+
+<section anchor="ERsrvFnc" title="Functions of the ER Server">
+
+<t>The ER server participates in the functions described in 
+<xref target="fncns"/> 
+as shown in <xref target="tab_ERsrvFnc"/>. [EDITOR'S NOTE: Need discussion of
+respective roles of local and home ER server, or whether there should even be 
+such a distinction.]</t>
+
+<texttable anchor="tab_ERsrvFnc" title="Functions of the ER Server">
+<ttcol>Function</ttcol>
+<ttcol>ER Server Role</ttcol>
+
+<c>EAP authentication</c>
+<c>No role.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Direct pre-authentication</c>
+<c>No role.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Indirect pre-authentication</c>
+<c>No role.</c>
+<c>-</c>
+<c>-</c>
+
+<c>EAP re-authentication</c>
+<c>Authenticates and authorizes the candidate access point to act as
+authenticator. Authenticates itself to the EAP server and acquires
+rRK or DSrRK as applicable when necessary.
+Terminates ERP signalling between it and the peer via the candidate
+authenticator. Determines whether
+network access authentication succeeds or fails. Provides MSK
+to authenticator.</c>
+<c>-</c>
+<c>-</c>
+
+<c>Authenticated anticipatory keying</c>
+<c>Authenticates itself to the EAP server and acquires
+rRK or DSrRK as applicable when necessary. Authenticates and authorizes 
+the candidate access points to act as authenticator. Derives pMSKs and 
+passes them to the candidate access points.</c>
+<c>-</c>
+<c>-</c>
+
+<c>ER key management</c>
+<c>Receives and saves rRK or DSrRK as applicable.</c>
+</texttable>
+
+</section><!-- ERsrvFnc -->
+
+</section><!-- compon -->
+
+
+    <section anchor="scen" title="Deployment Scenarios">
+
+<t>The necessity for this section and its contents are TBD.</t>
+
+</section><!-- scen -->
+
+
+    <section title="AAA Consideration">
+      <section title="Standalone HOKEY server">
+        <t>TBD.</t>
+      </section>
+    </section>
+
+    <section title="Security Considerations">
+      <t>TBD</t>
+    </section>
+
+    <section title="IANA Considerations">
+      <t>This document has no actions for IANA.</t>
+    </section>
+
+    <section title="Acknowledgments">
+      <t>The authors would like to thank  Mark Jones and Zhen Cao
+       for their reviews of  previous versions of this draft.</t>
+    </section>
+  </middle>
+
+  <back>
+    <references title="Informative References">
+&rfc2119;
+&rfc3748;
+&rfc5169;
+&rfc5295;
+&rfc5296;
+&rfc5749;
+&rfc5836;
+&rfc5873;
+
+<reference anchor="I-D.ietf-hokey-erp-aak">
+<front>
+<title>EAP Re-authentication Protocol Extensions for Authenticated Anticipatory
+    Keying (ERP/AAK)</title>
+<author fullname="Zhen Cao" initials="Z." surname="Cao">
+<organization>China Mobile
+</organization>
+</author>
+<author fullname="Hui Deng" initials="H." surname="Deng">
+<organization>China Mobile
+</organization>
+</author>
+<author fullname="Yungui Wang" initials="Y." surname="Wang">
+<organization>Huawei Technologies</organization>
+</author>
+<author fullname="Qin Wu" initials="Q." surname="Wu">
+<organization>Huawei technologies</organization>
+</author>
+<author fullname="Glen Zorn" initials="G." surname="Zorn">
+<organization>Network Zen</organization>
+</author>
+<date month="May" year="2010" />
+</front><seriesInfo name="Internet Draft" value="draft-ietf-hokey-erp-aak-02" />
+
+</reference>
+
+
+    </references>
+
+  </back>
+</rfc>