<?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>