Handover Keying (HOKEY) Architecture + Design

+ + The Extensible Authentication Protocol (EAP) 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. + + 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. + + describes this problem more fully and establishes +design goals for solutions to reduce re-authentication delay for transfers +within a single administrative domain. also suggests a +number of ways to achieve a solution: + + specification of a method-independent, efficient, re-authentication + protocol; + + reuse of keying material from the initial authentication; + + deployment of re-authentication servers local to the peer to reduce + round-trip delay; and + + specification of the additional protocol needed to allow the EAP + server to pass authentication information to the local re-authentication + servers. + + + 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. + specifies a method-independent re-authentication +protocol (ERP) applicable to two specific deployment scenarios: + + where the peer's home EAP server also performs re-authentication; +and + where a local re-authentication server exists but is collocated with a + AAA proxy within the domain. + + + + Other work provides further pieces of the solution or insight +into the problem. For the purpose of this draft, provides an abstract mechanism +for distribution of keying material from the EAP server to re-authentication servers. +contrasts the EAP re-authentication (ER) strategy provided by with an alternative strategy called "early authentication". + 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. + + + + + 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. + + This document proposes a general HOKEY architecture and demonstrates +how it can be adapted to different deployment scenarios. To begin with, recalls the design objectives for the HOKEY architecture. reviews the functions that must be supported within the +architecture. describes the components of the HOKEY +architecture. Finally, 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. + +

+ +

+ + This document contains no normative language, hence + language does not apply. + + This document reuses most of the terms defined in Section 2.2 of + . In addition, it defines the following: + + + + The use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival, + see . + + + + 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 + . + + + + A component of the HOKEY architecture that terminates the EAP + re-authentication exchange with the peer. + + + + An instantiation of the mechanism provided by for + creating and delivering root keys from an EAP server to an ER server. + + + + +

+ +

+ + 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 . + +

+ +

+ + 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. + +

+ +

+ + 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. 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. + +

+ +

+ + 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. + +

+ +

+ +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. + +The operation of the authentication subsystem also depends on the +availability of a number of discovery functions: + +discovery of candidate access points, by the peer, by the serving attachment +point, or by some other entity; +discovery of the authentication services supported at a given candidate +access +point; +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; +peer discovery of the local domain name (LDN) when EAP re-authentication +is used with a local server. + +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. + + 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 . AAK also needs +an extension of ER key management.] + +

+ ++------------------------------------------------------------+ +| 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 | ++------------------------------------------------------------+ + +Arrows show the direction of functional dependency. + + + shows the following dependencies: + +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. + +Pre-authentication triggers AAA network access authentication and +authorization at each candidate access point, which in turn causes full EAP +authentication to be invoked. + + EAP re-authentication invokes ER key management at the time of +authentication to create and distribute keying material to ER servers. + +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. + + + +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. + +

+ +

+ +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 . No document is +yet available to describe the implementation of pre-authentication +in terms of specific protocols. +could be part of the solution, but is Experimental rather +than Standards Track. + +

+ +

+ +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. +provides the design objectives for an implementation of this function. + describes a protocol to implement EAP +re-authentication subject to the architectural restrictions noted +above. Work is in progress to relax those restrictions. + +

+ +

+ +The EAP authentication function is responsible for authenticating +the peer at a specific access point using a full EAP exchange. + defines the associated protocol. + 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 , although +is a candidate. + + +

+ +

+ +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 . +A protocol implementation is being specified +in . + +

+ +

+ + EAP-based handover key management consists of EAP method +independent key derivation and distribution and comprises the following +specific functions: + + handover key derivation; and + handover key distribution. + +The derivation of handover keys is specified in , and key distribution is specified in . + +

+ +

+ +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. + describes the different +deployment scenarios that are possible using these functions. + +The components of the HOKEY architecture are as follows: + + the peer; + the authenticator, which is a part of the serving access point + and candidate access points; + the EAP server; and + the ER server, either in the home domain or local to the + authenticator. + +[EDITOR'S NOTE: probably have to add the ER/AAK server named +in to this list.] + + +

+ +The peer participates in the functions described in +as shown in . + + +Function +Peer Role + +EAP authentication +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. +- +- + +Direct pre-authentication +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. +- +- + +Indirect pre-authentication +Enters into a full EAP exchange when triggered, using either L2 +or L3 transport for the frames. +- +- + +EAP re-authentication +Determines that EAP re-authentication is possible based on +discovery or authenticator prompting. Discovers ER server. +Participates in ERP exchange with ER server. +- +- + +Authenticated anticipatory keying +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. + +- +- + +ER key management +No role. + + + +

+ +

+ +The serving authenticator participates in the functions described +in +as shown in . + + +Function +Serving Authenticator Role + +EAP authentication +No role. +- +- + +Direct pre-authentication +No role. +- +- + +Indirect pre-authentication +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. +- +- + +EAP re-authentication +No role. +- +- + +Authenticated anticipatory keying +Mediates between L2 transport of AAK frames on the peer side +and AAA transport toward the ER/AAK server. +- +- + +ER key management +No role. + + +

+ +

+ +The candidate authenticator participates in the functions described +in +as shown in . + + +Function +Candidate Authenticator Role + +EAP authentication +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. +- +- + +Direct pre-authentication +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. +- +- + +Indirect pre-authentication +Same as direct pre-authentication, except that it communicates with +the serving authenticator rather than the peer. +- +- + +EAP re-authentication +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. +- +- + +Authenticated anticipatory keying +Receives and saves pMSK. +- +- + +ER key management +No role. + + +

+ +

+ +The EAP server participates in the functions described in + +as shown in . + + +Function +EAP Server Role + +EAP authentication +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. +- +- + +Direct pre-authentication +As for EAP authentication. +- +- + +Indirect pre-authentication +As for EAP authentication. +- +- + +EAP re-authentication +Mutually authenticates with the ER server and authorizes it for +receiving keying amterial. Provides rRK or DSrRK to the ER server. +- +- + +Authenticated anticipatory keying +As for EAP re-authentication. +- +- + +ER key management +Creates rRK or DSrRK and distributes it to ER server requesting the +information. + + +

+ +

+ +The ER server participates in the functions described in + +as shown in . [EDITOR'S NOTE: Need discussion of +respective roles of local and home ER server, or whether there should even be +such a distinction.] + + +Function +ER Server Role + +EAP authentication +No role. +- +- + +Direct pre-authentication +No role. +- +- + +Indirect pre-authentication +No role. +- +- + +EAP re-authentication +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. +- +- + +Authenticated anticipatory keying +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. +- +- + +ER key management +Receives and saves rRK or DSrRK as applicable. + + +

+ +

+ + +

+ +The necessity for this section and its contents are TBD. + +

+ + +

+ TBD. +

+ +

+ TBD +

+ +

+ This document has no actions for IANA. +

+ +

+ The authors would like to thank Mark Jones and Zhen Cao + for their reviews of previous versions of this draft. +