Mercurial > hg > ietf

comparison draft-ietf-dime-erp-03.xml @ 46:409fb7bb22b7

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