Mercurial > hg > ietf

comparison draft-ietf-dime-erp-02.xml @ 39:0d94368e563c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Prepare document for revision -02, after submission of -01.
author Sebastien Decugis <sdecugis@nict.go.jp>
date Fri, 28 Aug 2009 18:46:55 +0900
parents draft-ietf-dime-erp-01.xml@45f0d51961cf
children 05f1b6f8af5d
comparison
equal deleted inserted replaced
38:45f0d51961cf 39:0d94368e563c
1 <?xml version="1.0" encoding="US-ASCII"?>
2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
3 <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
4 <!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
5 <!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
6 <!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml">
7 <!ENTITY RFC4187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml">
8 <!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
9 <!ENTITY RFC5295 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml">
10 <!ENTITY RFC5296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
11 <!ENTITY I-D.ietf-hokey-key-mgm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hokey-key-mgm-06.xml">
12 <!ENTITY I-D.ietf-dime-app-design-guide SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-app-design-guide-08.xml">
13 <!ENTITY I-D.gaonkar-radext-erp-attrs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gaonkar-radext-erp-attrs-03.xml">
14 <!ENTITY I-D.ietf-dime-erp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-erp-00.xml">
15 <!ENTITY I-D.wu-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wu-dime-local-keytran-00.xml">
16 <!ENTITY nbsp "&#160;">
17 ]>
18 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
19 <?rfc strict="yes"?>
20 <?rfc comments="no"?>
21 <?rfc inline="yes"?>
22 <?rfc editing="no"?>
23 <?rfc toc="yes"?>
24 <?rfc tocompact="yes"?>
25 <?rfc tocdepth="3"?>
26 <?rfc symrefs="yes"?>
27 <?rfc sortrefs="yes"?>
28 <?rfc compact="yes"?>
29 <?rfc subcompact="no"?>
30 <?rfc rfcedstyle="yes"?>
31 <?rfc rfcprocack="no"?>
32 <?rfc tocindent="yes"?>
33 <rfc category="std" docName="draft-ietf-dime-erp-02.txt" ipr="trust200902">
34 <front>
35 <title abbrev="Diameter support for ERP">Diameter support for EAP
36 Re-authentication Protocol (ERP)</title>
37
38 <author fullname="Lakshminath Dondeti" initials="L" surname="Dondeti">
39 <organization>QUALCOMM, Inc.</organization>
40
41 <address>
42 <postal>
43 <street>5775 Morehouse Dr</street>
44
45 <city>San Diego</city>
46
47 <region>CA</region>
48
49 <country>USA</country>
50 </postal>
51
52 <phone>+1 858-845-1267</phone>
53
54 <email>ldondeti@qualcomm.com</email>
55 </address>
56 </author>
57
58 <author fullname="Julien Bournelle" initials="J." surname="Bournelle">
59 <organization abbrev="Orange Labs">Orange Labs</organization>
60
61 <address>
62 <postal>
63 <street>38-40 rue du general Leclerc</street>
64
65 <city>Issy-Les-Moulineaux</city>
66
67 <code>92794</code>
68
69 <country>France</country>
70 </postal>
71
72 <email>julien.bournelle@orange-ftgroup.com</email>
73 </address>
74 </author>
75
76 <author fullname="Lionel Morand" initials="L." surname="Morand">
77 <organization abbrev="Orange Labs">Orange Labs</organization>
78
79 <address>
80 <postal>
81 <street>38-40 rue du general Leclerc</street>
82
83 <city>Issy-Les-Moulineaux</city>
84
85 <code>92794</code>
86
87 <country>France</country>
88 </postal>
89
90 <email>lionel.morand@orange-ftgroup.com</email>
91 </address>
92 </author>
93
94 <author fullname="Sebastien Decugis" initials="S." role="editor"
95 surname="Decugis">
96 <organization abbrev="NICT">NICT</organization>
97
98 <address>
99 <postal>
100 <street>4-2-1 Nukui-Kitamachi</street>
101
102 <city>Tokyo</city>
103
104 <code>184-8795</code>
105
106 <country>Koganei, Japan</country>
107 </postal>
108
109 <email>sdecugis@nict.go.jp</email>
110 </address>
111 </author>
112
113 <author fullname="Qin Wu" initials="Q." surname="Wu">
114 <organization abbrev="Huawei">Huawei Technologies Co.,
115 Ltd</organization>
116
117 <address>
118 <postal>
119 <street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia
120 Rd.</street>
121
122 <city>Nanjing</city>
123
124 <code>210001</code>
125
126 <country>China</country>
127 </postal>
128
129 <email>sunseawq@huawei.com</email>
130 </address>
131 </author>
132
133 <date year="2009" />
134
135 <area>Operations &amp; Management</area>
136
137 <workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>
138
139 <keyword>Internet-Draft</keyword>
140
141 <keyword>EAP</keyword>
142
143 <keyword>Diameter</keyword>
144
145 <keyword>Re-authentication</keyword>
146
147 <keyword>inter-authenticator roaming</keyword>
148
149 <abstract>
150 <t>EAP Re-authentication Protocol (ERP) defines extensions to the
151 Extensible Authentication Protocol (EAP) to support efficient
152 re-authentication between the EAP peer and an EAP re-authentication
153 server through an EAP/ERP authenticator. This document specifies
154 Diameter support for ERP. It defines a new Diameter ERP application to
155 transport ERP messages between authenticator and ERP server, and a set
156 of new AVPs that can be used to transport the cryptographic material
157 needed by ERP server.</t>
158 </abstract>
159 </front>
160
161 <middle>
162 <section anchor="Introduction" title="Introduction">
163 <t><xref target="RFC5296"></xref> defines the EAP Re-authentication
164 Protocol (ERP). It consists in the following steps:<list style="numbers">
165 <t>Bootstrapping: a root key for re-authentication is derived from
166 the Extended Master Session Key (EMSK) created during EAP
167 authentication <xref target="RFC5295"></xref>. This root key is
168 transported from the EAP server to the ER server.</t>
169
170 <t>Re-authentication: a one-round-trip exchange between the peer and
171 the ER server, resulting in mutual authentication. To accomplish the
172 EAP reauthentication functionality, ERP defines two new EAP codes -
173 EAP-Initiate and EAP-Finish.</t>
174 </list></t>
175
176 <t>This document defines how Diameter transports the ERP messages
177 (Re-authentication step). For this purpose, we define a new Application
178 Id for ERP, and re-use the Diameter EAP commands (DER/DEA).</t>
179
180 <t>This document also discusses the distribution of the root key
181 (bootstrapping step), either during the initial EAP authentication
182 (implicit bootstrapping) or during the first ERP exchange (explicit
183 bootstrapping). Security considerations for this key distribution are
184 detailed in <xref target="RFC5295"></xref>.</t>
185 </section>
186
187 <section title="Terminology">
188 <t>This document uses terminology defined in <xref
189 target="RFC3748"></xref>, <xref target="RFC5295"></xref>, <xref
190 target="RFC5296"></xref>, and <xref target="RFC4072"></xref>.</t>
191
192 <t>"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK
193 derived from an EMSK, depending on the location of the ER server in home
194 or foreign domain.</t>
195
196 <t>We note in this document ERP/DER a Diameter-EAP-Request command with
197 the Application Id set to Diameter ERP application. On the same model,
198 we use ERP/DEA, EAP/DER and EAP/DEA.</t>
199
200 <section title="Requirements Language">
201 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
203 document are to be interpreted as described in <xref
204 target="RFC2119"></xref>.</t>
205 </section>
206 </section>
207
208 <section title="Assumptions">
209 <t>This document makes the following assumptions.</t>
210
211 <t>The Home EAP server of a peer that wants to use ERP is extended to
212 support:<list>
213 <t>Cryptographic operations needed to derive the ERP root key from
214 the EMSK. By deriving the ERP root key for a specific domain, the
215 home EAP server implicitly authorizes the use of ERP within this
216 domain.</t>
217
218 <t>Diameter operations to include this root key inside an
219 appropriate AVP as defined in this document, in an answer message
220 corresponding to a request that contained a request for this
221 material (AVP for the request also defined in this document).</t>
222
223 <t>(recommanded) Ability to answer a DER message with EAP-Payload
224 containing an explicit bootstrapping ERP message.</t>
225 </list></t>
226
227 <t>The Authenticator (NAS) is extended to support:<list>
228 <t>Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in
229 its EAP pass-through mode.</t>
230
231 <t>(optional) Send the EAP-Initiate/Re-Auth-Start message</t>
232
233 <t>(optional) Provide the local domain name via lower layer specific
234 mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message.</t>
235
236 <t>Encapsulate ERP message and receive corresponding Diameter
237 answer, as described in this document.</t>
238 </list></t>
239
240 <t>If one of the components does not match these assumptions, the ERP
241 mechanism will fail. In such situation, a full EAP authentication may be
242 attempted as a fallback mechanism.</t>
243
244 <t>We consider at most one logical ER server entity in a domain. If
245 several physical servers are deployed for robustness, a replication
246 mechanism must be deployed to synchronize the ERP states (root keys
247 <cref>FFS: authorization attributes</cref> ) between these servers. This
248 replication mechanism is out of the scope of this document. If several
249 ER servers are deployed in the domain, we assume that they can be used
250 interchangeably.</t>
251 </section>
252
253 <section anchor="Overview" title="Protocol Overview">
254 <t>The following figure shows the components involved in ERP, and their
255 interactions.</t>
256
257 <figure title="Figure. Diameter ERP overview.">
258 <artwork><![CDATA[
259 Diameter +--------+
260 +-------------+ ERP +-----------+ (*) | Home |
261 Peer <->|Authenticator|<=======>| ER server | <---> | EAP |
262 +-------------+ +-----------+ | server |
263 +--------+
264 (*) Diameter EAP application,
265 explicit bootstraping scenario only.]]></artwork>
266 </figure>
267
268 <t>The ER server is located either in the home domain (same as EAP
269 server) or in the visited domain (same as authenticator, when it differs
270 from the home domain). <cref>Can the ER server be located in a third
271 domain (ex: broker's) according to ERP mechanism?</cref></t>
272
273 <t>When the peer initiates an ERP exchange, the authenticator creates a
274 Diameter-EAP-Request message, as described in Diameter EAP application
275 <xref target="RFC4072"></xref>. The Application Id of the message is set
276 to Diameter ERP application (code: TBD <cref>TBD IANA</cref>) in the
277 message. The exact processing to generate the ERP/DER message is
278 detailed in section <xref target="Re-authentication"></xref>.</t>
279
280 <t>If there is an ER server in the same domain as the authenticator
281 (local domain), Diameter routing MUST <cref>SHOULD ? FFS...</cref> be
282 configured so that this ERP/DER message reachs this server, even if the
283 Destination-Realm is not the local domain.</t>
284
285 <t>If there is no local ER server, the message is routed according to
286 its Destination-Realm AVP content, extracted from the realm component of
287 the keyName-NAI attribute. As specified in <xref
288 target="RFC5296"></xref>, this realm is the home domain of the peer in
289 case of bootstrapping exchange ('B' flag is set in ERP message) or the
290 domain of the bootstrapped ER server otherwise <cref>This actually might
291 allow the ER server to be in a third party realm</cref>.</t>
292
293 <t>If no ER server is available in the home domain either, the ERP/DER
294 message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER is
295 generated as specified in <xref target="RFC3588"></xref> and returned to
296 the authenticator. The authenticator may cache this information (with
297 limited duration) to avoid further attempts for ERP with this realm. It
298 may also fallback to full EAP authentication to authenticate the
299 peer.</t>
300
301 <t>When an ER server receives the ERP/DER message, it searches its local
302 database for a root key <cref>and authorization state ?</cref> matching
303 the keyName part of the User-Name AVP. If such key is found, the ER
304 server processes the ERP message as described in <xref
305 target="RFC5296"></xref> then creates the ERP/DEA answer as described in
306 <xref target="Re-authentication"></xref>. The rMSK is included in this
307 answer.</t>
308
309 <t>Finally, the authenticator extracts the rMSK from the ERP/DEA as
310 described in <xref target="RFC5296"></xref>, and forwards the content of
311 the EAP-Payload AVP, the EAP-Finish/Re-Auth message, to the peer.</t>
312
313 <t>If the EAP-Initiate/Re-Auth message has its 'B' flag set
314 (Bootstrapping exchange), the ER server should not possess the root key
315 in its local database <cref>This may not be true in future RFC5296bis
316 ?</cref>. In this case, the ER server acts as a proxy, and forwards the
317 message to the home EAP server after changing its Application Id to
318 Diameter EAP and adding an AVP to request the root key. See section
319 <xref target="Bootstrapping"></xref> for more detail on this
320 process.</t>
321 </section>
322
323 <section anchor="Bootstrapping" title="Bootstrapping the ER server">
324 <t>The bootstrapping process involves the home EAP server and the ER
325 server, but also impacts the peer and the authenticator. In ERP, the
326 peer must derive the same keying material as the ER server. To achieve
327 this, it must learn the domain name of the ER server. How this
328 information is acquired is outside the scope of this specification, but
329 it may involves that the authenticator is configured to advertize this
330 domain name, especially in the case of re-authentication after a
331 handover.</t>
332
333 <t>The bootstrapping of an ER server with a given root key happens
334 either during the initial EAP authentication of the peer when the EMSK
335 -- from which the root key is derived -- is created, during the first
336 re-authentication, or sometime between those events. We only consider
337 the first two possibilities in this specification, in the following
338 subsections.</t>
339
340 <section title="Bootstrapping during initial EAP authentication">
341 <t>Bootstrapping the ER server during the initial EAP authentication
342 (also known as implicit bootstrapping) offers the advantage that the
343 server is immediatly available for re-authentication of the peer, thus
344 minimizing the re-authentication delay. On the other hand, it is
345 possible that only a small number of peers will use re-authentication
346 in the visited domain. Deriving and caching key material for all the
347 peers (for example, for the peers that do not support ERP) is a waste
348 of resources and SHOULD be avoided.</t>
349
350 <t>To achieve implicit bootstrapping, the ER server must act as a
351 Diameter EAP Proxy as defined in Diameter Base Protocol <xref
352 target="RFC3588"></xref>, and routing must be configured so that
353 Diameter messages of a full EAP authentication are routed through this
354 proxy. The figure bellow captures this mechanism.</t>
355
356 <figure title="Figure. ERP bootstrapping during full EAP authentication">
357 <artwork><![CDATA[
358 ER server &
359 Authenticator EAP Proxy Home EAP server
360 ============= =========== ===============
361 ------------------------->
362 Diameter EAP/DER
363 (EAP-Response)
364 ------------------------->
365 Diameter EAP/DER
366 (EAP-Response)
367 (ERP-RK-Request)
368
369 <==================================================>
370 Multi-round Diameter EAP exchanges, unmodified
371
372 <-------------------------
373 Diameter EAP/DEA
374 (EAP-Success)
375 (MSK)
376 (ERP-RK-Answer)
377 <-------------------------
378 Diameter EAP/DEA
379 (EAP-Success)
380 (MSK)
381 [ERP-Realm]
382 ]]></artwork>
383 </figure>
384
385 <t>The ER server proxies the first DER of the full EAP authentication
386 and adds the ERP-RK-Request AVP inside, if this AVP is not already in
387 the message (which might happen if there are ER servers in the visited
388 and the home domains), then forwards the request.</t>
389
390 <t>If the EAP server does not support ERP extensions, it will simply
391 ignore this grouped AVP and continue as specified in <xref
392 target="RFC4072"></xref>. If the server supports the ERP extensions,
393 it caches the ERP-Realm value with the session, and continues the EAP
394 authentication. When the authentication is complete, if it is
395 successful and the EAP method generated an EMSK, the server MUST
396 compute the rRK or rDSRK (depending on the value of ERP-Realm) as
397 specified in <xref target="RFC5296"></xref>, and add an ERP-RK-Answer
398 AVP in the Diameter-EAP-Request message, in addition to the MSK and
399 EAP-Success payloads.</t>
400
401 <t>When the ER server proxies a Diameter-EAP-Answer message with a
402 Session-Id corresponding to a message to which it added an
403 ERP-RK-Answer, and the Result-Code is DIAMETER_SUCCESS, it MUST
404 examine the message, extract and remove any ERP-RK-Answer AVP from the
405 message, and save its content. If the message does not contain an
406 ERP-RK-Answer AVP, the ER server MAY save this information to avoid
407 possible subsequent re-authentication attempts for this session. In
408 any case, the information stored SHOULD NOT have a lifetime greater
409 than the EMSK lifetime <cref>how does the ER server knows the EMSK
410 lifetime, if there is no ERP-RK-Answer? What is the lifetime of the
411 MSK for example?</cref></t>
412
413 <t>If the ER server is successfully bootstrapped, it MAY also add the
414 ERP-Realm AVP after removing the ERP-RK-Answer AVP in the EAP/DEA
415 message. This could be used by the authenticator to notify the peer
416 that ERP is bootstrapped, with the ER domain information. How this
417 information can be transmitted to the peer is outside the scope of
418 this document. <cref>Is it possible? It would be useful...</cref></t>
419 </section>
420
421 <section title="Bootstrapping during first re-authentication">
422 <t>Bootstrapping the ER server during the first re-authentication
423 (also known as explicit bootstrapping) offers several advantages: it
424 saves resources, since we generate and cache only root key that we
425 actually need, and it can accomodate inter-domain handovers or ER
426 servers that loose their state (for example after reboot) <cref>This
427 last point might not be true currently, since the peer would not issue
428 a bootstrapping exchange... But this might change also with RFC5296bis
429 AFAIU</cref>. On the other hand, the first re-authentication with the
430 ER server requires a one-round-trip exchange with the home EAP server,
431 which adds some delay to the process (but it is more efficient than a
432 full EAP authentication in any case). It also requires some
433 synchronization between the peer and the visited domain: since the ERP
434 message is different<cref>and the root key used also ?</cref> for
435 explicit bootstrapping exchange and for normal re-authentication,
436 explicit bootstrapping should not be used if implicit bootstrapping
437 was already performed.</t>
438
439 <t><cref>What should we do if the ER server receives an explicit
440 bootstrapping request but already possess the rDSRK? Can it answer
441 without going to the home server? That would be simpler -- planned in
442 rfc5296bis ?</cref></t>
443
444 <t>The ER server receives the ERP/DER message containing the
445 EAP-Initiate/Re-Auth message with the 'B' flag set. It proxies this
446 message, and do the following processing in addition to standard proxy
447 operations:<list>
448 <t>Change the Application Id in the header of the message to
449 Diameter EAP Application (code 5).</t>
450
451 <t>Change the content of Application-Auth-Id accordingly. <cref>Is
452 it better to leave it unmodified?</cref></t>
453
454 <t>Add the ERP-RK-Request AVP, which contains the name of the
455 domain where the ER server is located.</t>
456
457 <t><cref>Add the Destination-Host to reach the appropriate EAP
458 server, the one with the EMSK. How does the ER server know this
459 information ?</cref></t>
460 </list>Then the server forwards the EAP/DER request, which is routed
461 to the home EAP server.</t>
462
463 <t>If the home EAP server does not support ERP extensions, it replies
464 with an error since the encapsulated EAP-Initiate/Re-auth command is
465 not understood. Otherwise, it processes the ERP request as described
466 in <xref target="RFC5296"></xref>. In particular, it includes the
467 Domain-Name TLV attribute with the content from the ERP-Realm AVP. It
468 creates the EAP/DEA reply message following standard processing from
469 <xref target="RFC4072"></xref> (in particular EAP-Master-Session-Key
470 AVP is used to transport the rMSK), and includes the ERP-RK-Answer
471 AVP. <cref>What about authorization AVPs ?</cref></t>
472
473 <t>The ER server receives this EAP/DEA and proxies it as follow, in
474 addition to standard proxy operations:<list>
475 <t>Set the Application Id back to Diameter ERP (code TBD<cref>TBD
476 IANA</cref>)</t>
477
478 <t>Extract and cache the content of the ERP-RK-Answer. <cref>And
479 authorization AVPs ?</cref></t>
480 </list>The DEA is then forwarded to the authenticator, that can use
481 the rMSK as described in <xref target="RFC5296"></xref>.</t>
482
483 <t>The figure below captures this proxy behavior:</t>
484
485 <figure title="Figure. ERP explicit bootstrapping message flow">
486 <artwork><![CDATA[
487 Authenticator ER server Home EAP server
488 ============= ========= ===============
489 ----------------------->
490 Diameter ERP/DER
491 (EAP-Initiate)
492 ------------------------>
493 Diameter EAP/DER
494 (EAP-Initiate)
495 (ERP-RK-Request)
496
497 <------------------------
498 Diameter EAP/DEA
499 (EAP-Finish)
500 (ERP-RK-Answer)
501 (rMSK)
502 <----------------------
503 Diameter ERP/DEA
504 (EAP-Finish)
505 (rMSK)
506 ]]></artwork>
507 </figure>
508 </section>
509 </section>
510
511 <section anchor="Re-authentication" title="Re-Authentication">
512 <t>This section describes in detail a re-authentication exchange with a
513 (bootstrapped) ER server. The following figure summarizes the
514 re-authentication exchange.</t>
515
516 <figure title="Figure. Diameter ERP exchange. ">
517 <artwork><![CDATA[
518 ER server
519 (bootstrapped)
520 Peer Authenticator (local or home domain)
521 ==== ============= ======================
522 [ <------------------------ ]
523 [optional EAP-Initiate/Re-auth-start]
524
525 ----------------------->
526 EAP-Initiate/Re-auth
527 ==================================>
528 Diameter ERP, cmd code DER
529 User-Name: Keyname-NAI
530 EAP-Payload: EAP-Initiate/Re-auth
531
532 <==================================
533 Diameter ERP, cmd code DEA
534 EAP-Payload: EAP-Finish/Re-auth
535 EAP-Master-Session-Key: rMSK
536 <----------------------
537 EAP-Finish/Re-auth
538 ]]></artwork>
539 </figure>
540
541 <t>In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER
542 server via the authenticator. Alternatively, the NAS may send an
543 EAP-Initiate/Re-auth-Start message to the peer to trigger the start of
544 ERP. In this case, the peer responds with an EAP-Initiate/Re-auth
545 message to the NAS.</t>
546
547 <t>If the authenticator does not support ERP (pure <xref
548 target="RFC4072"></xref> support), it discards the EAP packets with
549 unknown ERP-specific code (EAP-Initiate). The peer may fallback to full
550 EAP authentication in such case.</t>
551
552 <t>When the authenticator receives an EAP-Initiate/Re-auth message from
553 the peer, it process as described in <xref target="RFC5296"></xref> with
554 regards to the EAP state machine. It creates a Diameter EAP Request
555 message following the general process of <xref target="RFC4072">Diameter
556 EAP</xref>, with the following differences:<list>
557 <t>The Application Id in the header is set to Diameter ERP (code TBD
558 <cref>TBD IANA</cref>).</t>
559
560 <t>The value in Auth-Application-Id AVP is also set to Diameter ERP
561 Application.</t>
562
563 <t>The keyName-NAI attribute from ERP message is used to create the
564 content of User-Name AVP and Destination-Realm AVP.</t>
565
566 <t><cref>FFS: What about Session-ID AVP -- in case of re-auth at the
567 same place, and in case of handover?</cref></t>
568
569 <t>The Auth-Request-Type AVP content is set to [Editor's note:
570 FFS]<cref>Do we really do authorization with Diameter ERP ? -- need
571 to pass the authorization attrs to the ER server in that case. Idea
572 FFS: we do authorization only for explicit bootstrapping
573 exchanges...</cref>.</t>
574
575 <t>The EAP-Payload AVP contains the ERP message,
576 EAP-Initiate/Re-Auth.</t>
577 </list>Then this ERP/DER message is sent as described in <xref
578 target="Overview"></xref>.</t>
579
580 <t>The ER server receives and processes this request as described in
581 <xref target="Overview"></xref>. It then creates a Diameter answer
582 ERP/DEA, following the general processing described in <xref
583 target="RFC4072"></xref>, with the following differences:<list>
584 <t>The Application Id in the header is set to Diameter ERP (code
585 TBD<cref>TBD IANA</cref>).</t>
586
587 <t>The value in Auth-Application-Id AVP is also set to Diameter ERP
588 Application.</t>
589
590 <t>The Result-Code AVP is set to <cref>version -00 stated a SHOULD
591 here, not sure why ?</cref> an error value in case ERP
592 authentication fails, or to DIAMETER_SUCCESS if ERP is
593 successful.</t>
594
595 <t>The EAP-Payload AVP contains the ERP message,
596 EAP-Finish/Re-auth.</t>
597
598 <t>In case of successful authentication, the EAP-Master-Session-Key
599 AVP contains the Re-authentication Master Session Key (rMSK) derived
600 by ERP.</t>
601
602 <t><cref>What about all the authorization attributes? If we want to
603 include them, they have to be present on the ER server...</cref></t>
604 </list></t>
605
606 <t>When the authenticator receives this ERP/DEA answer, it processes it
607 as described in <xref target="RFC4072">Diameter EAP</xref> and <xref
608 target="RFC5296"></xref>: the content of EAP-Payload AVP content is
609 forwarded to the peer, and the content of EAP-Master-Session-Key AVP is
610 used as a shared secret for Secure Association Protocol.</t>
611 </section>
612
613 <section anchor="ApplicationId" title="Application Id">
614 <t>We define a new Diameter application in this document, Diameter ERP
615 Application, with an Application Id value of TBD<cref>TBD IANA</cref>.
616 Diameter nodes conforming to this specification in the role of ER server
617 MUST advertise support by including an Auth-Application-Id AVP with a
618 value of Diameter ERP Application in the of the
619 Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands,
620 as described in <xref target="RFC3588"></xref>.</t>
621
622 <t>The primary use of the Diameter ERP Application Id is to ensure
623 proper routing of the messages, and that the nodes that advertise the
624 support for this application do understand the new AVPs defined in
625 section <xref target="AVPs"></xref> , although these AVP have the 'M'
626 flag cleared.</t>
627 </section>
628
629 <section anchor="AVPs" title="AVPs">
630 <t>This specification defines the following new AVPs. <cref>FFS: to
631 align with draft-wu-dime-local-keytran-02 if it becomes a WG
632 item</cref></t>
633
634 <section title="ERP-RK-Request AVP">
635 <t>The ERP-RK-Request AVP (AVP Code TBD<cref>TBD IANA</cref>) is of
636 type grouped AVP. This AVP is used by the ER server to indicate its
637 willingness to act as ER server for a particular session.</t>
638
639 <t>This AVP has the M and V bits cleared.</t>
640
641 <figure title="Figure. ERP-RK-Request ABNF">
642 <artwork><![CDATA[
643 ERP-RK-Request ::= < AVP Header: TBD >
644 { ERP-Realm }
645 * [ AVP ]
646 ]]></artwork>
647 </figure>
648 </section>
649
650 <section title="ERP-Realm AVP">
651 <t>The ERP-Realm AVP (AVP Code TBD<cref>TBD IANA</cref>) is of type
652 DiameterIdentity. It contains the name of the realm in which the ER
653 server is located.</t>
654
655 <t><cref>FFS: We may re-use Origin-Realm here instead? On the other
656 hand, ERP-Realm may be useful if the ER server is not in a third-party
657 realm, if this is possible.</cref></t>
658
659 <t>This AVP has the M and V bits cleared.</t>
660 </section>
661
662 <section title="ERP-RK-Answer AVP">
663 <t>The ERP-RK-Answer AVP (AVP Code TBD<cref>TBD IANA</cref>) is of
664 type grouped AVP. It is used by the home EAP server to provide ERP
665 root key material to the ER server.</t>
666
667 <t>This AVP has the M and V bits cleared.</t>
668
669 <figure title="Figure. ERP-RK-Answer ABNF">
670 <artwork><![CDATA[
671 ERP-RK-Answer ::= < AVP Header: TBD >
672 { ERP-RK }
673 { ERP-RK-Name }
674 { ERP-RK-Lifetime }
675 * [ AVP ]
676 ]]></artwork>
677 </figure>
678 </section>
679
680 <section title="ERP-RK AVP">
681 <t>The ERP-RK AVP (AVP Code TBD<cref>TBD IANA</cref>) is of type
682 OctetString. It contains the root key (either rRK or rDSRK) sent by
683 the home EAP server to the ER server, in answer to request containing
684 an ERP-RK-Request AVP. How this material is derived and used is
685 specified in <xref target="RFC5296"></xref>.</t>
686
687 <t><cref>Can we re-use EAP-Master-Session-Key here instead? Must check
688 the exact definition...</cref></t>
689
690 <t>This AVP has the M and V bits cleared.</t>
691 </section>
692
693 <section title="ERP-RK-Name AVP">
694 <t>The ERP-RK-Name AVP (AVP Code TBD<cref>TBD IANA</cref>) is of type
695 OctetString. This AVP contains the EMSKname which identifies the
696 keying material. How this name is derived is beyond the scope of this
697 document and defined in <xref target="RFC5296"></xref>.</t>
698
699 <t><cref>Can we re-use EAP-Key-Name here instead ?</cref></t>
700
701 <t>This AVP has the M and V bits cleared.</t>
702 </section>
703
704 <section title="ERP-RK-Lifetime AVP">
705 <t>The ERP-RK-Lifetime AVP (AVP Code TBD<cref>TBD IANA</cref>) is of
706 type Unsigned32 <cref>do we really need 64 as in -00 ? 2^32 secs is
707 already more than 100 years, which is too long for a key lifetime
708 !</cref> and contains the root key material remaining lifetime in
709 seconds. It MUST not be greater than the remaining lifetime of the
710 EMSK it is derived from. <cref>FFS: is it better to pass an absolute
711 value here, for example expiration date? How to express it then (TZ,
712 ...)? Synchronization problems?</cref></t>
713
714 <t>This AVP has the M and V bits cleared.</t>
715 </section>
716 </section>
717
718 <section anchor="Commands" title="Commands">
719 <t>We do not define any new command in this specification. We reuse the
720 Diameter-EAP-Request and Diameter-EAP-Answer commands defined in <xref
721 target="RFC4072"></xref>.</t>
722
723 <t>Since the original ABNF of these commands allow other optional AVPs
724 ("* [ AVP ]"), and the new AVPs defined in this specification do not
725 have the 'M' flag set, the ABNF does not need any change. Anyway, a
726 Diameter node that advertizes support for the Diameter ERP application
727 MUST support the new AVPs defined in this specification.</t>
728
729 <figure title="Figure. Command Codes">
730 <artwork><![CDATA[
731 Command-Name Abbrev. Code Reference Application
732 ---------------------------------------------------------
733 Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP
734 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP
735 ]]></artwork>
736 </figure>
737 </section>
738
739 <section anchor="Issues" title="Open issues">
740 <t>This document does not address some known issues in Diameter ERP
741 mechanism. The authors would like to hear ideas about how to address
742 them.</t>
743
744 <t>The main issue is the use of ERP for authentication after a handover
745 of the peer to a new authenticator (or different authenticator port).
746 Diameter ERP is not meant to be a mobility protocol. A number of issues
747 appear when we try to do handover in Diameter ERP (alone): how to manage
748 the Session-Id AVP; how does the ER server provide the Authorization
749 AVPs; how does the peer learn the ERP domain of the new authenticator;
750 how does the home server reachs the peer to for example terminate the
751 session; and so on... Therefore, the management of the session for a
752 mobile peer is not (yet) addressed in this document. It must be studied
753 how Diameter ERP can be for example used in conjunction with a mobility
754 application (Diameter MIP4, Diameter MIP6) to support the optimized
755 re-authentication in such situation.</t>
756
757 <t>Another issue concerns the case where the home realm contains several
758 EAP servers. In multi rounds full EAP authentication, the
759 Destination-Host AVP provides the solution to reach the same server
760 across the exchanges. Only this server possess the EMSK for the session.
761 In case of explicit bootstrapping, the ER server must therefore be able
762 to reach the correct server to request the DSRK. A solution might
763 consist in saving the Origin-Host AVP of all successful EAP/DEA in the
764 ER server, which is a bit similar to the implicit bootstrapping scenario
765 described here -- only we save the server name instead of the root key,
766 and we must then be able to match the DSRK with the user name.</t>
767
768 <t>Finally, this document currently lacks a description of what happens
769 when a Re-Auth-Request is received for a peer on the authenticator.</t>
770 </section>
771
772 <section anchor="Acknowledgements" title="Acknowledgements">
773 <t>Hannes Tschofenig wrote the initial draft for this document and
774 provided useful reviews.</t>
775
776 <t>Vidya Narayanan reviewed a rough draft version of the document and
777 found some errors.</t>
778
779 <t>Glen Zorn actively participated in the discussions on the design for
780 Diameter ERP, providing the point of view and experience from HOKEY
781 workgroup.</t>
782
783 <t>Many thanks to these people!</t>
784 </section>
785
786 <section anchor="IANA" title="IANA Considerations">
787 <t>This document requires IANA registration of the following new
788 elements in the <eref
789 target="http://www.iana.org/assignments/aaa-parameters/">Authentication,
790 Authorization, and Accounting (AAA) Parameters</eref> registries.</t>
791
792 <section title="Diameter ERP application">
793 <t>This specification requires IANA to allocate a new value "Diameter
794 ERP" in the "Application IDs" registry created by in <xref
795 target="RFC3588"></xref>.</t>
796
797 <figure title="IANA consideration for Diameter ERP application">
798 <artwork><![CDATA[
799 Application Identifier | Value
800 -----------------------------------+------
801 Diameter ERP | TBD
802 ]]></artwork>
803 </figure>
804 </section>
805
806 <section title="New AVPs">
807 <t>This specification requires IANA to allocate new values from the
808 "AVP Codes" registry defined in <xref target="RFC3588"></xref> for the
809 following AVPs:<list>
810 <t>ERP-RK-Request</t>
811
812 <t>ERP-Realm</t>
813
814 <t>ERP-RK-Answer</t>
815
816 <t>ERP-RK</t>
817
818 <t>ERP-RK-Name</t>
819
820 <t>ERP-RK-Lifetime</t>
821 </list>These AVPs are defined in section <xref
822 target="AVPs"></xref>.</t>
823 </section>
824 </section>
825
826 <section anchor="Security" title="Security Considerations">
827 <t>The security considerations from the following RFC apply here: <xref
828 target="RFC3588"></xref>, <xref target="RFC4072"></xref>, <xref
829 target="RFC5247"></xref>, <xref target="RFC5295"></xref>, and <xref
830 target="RFC5296"></xref>.</t>
831
832 <t><cref>FFS: Do we really respect these security considerations with
833 the mechanism we describe here? Is it safe to use ERP-RK-Request /
834 Answer AVPs? What is the worst case?</cref></t>
835
836 <t>EAP channel bindings may be necessary to ensure that the Diameter
837 client and the server are in sync regarding the key Requesting Entity's
838 Identity. Specifically, the Requesting Entity advertises its identity
839 through the EAP lower layer, and the user or the EAP peer communicates
840 that identity to the EAP server (and the EAP server communicates that
841 identity to the Diameter server) via the EAP method for user/peer to
842 server verification of the Requesting Entity's Identity.<cref>Editor: I
843 really don't understand this paragraph ^^'...</cref></t>
844 </section>
845 </middle>
846
847 <back>
848 <references title="Normative References">
849 &RFC2119;
850
851 &RFC3588;
852
853 &RFC4072;
854
855 &RFC5295;
856
857 &RFC5296;
858
859 &RFC3748;
860 </references>
861
862 <references title="Informative References">
863 &RFC4187;
864
865 &RFC5247;
866
867 &I-D.ietf-hokey-key-mgm;
868
869 &I-D.ietf-dime-erp;
870
871 &I-D.wu-dime-local-keytran;
872
873 &I-D.ietf-dime-app-design-guide;
874 </references>
875 </back>
876 </rfc>
"Welcome to our mercurial repository"