Mercurial > hg > ietf

comparison draft-ietf-dime-erp-01.xml @ 34:e34f7869b4a1

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