|
61
|
1 <?xml version="1.0" encoding="UTF-8"?> |
|
|
2 <?xml-stylesheet type='text/xsl' |
|
|
3 href='http://xml.resource.org/authoring/rfc2629.xslt' ?> |
|
|
4 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ |
|
|
5 <!ENTITY rfc2119 PUBLIC "" |
|
|
6 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> |
|
|
7 <!ENTITY rfc2828 PUBLIC "" |
|
|
8 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2828.xml"> |
|
|
9 <!ENTITY rfc2865 PUBLIC "" |
|
|
10 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml"> |
|
|
11 <!ENTITY rfc3588 PUBLIC "" |
|
|
12 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml"> |
|
|
13 <!ENTITY rfc3748 PUBLIC "" |
|
|
14 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml"> |
|
|
15 <!ENTITY rfc4306 PUBLIC "" |
|
|
16 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml"> |
|
|
17 <!ENTITY rfc4962 PUBLIC "" |
|
|
18 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml"> |
|
|
19 <!ENTITY rfc5169 PUBLIC "" |
|
|
20 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5169.xml"> |
|
|
21 <!ENTITY rfc5295 PUBLIC "" |
|
|
22 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml"> |
|
|
23 <!ENTITY rfc5296 PUBLIC "" |
|
|
24 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml"> |
|
|
25 <!ENTITY rfc5749 PUBLIC "" |
|
|
26 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5749.xml"> |
|
|
27 <!ENTITY rfc5836 PUBLIC "" |
|
|
28 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5836.xml"> |
|
|
29 <!ENTITY rfc5873 PUBLIC "" |
|
|
30 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5873.xml"> |
|
|
31 ]> |
|
|
32 <?rfc toc="yes"?> |
|
|
33 <?rfc symrefs="yes"?> |
|
|
34 <?rfc compact="yes"?> |
|
|
35 <?rfc subcompact="no"?> |
|
|
36 <rfc category="info" docName="draft-ietf-hokey-arch-design-01" |
|
|
37 ipr="trust200902"> |
|
|
38 <front> |
|
|
39 <title abbrev="Architecture Design">Handover Keying (HOKEY) Architecture |
|
|
40 Design</title> |
|
|
41 |
|
|
42 <author fullname="Katrin Hoeper" initials="K." surname="Hoeper"> |
|
|
43 <organization abbrev="Motorola">Motorola, Inc.</organization> |
|
|
44 |
|
|
45 <address> |
|
|
46 <postal> |
|
|
47 <street>1301 E. Algonquin Road</street> |
|
|
48 |
|
|
49 <city>Schaumburg</city> |
|
|
50 |
|
|
51 <region>IL</region> |
|
|
52 |
|
|
53 <code>60196</code> |
|
|
54 |
|
|
55 <country>USA</country> |
|
|
56 </postal> |
|
|
57 |
|
|
58 <email>khoeper@motorola.com</email> |
|
|
59 </address> |
|
|
60 </author> |
|
|
61 |
|
|
62 <author fullname="Sebastien Decugis" initials="S." surname="Decugis"> |
|
|
63 <organization abbrev="NICT">NICT</organization> |
|
|
64 |
|
|
65 <address> |
|
|
66 <postal> |
|
|
67 <street>4-2-1 Nukui-Kitamachi</street> |
|
|
68 |
|
|
69 <city>Tokyo</city> |
|
|
70 |
|
|
71 <region>Koganei</region> |
|
|
72 |
|
|
73 <code>184-8795</code> |
|
|
74 |
|
|
75 <country>Japan</country> |
|
|
76 </postal> |
|
|
77 |
|
|
78 <email>sdecugis@nict.go.jp</email> |
|
|
79 </address> |
|
|
80 </author> |
|
|
81 |
|
|
82 <author fullname="Glen Zorn" initials="G." surname="Zorn"> |
|
|
83 <organization abbrev="Network Zen">Network Zen</organization> |
|
|
84 |
|
|
85 <address> |
|
|
86 <postal> |
|
|
87 <street>1310 East Thomas Street</street> |
|
|
88 |
|
|
89 <city>Seattle</city> |
|
|
90 |
|
|
91 <region>Washington</region> |
|
|
92 |
|
|
93 <code>98102</code> |
|
|
94 |
|
|
95 <country>USA</country> |
|
|
96 </postal> |
|
|
97 |
|
|
98 <email>gwz@net-zen.net</email> |
|
|
99 </address> |
|
|
100 </author> |
|
|
101 |
|
|
102 <author fullname="Qin Wu" initials="Q." surname="Wu"> |
|
|
103 <organization abbrev="Huawei">Huawei Technologies Co.,Ltd</organization> |
|
|
104 |
|
|
105 <address> |
|
|
106 <postal> |
|
|
107 <street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia |
|
|
108 Rd.</street> |
|
|
109 |
|
|
110 <city>Nanjing</city> |
|
|
111 |
|
|
112 <region>JiangSu</region> |
|
|
113 |
|
|
114 <code>210001</code> |
|
|
115 |
|
|
116 <country>China</country> |
|
|
117 </postal> |
|
|
118 |
|
|
119 <phone>+86-25-84565892</phone> |
|
|
120 |
|
|
121 <email>sunseawq@huawei.com</email> |
|
|
122 </address> |
|
|
123 </author> |
|
|
124 |
|
|
125 <author fullname="Tom Taylor" initials="T." surname="Taylor"> |
|
|
126 <organization abbrev="Huawei">Huawei Technologies Co., Ltd</organization> |
|
|
127 |
|
|
128 <address> |
|
|
129 <postal> |
|
|
130 |
|
|
131 <street></street> |
|
|
132 |
|
|
133 <city>Ottawa </city> |
|
|
134 |
|
|
135 <country>Canada</country> |
|
|
136 </postal> |
|
|
137 |
|
|
138 <email>tom111.taylor@bell.net </email> |
|
|
139 </address> |
|
|
140 </author> |
|
|
141 |
|
|
142 <date year="2010" /> |
|
|
143 |
|
|
144 <workgroup>Network Working Group</workgroup> |
|
|
145 |
|
|
146 <abstract> |
|
|
147 <t>The Handover Keying (HOKEY) Working Group seeks to minimize handover delay |
|
|
148 due to authentication when a peer moves from one point of attachment to another. |
|
|
149 Work has progressed on two different approaches to reduce handover delay: |
|
|
150 early authentication (so that authentication does not need to be performed |
|
|
151 during handover), and reuse of cryptographic material generated during an |
|
|
152 initial authentication to save time during re-authentication. A starting |
|
|
153 assumption is that the mobile host or "peer" is initially authenticated using |
|
|
154 the Extensible Authentication Protocol (EAP), executed between the peer and an |
|
|
155 EAP server as defined in RFC 3748.</t> |
|
|
156 |
|
|
157 <t>This document documents the HOKEY architecture. Specifically, it describes |
|
|
158 design objectives, the functional environment within which handover keying |
|
|
159 operates, the functions to be performed by the HOKEY architecture itself, and |
|
|
160 the assignment of those functions to architectural components. It goes on to |
|
|
161 illustrate the operation of the architecture within various deployment |
|
|
162 scenarios that are described more fully in other |
|
|
163 documents produced by the HOKEY Working Group. </t> |
|
|
164 </abstract> |
|
|
165 </front> |
|
|
166 |
|
|
167 <middle> |
|
|
168 <section title="Introduction"> |
|
|
169 |
|
|
170 <t>The Extensible Authentication Protocol (EAP) <xref |
|
|
171 target="RFC3748"></xref> is an authentication framework that supports different |
|
|
172 types of authentication methods. Originally designed for dial-up connections, |
|
|
173 EAP is now commonly used for authentication in wireless access networks.</t> |
|
|
174 |
|
|
175 <t>When a host (or "peer", the term used from this point onward) changes its |
|
|
176 point of attachment to the network, it must be re-authenticated. If a full EAP |
|
|
177 authentication must be repeated, several message round-trips between the peer |
|
|
178 and the home EAP server may be involved. The resulting delay will result in |
|
|
179 degradation or in the worst case loss of any service session in progress if |
|
|
180 communication is suspended while re-authentication is carried out. The delay is |
|
|
181 worse if the new point of attachment is in a visited network rather than the |
|
|
182 peer's home network, because of the extra procedural steps involved as well as |
|
|
183 because of the probable increase in round-trip time. </t> |
|
|
184 |
|
|
185 <t><xref target="RFC5169"/> describes this problem more fully and establishes |
|
|
186 design goals for solutions to reduce re-authentication delay for transfers |
|
|
187 within a single administrative domain. <xref target="RFC5169"/> also suggests a |
|
|
188 number of ways to achieve a solution: |
|
|
189 <list style="symbols"> |
|
|
190 <t>specification of a method-independent, efficient, re-authentication |
|
|
191 protocol;</t> |
|
|
192 |
|
|
193 <t>reuse of keying material from the initial authentication;</t> |
|
|
194 |
|
|
195 <t>deployment of re-authentication servers local to the peer to reduce |
|
|
196 round-trip delay; and</t> |
|
|
197 |
|
|
198 <t>specification of the additional protocol needed to allow the EAP |
|
|
199 server to pass authentication information to the local re-authentication |
|
|
200 servers.</t> |
|
|
201 </list> |
|
|
202 </t> |
|
|
203 <t><xref target="RFC5295"/> tackles the problem of reuse of keying material |
|
|
204 by specifying how to derive a hierarchy of cryptographically independent |
|
|
205 purpose-specific keys from the results of the original EAP authentication. |
|
|
206 <xref target="RFC5296"/> specifies a method-independent re-authentication |
|
|
207 protocol (ERP) applicable to two specific deployment scenarios: |
|
|
208 <list style="symbols"> |
|
|
209 <t>where the peer's home EAP server also performs re-authentication; |
|
|
210 and</t> |
|
|
211 <t>where a local re-authentication server exists but is collocated with a |
|
|
212 AAA proxy within the domain.</t> |
|
|
213 </list> |
|
|
214 </t> |
|
|
215 |
|
|
216 <t>Other work provides further pieces of the solution or insight |
|
|
217 into the problem. For the purpose of this draft, <xref target="RFC5749"/> provides an abstract mechanism |
|
|
218 for distribution of keying material from the EAP server to re-authentication servers. <xref target="RFC5836"/> |
|
|
219 contrasts the EAP re-authentication (ER) strategy provided by <xref target="RFC5296"/> with an alternative strategy called "early authentication". |
|
|
220 <xref target="RFC5836"></xref> defines EAP early |
|
|
221 authentication as the use of EAP by a mobile peer to establish authenticated |
|
|
222 keying material on a target attachment point prior to its arrival. Here, a full |
|
|
223 EAP execution occurs before the handover of the peer takes place. Hence, the |
|
|
224 goal of EAP early authentication is to complete all EAP-related communications, |
|
|
225 including AAA signaling, in preparation for the handover, before the mobile |
|
|
226 device actually moves. Early authentication includes direct and indirect pre-authentication as well as Authenticated Anticipatory Keying (AKK). |
|
|
227 All three mechanims provide means to execute a full EAP authentication with a Candidate Access Point (CAP) while still being connected to the Serving |
|
|
228 Access Point (SAP) but vary in their |
|
|
229 respective system assumptions and communication paths. In particular, direct pre-authentication assumes that clients are capable of discovering candidate |
|
|
230 access points and all communications are routed through the serving access point. On the other hand, indirect pre-authentication assumes an |
|
|
231 existing relationship betweem SAP and CAP, whereas in AAK the client interacts with the AAA to discover and connect to CAPs.</t> |
|
|
232 |
|
|
233 |
|
|
234 |
|
|
235 |
|
|
236 <t>Both EAP re-authentication and early authentication enable faster |
|
|
237 inter-authenticator handovers. However, it is currently unclear how the |
|
|
238 necessary handover infrastructure is deployed and can be integrated into existing |
|
|
239 EAP infrastructures. In particular, previous work has not described how ER |
|
|
240 servers that act as endpoints in the re-authentication process should be integrated into local and home domain |
|
|
241 networks. Furthermore, it is currently unspecified how EAP infrastructure can |
|
|
242 support the timely triggering of early authentications and aid with the selection of candidate access points.</t> |
|
|
243 |
|
|
244 <t>This document proposes a general HOKEY architecture and demonstrates |
|
|
245 how it can be adapted to different deployment scenarios. To begin with, <xref |
|
|
246 target="goals"/> recalls the design objectives for the HOKEY architecture. <xref |
|
|
247 target="fncns"/> reviews the functions that must be supported within the |
|
|
248 architecture. <xref target="compon"/> describes the components of the HOKEY |
|
|
249 architecture. Finally, <xref target="scen"/> describes the different deployment |
|
|
250 scenarios that the HOKEY Working Group has addressed and the information flows |
|
|
251 that must occur within those scenarios, by reference to the documents |
|
|
252 summarized above where possible and otherwise within this document itself.</t> |
|
|
253 |
|
|
254 </section><!-- Introduction --> |
|
|
255 |
|
|
256 <section anchor="terms" title="Terminology"> |
|
|
257 |
|
|
258 <t>This document contains no normative language, hence |
|
|
259 <xref target="RFC2119"/> language does not apply.</t> |
|
|
260 |
|
|
261 <t>This document reuses most of the terms defined in Section 2.2 of |
|
|
262 <xref target="RFC5836"/>. In addition, it defines the following: |
|
|
263 |
|
|
264 <list style="hanging"> |
|
|
265 <t hangText="EAP Early Authentication"><vspace blankLines="0" /> |
|
|
266 The use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival, |
|
|
267 see <xref target="RFC5836"></xref>. |
|
|
268 </t> |
|
|
269 |
|
|
270 <t hangText="EAP Re-authentication (ER)"><vspace blankLines="0" /> |
|
|
271 The use of keying material derived from an initial EAP authentication |
|
|
272 to enable single-roundtrip re-authentication of a mobile peer. For a |
|
|
273 detailed description of the keying material see Section 3 of |
|
|
274 <xref target="RFC5296"/>. |
|
|
275 </t> |
|
|
276 |
|
|
277 <t hangText="ER Server"><vspace blankLines="0" /> |
|
|
278 A component of the HOKEY architecture that terminates the EAP |
|
|
279 re-authentication exchange with the peer. |
|
|
280 </t> |
|
|
281 |
|
|
282 <t hangText="ER Key Management"><vspace blankLines="0" /> |
|
|
283 An instantiation of the mechanism provided by <xref target="RFC5749"/> for |
|
|
284 creating and delivering root keys from an EAP server to an ER server. |
|
|
285 </t> |
|
|
286 |
|
|
287 </list> |
|
|
288 </t> |
|
|
289 </section> |
|
|
290 |
|
|
291 <section anchor="goals" title="Design Goals"> |
|
|
292 |
|
|
293 <t>This section investigates the design goals for the HOKEY |
|
|
294 architecture. These include reducing the signaling overhead for re- |
|
|
295 authentication and early authentication, integrating local domain name |
|
|
296 discovery, |
|
|
297 and improving deployment scalability. |
|
|
298 These goals supplement the discussion in <xref target="RFC5169"/>.</t> |
|
|
299 |
|
|
300 <section anchor="sigOvhd" title="Reducing Signalling Overhead"> |
|
|
301 |
|
|
302 <section title="Minimized Communications with Home Servers"> |
|
|
303 |
|
|
304 <t>ERP requires only one round trip, however, this roundtrip may |
|
|
305 require communications between a peer and its home ER and/or home AAA server |
|
|
306 even if the peer is currently attached to a visited (local) network. As a |
|
|
307 result, even this one round trip may introduce long delays because home ER and |
|
|
308 home AAA servers may be distant from the peer. To lower the signaling overhead, |
|
|
309 communication with the home ER server and home AAA server should be minimized. |
|
|
310 Ideally, a peer should only need to communicate with local servers and other |
|
|
311 local entities.</t> |
|
|
312 |
|
|
313 </section> |
|
|
314 |
|
|
315 <section title="Integrated Local Domain Name (LDN) Discovery"> |
|
|
316 |
|
|
317 <t> ERP bootstrapping must occur before (implicit) or during (explicit) a |
|
|
318 handover to transport the necessary re-authentication root keys to the local ER |
|
|
319 server involved. Implicit bootstrapping is preferable because it does not |
|
|
320 require communication with the home ER server during handover (see previous |
|
|
321 section), but it requires the peer to know the domain name of the ER server in |
|
|
322 order to derive the necessary re-authentication keying material. <xref |
|
|
323 target="RFC5296"></xref> does not specify such a domain name discovery |
|
|
324 mechanism and suggests that the peer may learn the domain name through the EAP- |
|
|
325 Initiate/Re-auth-Start message or via lower layer announcements. To allow more |
|
|
326 efficient handovers, a HOKEY architecture should support an efficient domain |
|
|
327 name discovery mechanism and allow its integration with ERP implicit |
|
|
328 bootstrapping. Even in the case of explicit bootstrapping, local domain name |
|
|
329 discovery should be optimized such that it does not require contacting the home |
|
|
330 AAA server, as is currently the case.</t> |
|
|
331 |
|
|
332 </section> |
|
|
333 |
|
|
334 </section><!-- sigOvhd --> |
|
|
335 |
|
|
336 <section title="Better Deployment Scalability"> |
|
|
337 |
|
|
338 <t>To provide better deployment scalability, it should not be required |
|
|
339 that the HOKEY server and AAA servers or proxies are collocated. Separation of |
|
|
340 these entities may cause problems with routing, but allows flexibility in |
|
|
341 deployment and implementation.</t> |
|
|
342 |
|
|
343 </section> |
|
|
344 |
|
|
345 </section> |
|
|
346 |
|
|
347 <section anchor="fncns" title="Functions That Must Be Supported"> |
|
|
348 <section title="System Overview"> |
|
|
349 |
|
|
350 <t>This section views the HOKEY architecture as the implementation of a |
|
|
351 subsystem providing authentication services to AAA. Not only does AAA depend on |
|
|
352 the authentication subsystem, but the latter also depends on AAA as a means for |
|
|
353 the routing and secure transport of messages internal to the operation of |
|
|
354 network access authentication.</t> |
|
|
355 |
|
|
356 <t>The operation of the authentication subsystem also depends on the |
|
|
357 availability of a number of discovery functions: |
|
|
358 <list style="symbols"> |
|
|
359 <t>discovery of candidate access points, by the peer, by the serving attachment |
|
|
360 point, or by some other entity;</t> |
|
|
361 <t>discovery of the authentication services supported at a given candidate |
|
|
362 access |
|
|
363 point;</t> |
|
|
364 <t>discovery of the required server in the home domain when a candidate |
|
|
365 access point is not in the same domain as the serving attachment point, or |
|
|
366 no local server is available;</t> |
|
|
367 <t>peer discovery of the local domain name (LDN) when EAP re-authentication |
|
|
368 is used with a local server. </t> |
|
|
369 </list> |
|
|
370 It is assumed that |
|
|
371 these functions are provided by the environment within which the |
|
|
372 authentication subsystem operates, and are outside the scope of the |
|
|
373 authentication subsystem itself. Local domain name discovery is |
|
|
374 a possible exception. </t> |
|
|
375 |
|
|
376 <t><xref target="fig_fctlOver"/> shows the major functions comprising |
|
|
377 the authentication subsystem and their interdependencies. These functions |
|
|
378 are described below. |
|
|
379 [EDITOR'S NOTE: These probably need refinement. The relationship |
|
|
380 of pre-authentication to EAP authentication, for instance, is |
|
|
381 currently not totally correct, when one takes account of the |
|
|
382 roles described in <xref target="compon"/>. AAK also needs |
|
|
383 an extension of ER key management.]</t> |
|
|
384 |
|
|
385 <figure anchor="fig_fctlOver" title="Authentication Subsystem |
|
|
386 Functional Overview"> |
|
|
387 <artwork> |
|
|
388 +------------------------------------------------------------+ |
|
|
389 | AAA Network Access Authentication and Authorization | |
|
|
390 +---+-------------.----------------------------+-------------+ |
|
|
391 | /|\ | |
|
|
392 | | Authentication subsystem | |
|
|
393 +===|=============|============================|=============+ |
|
|
394 | | +---------+----------+ +-------------V---------+ | |
|
|
395 | | | Direct and | | EAP Re-authentication | | |
|
|
396 | | | Indirect | +--+------+-------------+ | |
|
|
397 | | | Pre-Authentication | / / | |
|
|
398 | | +--------------------+ / / | |
|
|
399 | | / / +---------------+ | |
|
|
400 | | / | | Authenticated | | |
|
|
401 | | / | | Anticipatory | | |
|
|
402 | | / | | Keying (AAK) | | |
|
|
403 | | / | +-------+-------+ | |
|
|
404 | | / | | | |
|
|
405 | +-V------------------+ / +---------V----------V--------+ | |
|
|
406 | | EAP Authentication | | | ER Key Management | | |
|
|
407 | +---------+----------+ | |+------------+ +------------+| | |
|
|
408 | | | ||Handover Key| |Handover Key|| | |
|
|
409 | | | || Derivation | |Distribution|| | |
|
|
410 | | | |+------------+ +------+-----+| | |
|
|
411 | | | +----------------------|------+ | |
|
|
412 +===========|=============|=========================|========+ |
|
|
413 | | | |
|
|
414 +-----------V-------------V-------------------------V--------+ |
|
|
415 | AAA routing and secure transport | |
|
|
416 +------------------------------------------------------------+ |
|
|
417 </artwork> |
|
|
418 <postamble>Arrows show the direction of functional dependency.</postamble> |
|
|
419 </figure> |
|
|
420 |
|
|
421 <t><xref target="fig_fctlOver"/> shows the following dependencies: |
|
|
422 <list style="symbols"> |
|
|
423 <t>When AAA is invoked to authenticate and authorize network access, it uses one |
|
|
424 of two services offered by the authentication subsystem: full EAP |
|
|
425 authentication, or EAP re-authentication.</t> |
|
|
426 |
|
|
427 <t>Pre-authentication triggers AAA network access authentication and |
|
|
428 authorization at each candidate access point, which in turn causes full EAP |
|
|
429 authentication to be invoked. </t> |
|
|
430 |
|
|
431 <t> EAP re-authentication invokes ER key management at the time of |
|
|
432 authentication to create and distribute keying material to ER servers.</t> |
|
|
433 |
|
|
434 <t>Authenticated anticipatory keying (AAK) relies on ER key management to |
|
|
435 establish keying material on ER/AAK servers, but uses an extension |
|
|
436 to ER key management to derive and establish keying material on |
|
|
437 candidate authenticators.</t> |
|
|
438 </list> |
|
|
439 </t> |
|
|
440 |
|
|
441 <t>EAP authentication, EAP re-authentication, and handover key distribution |
|
|
442 depend on the routing and secure transport service |
|
|
443 provided by AAA. Discovery functions and the function of authentication and |
|
|
444 authorization of network entities (access points, ER servers) |
|
|
445 are not shown. As stated above, these are external to the authentication |
|
|
446 subsystem.</t> |
|
|
447 |
|
|
448 </section><!-- System Overview --> |
|
|
449 |
|
|
450 <section anchor="preauth" title="Pre-Authentication Function (Direct or |
|
|
451 Indirect)"> |
|
|
452 |
|
|
453 <t>The pre-authentication function is responsible for discovery of candidate |
|
|
454 access points and completion of network access authentication and |
|
|
455 authorization at each candidate access point in advance of handover. The operation of this function |
|
|
456 is described in general terms in <xref target="RFC5836"/>. No document is |
|
|
457 yet available to describe the implementation of pre-authentication |
|
|
458 in terms of specific protocols. <xref target="RFC5873"/> |
|
|
459 could be part of the solution, but is Experimental rather |
|
|
460 than Standards Track.</t> |
|
|
461 |
|
|
462 </section><!-- preauth --> |
|
|
463 |
|
|
464 <section anchor="reauth" title="EAP Re-authentication Function"> |
|
|
465 |
|
|
466 <t>The EAP re-authentication function is responsible for authenticating |
|
|
467 the peer at a specific access point using keying material |
|
|
468 derived from a prior full EAP authentication. <xref target="RFC5169"/> |
|
|
469 provides the design objectives for an implementation of this function. |
|
|
470 <xref target="RFC5296"/> describes a protocol to implement EAP |
|
|
471 re-authentication subject to the architectural restrictions noted |
|
|
472 above. Work is in progress to relax those restrictions.</t> |
|
|
473 |
|
|
474 </section><!-- reauth --> |
|
|
475 |
|
|
476 <section anchor="EAPauthen" title="EAP Authentication Function"> |
|
|
477 |
|
|
478 <t>The EAP authentication function is responsible for authenticating |
|
|
479 the peer at a specific access point using a full EAP exchange. |
|
|
480 <xref target="RFC3748"/> defines the associated protocol. |
|
|
481 <xref target="RFC5836"/> shows the use of EAP as part of |
|
|
482 pre-authentication. Note that the HOKEY Working Group has not specified |
|
|
483 the non-AAA protocol required |
|
|
484 to transport EAP frames over IP that is shown in Figures 3 and 5 |
|
|
485 of <xref target="RFC5836"/>, although <xref target="RFC5873"/> |
|
|
486 is a candidate. |
|
|
487 </t> |
|
|
488 |
|
|
489 </section><!-- EAPauthen --> |
|
|
490 |
|
|
491 <section anchor="AAKfcn" title="Authenticated Anticipatory Keying (AAK) |
|
|
492 Function"> |
|
|
493 |
|
|
494 <t>The authenticated anticipatory keying function is responsible for |
|
|
495 pre-placing keying material derived from an initial full EAP authentication |
|
|
496 on candidate access points. The operation is carried out in two steps: |
|
|
497 ER key management (with trigger not currently specified) places root |
|
|
498 keys derived from initial EAP authentication onto an ER/AAK server |
|
|
499 associated with the peer. When requested by the peer, the ER/AAK server |
|
|
500 derives and pushes predefined master session keys to a list of |
|
|
501 candidate access points. The operation |
|
|
502 of the authenticated anticipatory keying function is described in very |
|
|
503 general terms in <xref target="RFC5836"/>. |
|
|
504 A protocol implementation is being specified |
|
|
505 in <xref target="I-D.ietf-hokey-erp-aak"/>.</t> |
|
|
506 |
|
|
507 </section><!-- AAKfcn --> |
|
|
508 |
|
|
509 <section anchor="keyMgmt" title="EAP-Based Handover Key Management"> |
|
|
510 |
|
|
511 <t>EAP-based handover key management consists of EAP method |
|
|
512 independent key derivation and distribution and comprises the following |
|
|
513 specific functions: |
|
|
514 <list style="symbols"> |
|
|
515 <t>handover key derivation; and</t> |
|
|
516 <t>handover key distribution.</t> |
|
|
517 </list> |
|
|
518 The derivation of handover keys is specified in <xref |
|
|
519 target="RFC5295"></xref>, and key distribution is specified in <xref |
|
|
520 target="RFC5749"></xref>.</t> |
|
|
521 |
|
|
522 </section><!-- keyMgmt --> |
|
|
523 |
|
|
524 </section><!-- fncns --> |
|
|
525 |
|
|
526 <section anchor="compon" title="Components of the HOKEY Architecture"> |
|
|
527 |
|
|
528 <t>This section describes the components of the HOKEY architecture, in terms |
|
|
529 of the functions they perform. The components cooperate as described in |
|
|
530 this section to carry out the functions described in the previous section. |
|
|
531 <xref target="scen"/> describes the different |
|
|
532 deployment scenarios that are possible using these functions.</t> |
|
|
533 |
|
|
534 <t>The components of the HOKEY architecture are as follows: |
|
|
535 <list style="symbols"> |
|
|
536 <t>the peer;</t> |
|
|
537 <t>the authenticator, which is a part of the serving access point |
|
|
538 and candidate access points;</t> |
|
|
539 <t>the EAP server; and</t> |
|
|
540 <t>the ER server, either in the home domain or local to the |
|
|
541 authenticator.</t> |
|
|
542 </list> |
|
|
543 [EDITOR'S NOTE: probably have to add the ER/AAK server named |
|
|
544 in <xref target="I-D.ietf-hokey-erp-aak"/> to this list.] |
|
|
545 </t> |
|
|
546 |
|
|
547 <section anchor="peerFnc" title="Functions of the Peer"> |
|
|
548 |
|
|
549 <t>The peer participates in the functions described in <xref target="fncns"/> |
|
|
550 as shown in <xref target="tab_peerFnc"/>.</t> |
|
|
551 |
|
|
552 <texttable anchor="tab_peerFnc" title="Functions of the Peer"> |
|
|
553 <ttcol>Function</ttcol> |
|
|
554 <ttcol>Peer Role</ttcol> |
|
|
555 |
|
|
556 <c>EAP authentication</c> |
|
|
557 <c>Determines that full EAP authentication is needed based on context |
|
|
558 (e.g., initial authentication), prompting from the authenticator, or |
|
|
559 discovery that only EAP authentication is supported. Participates |
|
|
560 in the EAP exchange with the EAP server.</c> |
|
|
561 <c>-</c> |
|
|
562 <c>-</c> |
|
|
563 |
|
|
564 <c>Direct pre-authentication</c> |
|
|
565 <c>Discovers candidate access points. Initiates pre-authentication |
|
|
566 with each, followed by EAP authentication as above, but using IP |
|
|
567 rather than L2 transport for the EAP frames.</c> |
|
|
568 <c>-</c> |
|
|
569 <c>-</c> |
|
|
570 |
|
|
571 <c>Indirect pre-authentication</c> |
|
|
572 <c>Enters into a full EAP exchange when triggered, using either L2 |
|
|
573 or L3 transport for the frames. </c> |
|
|
574 <c>-</c> |
|
|
575 <c>-</c> |
|
|
576 |
|
|
577 <c>EAP re-authentication</c> |
|
|
578 <c>Determines that EAP re-authentication is possible based on |
|
|
579 discovery or authenticator prompting. Discovers ER server. |
|
|
580 Participates in ERP exchange with ER server.</c> |
|
|
581 <c>-</c> |
|
|
582 <c>-</c> |
|
|
583 |
|
|
584 <c>Authenticated anticipatory keying</c> |
|
|
585 <c>Determines that AAK is possible based on discovery or |
|
|
586 serving authenticator prompting. Discovers candidate access points. |
|
|
587 Sends request to serving authenticator to distribute keying |
|
|
588 material to the candidate access points. |
|
|
589 </c> |
|
|
590 <c>-</c> |
|
|
591 <c>-</c> |
|
|
592 |
|
|
593 <c>ER key management</c> |
|
|
594 <c>No role.</c> |
|
|
595 </texttable> |
|
|
596 |
|
|
597 |
|
|
598 </section><!-- peerFnc --> |
|
|
599 |
|
|
600 <section anchor="saFnc" title="Functions of the Serving Authenticator"> |
|
|
601 |
|
|
602 <t>The serving authenticator participates in the functions described |
|
|
603 in <xref target="fncns"/> |
|
|
604 as shown in <xref target="tab_saFnc"/>.</t> |
|
|
605 |
|
|
606 <texttable anchor="tab_saFnc" title="Functions of the Serving Authenticator"> |
|
|
607 <ttcol>Function</ttcol> |
|
|
608 <ttcol>Serving Authenticator Role</ttcol> |
|
|
609 |
|
|
610 <c>EAP authentication</c> |
|
|
611 <c>No role. </c> |
|
|
612 <c>-</c> |
|
|
613 <c>-</c> |
|
|
614 |
|
|
615 <c>Direct pre-authentication</c> |
|
|
616 <c>No role.</c> |
|
|
617 <c>-</c> |
|
|
618 <c>-</c> |
|
|
619 |
|
|
620 <c>Indirect pre-authentication</c> |
|
|
621 <c>Discovers candidate access points. Initiates an EAP exchange |
|
|
622 between the peer and the EAP server through each candidate |
|
|
623 authenticator. Mediates between L2 transport of EAP frames on the peer |
|
|
624 side and a non-AAA protocol over IP toward the candidate access point.</c> |
|
|
625 <c>-</c> |
|
|
626 <c>-</c> |
|
|
627 |
|
|
628 <c>EAP re-authentication</c> |
|
|
629 <c>No role.</c> |
|
|
630 <c>-</c> |
|
|
631 <c>-</c> |
|
|
632 |
|
|
633 <c>Authenticated anticipatory keying</c> |
|
|
634 <c>Mediates between L2 transport of AAK frames on the peer side |
|
|
635 and AAA transport toward the ER/AAK server.</c> |
|
|
636 <c>-</c> |
|
|
637 <c>-</c> |
|
|
638 |
|
|
639 <c>ER key management</c> |
|
|
640 <c>No role.</c> |
|
|
641 </texttable> |
|
|
642 |
|
|
643 </section><!-- saFnc --> |
|
|
644 |
|
|
645 <section anchor="caFnc" title="Functions of the Candidate Authenticator"> |
|
|
646 |
|
|
647 <t>The candidate authenticator participates in the functions described |
|
|
648 in <xref target="fncns"/> |
|
|
649 as shown in <xref target="tab_caFnc"/>.</t> |
|
|
650 |
|
|
651 <texttable anchor="tab_caFnc" title="Functions of the Candidate Authenticator"> |
|
|
652 <ttcol>Function</ttcol> |
|
|
653 <ttcol>Candidate Authenticator Role</ttcol> |
|
|
654 |
|
|
655 <c>EAP authentication</c> |
|
|
656 <c>Invokes AAA network access authentication and authorization |
|
|
657 upon handover/initial attachment. |
|
|
658 Mediates between L2 transport of EAP frames on the peer link and AAA |
|
|
659 transport toward the EAP server.</c> |
|
|
660 <c>-</c> |
|
|
661 <c>-</c> |
|
|
662 |
|
|
663 <c>Direct pre-authentication</c> |
|
|
664 <c>Invokes AAA network access authentication and authorization |
|
|
665 when the peer initiates authentication. |
|
|
666 Mediates between non-AAA L3 transport of EAP frames on the peer side and AAA |
|
|
667 transport toward the EAP server. </c> |
|
|
668 <c>-</c> |
|
|
669 <c>-</c> |
|
|
670 |
|
|
671 <c>Indirect pre-authentication</c> |
|
|
672 <c>Same as direct pre-authentication, except that it communicates with |
|
|
673 the serving authenticator rather than the peer.</c> |
|
|
674 <c>-</c> |
|
|
675 <c>-</c> |
|
|
676 |
|
|
677 <c>EAP re-authentication</c> |
|
|
678 <c>Invokes AAA network access authentication and authorization upon handover. |
|
|
679 Discovers or is configured with the address of the ER server. |
|
|
680 Mediates between L2 transport of a ERP frames on the peer side |
|
|
681 and AAA transport toward the ER server.</c> |
|
|
682 <c>-</c> |
|
|
683 <c>-</c> |
|
|
684 |
|
|
685 <c>Authenticated anticipatory keying</c> |
|
|
686 <c>Receives and saves pMSK.</c> |
|
|
687 <c>-</c> |
|
|
688 <c>-</c> |
|
|
689 |
|
|
690 <c>ER key management</c> |
|
|
691 <c>No role.</c> |
|
|
692 </texttable> |
|
|
693 |
|
|
694 </section><!-- caFnc --> |
|
|
695 |
|
|
696 <section anchor="EAPsrvFnc" title="Functions of the EAP Server"> |
|
|
697 |
|
|
698 <t>The EAP server participates in the functions described in |
|
|
699 <xref target="fncns"/> |
|
|
700 as shown in <xref target="tab_EAPsrvFnc"/>.</t> |
|
|
701 |
|
|
702 <texttable anchor="tab_EAPsrvFnc" title="Functions of the EAP Server"> |
|
|
703 <ttcol>Function</ttcol> |
|
|
704 <ttcol>EAP Server Role</ttcol> |
|
|
705 |
|
|
706 <c>EAP authentication</c> |
|
|
707 <c>Authenticates and authorizes the candidate access point to act as |
|
|
708 authenticator. |
|
|
709 Terminates EAP signalling between it and the peer via the candidate |
|
|
710 authenticator. Determines whether |
|
|
711 network access authentication succeeds or fails. Provides MSK |
|
|
712 to authenticator.</c> |
|
|
713 <c>-</c> |
|
|
714 <c>-</c> |
|
|
715 |
|
|
716 <c>Direct pre-authentication</c> |
|
|
717 <c>As for EAP authentication.</c> |
|
|
718 <c>-</c> |
|
|
719 <c>-</c> |
|
|
720 |
|
|
721 <c>Indirect pre-authentication</c> |
|
|
722 <c>As for EAP authentication.</c> |
|
|
723 <c>-</c> |
|
|
724 <c>-</c> |
|
|
725 |
|
|
726 <c>EAP re-authentication</c> |
|
|
727 <c>Mutually authenticates with the ER server and authorizes it for |
|
|
728 receiving keying amterial. Provides rRK or DSrRK to the ER server.</c> |
|
|
729 <c>-</c> |
|
|
730 <c>-</c> |
|
|
731 |
|
|
732 <c>Authenticated anticipatory keying</c> |
|
|
733 <c>As for EAP re-authentication.</c> |
|
|
734 <c>-</c> |
|
|
735 <c>-</c> |
|
|
736 |
|
|
737 <c>ER key management</c> |
|
|
738 <c>Creates rRK or DSrRK and distributes it to ER server requesting the |
|
|
739 information.</c> |
|
|
740 </texttable> |
|
|
741 |
|
|
742 </section><!-- EAPsrvFnc --> |
|
|
743 |
|
|
744 <section anchor="ERsrvFnc" title="Functions of the ER Server"> |
|
|
745 |
|
|
746 <t>The ER server participates in the functions described in |
|
|
747 <xref target="fncns"/> |
|
|
748 as shown in <xref target="tab_ERsrvFnc"/>. [EDITOR'S NOTE: Need discussion of |
|
|
749 respective roles of local and home ER server, or whether there should even be |
|
|
750 such a distinction.]</t> |
|
|
751 |
|
|
752 <texttable anchor="tab_ERsrvFnc" title="Functions of the ER Server"> |
|
|
753 <ttcol>Function</ttcol> |
|
|
754 <ttcol>ER Server Role</ttcol> |
|
|
755 |
|
|
756 <c>EAP authentication</c> |
|
|
757 <c>No role.</c> |
|
|
758 <c>-</c> |
|
|
759 <c>-</c> |
|
|
760 |
|
|
761 <c>Direct pre-authentication</c> |
|
|
762 <c>No role.</c> |
|
|
763 <c>-</c> |
|
|
764 <c>-</c> |
|
|
765 |
|
|
766 <c>Indirect pre-authentication</c> |
|
|
767 <c>No role.</c> |
|
|
768 <c>-</c> |
|
|
769 <c>-</c> |
|
|
770 |
|
|
771 <c>EAP re-authentication</c> |
|
|
772 <c>Authenticates and authorizes the candidate access point to act as |
|
|
773 authenticator. Authenticates itself to the EAP server and acquires |
|
|
774 rRK or DSrRK as applicable when necessary. |
|
|
775 Terminates ERP signalling between it and the peer via the candidate |
|
|
776 authenticator. Determines whether |
|
|
777 network access authentication succeeds or fails. Provides MSK |
|
|
778 to authenticator.</c> |
|
|
779 <c>-</c> |
|
|
780 <c>-</c> |
|
|
781 |
|
|
782 <c>Authenticated anticipatory keying</c> |
|
|
783 <c>Authenticates itself to the EAP server and acquires |
|
|
784 rRK or DSrRK as applicable when necessary. Authenticates and authorizes |
|
|
785 the candidate access points to act as authenticator. Derives pMSKs and |
|
|
786 passes them to the candidate access points.</c> |
|
|
787 <c>-</c> |
|
|
788 <c>-</c> |
|
|
789 |
|
|
790 <c>ER key management</c> |
|
|
791 <c>Receives and saves rRK or DSrRK as applicable.</c> |
|
|
792 </texttable> |
|
|
793 |
|
|
794 </section><!-- ERsrvFnc --> |
|
|
795 |
|
|
796 </section><!-- compon --> |
|
|
797 |
|
|
798 |
|
|
799 <section anchor="scen" title="Deployment Scenarios"> |
|
|
800 |
|
|
801 <t>The necessity for this section and its contents are TBD.</t> |
|
|
802 |
|
|
803 </section><!-- scen --> |
|
|
804 |
|
|
805 |
|
|
806 <section title="AAA Consideration"> |
|
|
807 <section title="Standalone HOKEY server"> |
|
|
808 <t>TBD.</t> |
|
|
809 </section> |
|
|
810 </section> |
|
|
811 |
|
|
812 <section title="Security Considerations"> |
|
|
813 <t>TBD</t> |
|
|
814 </section> |
|
|
815 |
|
|
816 <section title="IANA Considerations"> |
|
|
817 <t>This document has no actions for IANA.</t> |
|
|
818 </section> |
|
|
819 |
|
|
820 <section title="Acknowledgments"> |
|
|
821 <t>The authors would like to thank Mark Jones and Zhen Cao |
|
|
822 for their reviews of previous versions of this draft.</t> |
|
|
823 </section> |
|
|
824 </middle> |
|
|
825 |
|
|
826 <back> |
|
|
827 <references title="Informative References"> |
|
|
828 &rfc2119; |
|
|
829 &rfc3748; |
|
|
830 &rfc5169; |
|
|
831 &rfc5295; |
|
|
832 &rfc5296; |
|
|
833 &rfc5749; |
|
|
834 &rfc5836; |
|
|
835 &rfc5873; |
|
|
836 |
|
|
837 <reference anchor="I-D.ietf-hokey-erp-aak"> |
|
|
838 <front> |
|
|
839 <title>EAP Re-authentication Protocol Extensions for Authenticated Anticipatory |
|
|
840 Keying (ERP/AAK)</title> |
|
|
841 <author fullname="Zhen Cao" initials="Z." surname="Cao"> |
|
|
842 <organization>China Mobile |
|
|
843 </organization> |
|
|
844 </author> |
|
|
845 <author fullname="Hui Deng" initials="H." surname="Deng"> |
|
|
846 <organization>China Mobile |
|
|
847 </organization> |
|
|
848 </author> |
|
|
849 <author fullname="Yungui Wang" initials="Y." surname="Wang"> |
|
|
850 <organization>Huawei Technologies</organization> |
|
|
851 </author> |
|
|
852 <author fullname="Qin Wu" initials="Q." surname="Wu"> |
|
|
853 <organization>Huawei technologies</organization> |
|
|
854 </author> |
|
|
855 <author fullname="Glen Zorn" initials="G." surname="Zorn"> |
|
|
856 <organization>Network Zen</organization> |
|
|
857 </author> |
|
|
858 <date month="May" year="2010" /> |
|
|
859 </front><seriesInfo name="Internet Draft" value="draft-ietf-hokey-erp-aak-02" /> |
|
|
860 |
|
|
861 </reference> |
|
|
862 |
|
|
863 |
|
|
864 </references> |
|
|
865 |
|
|
866 </back> |
|
|
867 </rfc> |
