Mercurial > hg > ietf

comparison New_ERP_draft_src.txt @ 9:5fdd3345477f

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Cleanups.
author Sebastien Decugis <sdecugis@nict.go.jp>
date Wed, 18 Mar 2009 14:06:05 +0900
parents 45a13fe6e0be
children c8dd0bdbd9e6
comparison
equal deleted inserted replaced
8:45a13fe6e0be 9:5fdd3345477f
4 4
5 5
6 6
7 *Differences with [draft-ietf-dime-erp-00]* 7 *Differences with [draft-ietf-dime-erp-00]*
8 8
9 In this document, we specify a new Diameter application ID for Diameter messages transporting ERP exchanges. We re-use the mechanism described in [draft-ietf-dime-erp-00] as an option available to provide implicit bootstrapping to the ER server. 9 In this document, we specify a new Diameter application ID for Diameter messages transporting ERP exchanges between authenticator and ER server. We re-use the mechanism described in [draft-ietf-dime-erp-00] as an option available to provide implicit bootstrapping to the ER server.
10 10
11 11
12 12
13 *Introduction.* 13 *Introduction.*
14 14
15 During full EAP authentication, both the peer and the home EAP server derive EMSK material in addition to MSK. The EMSK can be used to derive a re-authentication root key (rRK or rDSRK) as described in [RFC5296]. This root key is transported to an ER server, this is called bootstrapping the ER server. When the peer re-authenticates using ERP, a one round-trip exchange occurs between the authenticator and the ER server, and new rMSK material is derived. The ER server may be located in the visited domain or home domain. 15 During full EAP authentication, both the peer and the home EAP server derive EMSK material in addition to MSK. The EMSK can be used to derive a re-authentication root key (rRK or rDSRK) as described in [RFC5296]. This root key is transported to an ER server, this is called bootstrapping the ER server. When the peer re-authenticates using ERP, a one round-trip exchange occurs between the authenticator and the ER server, where new rMSK material is derived. The ER server may be located in the visited domain or home domain.
16 16
17 There are two types of exchanges between AAA entities in the Re-authentication mechanism: transport of the re-authentication root key between the home EAP server and the ER server to bootstrap the mechanism, and transport of ERP messages and rMSK material between authenticator and ER server. This document specifies how the re-authentication exchange is transported using Diameter. It also contains information on how bootstrapping can be achieved in several situations. 17 There are two types of exchanges between AAA entities in the Re-authentication mechanism: transport of the re-authentication root key between the home EAP server and the ER server to bootstrap the mechanism, and transport of ERP messages and rMSK material between ER server and authenticator. This document specifies how the re-authentication exchange is transported using Diameter. It also provides information on how bootstrapping can be achieved in several situations.
18 18
19 Diameter +--------+ 19 Diameter +--------+
20 +-------------+ ERP +-----------+ (*) | Home | 20 +-------------+ ERP +-----------+ (*) | Home |
21 Peer <->|Authenticator|<=======>| ER server | <---> | EAP | 21 Peer <->|Authenticator|<=======>| ER server | <---> | EAP |
22 +-------------+ +-----------+ | server | 22 +-------------+ +-----------+ | server |
23 +--------+ 23 +--------+
24 (*) Several protocols can be used between ER server and home EAP server to transport bootstrapping material. Diameter EAP is one of them. 24 (*) Several protocols can be used between ER server and home EAP server to transport bootstrapping material. Diameter EAP is one of the possibilities.
25 25
26 Figure 1. Diameter applications used in the ERP mechanism. 26 Figure 1. Diameter applications used in the ERP mechanism.
27 27
28 28
29 29
30 *Assumptions.* 30 *Assumptions.*
31 31
32 For the peer to start an ERP exchange when attaching to a new authenticator, the following assumptions must be verified. Note that the peer can always fall back to full EAP authentication if one of these conditions is not met. 32 For the peer to start an ERP exchange when attaching to a new authenticator, the following assumptions must be verified. Note that the peer can always fall back to full EAP authentication if one of these conditions is not met. These assumptions are implicit from [RFC5296].
33 33
34 The peer must have non-expired keying material (EMSK) derived from a previous full EAP authentication. 34 The peer must have non-expired keying material (EMSK) derived from a previous full EAP authentication.
35 35
36 The peer must learn the realm of the new authenticator before starting the exchange, for example using L2-dependent mechanism. If this condition is not met, the peer cannot assume that an ER server is available and bootstrapped in the domain of this authenticator. It should start an ERP bootstrapping exchange as described in [RFC5296]. In addition, if the peer is attaching to this realm for the first time since the EMSK was derived (inter-domain handover), an ERP bootstrapping exchange must be initiated. 36 The peer must learn the realm of the new authenticator before starting the exchange, for example using L2-dependent mechanism. If this condition is not met, the peer cannot assume that an ER server is available and bootstrapped in the realm of this authenticator. It should start an ERP bootstrapping exchange as described in [RFC5296]. In addition, if the peer is attaching to this realm for the first time since the EMSK was derived (inter-domain handover), an ERP bootstrapping exchange must be initiated.
37 37
38 The authenticator must support ERP extensions. If this condition is not met, the ERP messages will be dropped by the authenticator conforming to [RFC4072] and ERP will fail. 38 The authenticator must support ERP extensions. If this condition is not met, the ERP messages will be dropped by the authenticator conforming to [RFC4072] and ERP will fail.
39 39
40 40
41 41
42 *Overview* 42 *Overview*
43 43
44 We define a new Diameter Application ID for ERP. When the authenticator receives an EAP-Initiate/Re-auth message, it encapsulates in a DER message following the rules described in [RFC4072]. The application id of the DER message is set to the new ERP application ID. The User-Name and Destination-Realm AVPs are extracted from the keyName-NAI included in the ERP message, as described in [RFC5296]. In the case were ERP is already bootstrapped in this domain, and the peer knows it, the Destination-Realm of the message is the local domain. In the other case, the peer is initiating a bootstrapping ERP exchange, and the Destination-Realm is the home domain. 44 We define a new Diameter Application ID for ERP. When the authenticator receives an EAP-Initiate/Re-auth message, it encapsulates it in a DER message following the rules described in [RFC4072]. The application id of the DER message is set to the Diameter ERP application ID. The User-Name and Destination-Realm AVPs are extracted from the keyName-NAI included in the ERP message, as described in [RFC5296]. In the case were ERP is already bootstrapped in this domain, and the peer knows it, the Destination-Realm of the message is the local domain. In other cases, the peer is initiating a bootstrapping ERP exchange, and the Destination-Realm is the home domain.
45 45
46 When ERP is already bootstrapped, the message is routed to the bootstrapped ER server. This server processes the ERP message as described in [RFC5296] then derives a new rMSK and answers a DEA encapsulating the EAP-Finish/Re-auth answer and the rMSK for the authenticator. Re-authentication is complete {see pending question in the end of this document}. This exchange is described in Figure 2 bellow. 46 When ERP is already bootstrapped, the message is routed to the bootstrapped ER server. This server processes the ERP message as described in [RFC5296] then derives a new rMSK and answers a DEA encapsulating the EAP-Finish/Re-auth answer and the rMSK for the authenticator. Re-authentication is complete {see pending question in the end of this document}. This exchange is described in Figure 2 bellow.
47 47
48 There are several options to bootstrap the local ER server. This document discusses some of the options, but a different mechanism not described here may be deployed as well. See the following sections for more details about bootstrapping scenarii. 48 There are several options to bootstrap the ER server. This document discusses some of the options, but a different mechanism not described here may be deployed as well. See the following sections for more details about bootstrapping scenarii.
49 49
50 50
51 Peer Authenticator ER server 51 Peer Authenticator ER server
52 ==== ============= (bootstrapped) 52 ==== ============= (bootstrapped)
53 [ <------------------------ ] (local or home domain) 53 [ <------------------------ ] (local or home domain)
54 [optional EAP-Initiate/Re-auth-start] ====================== 54 [optional EAP-Initiate/Re-auth-start] ======================
55 55
56 -----------------------> 56 ----------------------->
57 EAP-Initiate/Re-auth 57 EAP-Initiate/Re-auth
58 =====================================> 58 =====================================>
59 Diameter ERP, cmd code DER 59 Diameter ERP, cmd code DER
60 User-Name: Keyname-NAI 60 User-Name: Keyname-NAI
61 EAP-Payload: EAP-Initiate/Re-auth 61 EAP-Payload: EAP-Initiate/Re-auth
62 62
63 <===================================== 63 <=====================================
64 Diameter ERP, cmd code DEA 64 Diameter ERP, cmd code DEA
65 EAP-Payload: EAP-Finish/Re-auth 65 EAP-Payload: EAP-Finish/Re-auth
66 EAP-Master-Session-Key: rMSK 66 EAP-Master-Session-Key: rMSK
67 <---------------------- 67 <----------------------
68 EAP-Finish/Re-auth 68 EAP-Finish/Re-auth
69 69
70 Figure 2. Diameter ERP exchange. 70 Figure 2. Diameter ERP exchange.
71 71
72 72
73 73
74 *Bootstrapping* 74 *Bootstrapping*
75 75
85 If an ER server is located in the local domain, it should proxy the request and process as described bellow. Otherwise the request is sent to the ER server in the home domain. 85 If an ER server is located in the local domain, it should proxy the request and process as described bellow. Otherwise the request is sent to the ER server in the home domain.
86 86
87 When the ER server (in local or home domain) receives the ERP/DER request, it must process as follow: 87 When the ER server (in local or home domain) receives the ERP/DER request, it must process as follow:
88 - Check in the local key store if a key with same name is available. If such key is found, process the request locally and answer. 88 - Check in the local key store if a key with same name is available. If such key is found, process the request locally and answer.
89 - Check if the EAP-Initiate/Re-auth message has the [B] (bootstrapping) flag set. If this flag is not set, relay the message without altering it (except adding the Route-Record information) or reply with an error if no other Diameter node is available to handle the request, following the rules of Diameter Base Protocol. 89 - Check if the EAP-Initiate/Re-auth message has the [B] (bootstrapping) flag set. If this flag is not set, relay the message without altering it (except adding the Route-Record information) or reply with an error if no other Diameter node is available to handle the request, following the rules of Diameter Base Protocol.
90 - If the [B] flag was set, the message is proxied locally, and modified as follow: 90 - If the [B] flag was set, the message is proxied locally and modified as follow:
91 * Change the application-id of the message from Diameter ERP to Diameter EAP (so that the message will reach the Home EAP server). 91 * Change the application-id of the message from Diameter ERP to Diameter EAP (so that the message will reach the Home EAP server).
92 * Add the rDSRK-Request AVP if ER server is in visited domain, or rRK-Request AVP if ER server is in home domain.@These grouped AVP are described in this document. 92 * Add the ERP-RK-Request AVP, defined in this document.
93 * Send the new message. It will reach the Home EAP server. 93 * Send the new message. It will reach the Home EAP server.
94 94
95 If the home EAP server does not support ERP extensions, it replies with an error since EAP-Initiate/Re-auth command is not understood. Otherwise, it processes the EAP-Initiate/Re-auth message as described in [RFC5296] and derives the requested rDSRK or rRK, and new rMSK. It sends this material using the new AVPs described in this document. It also includes the realm of the ER server in the EAP-Finish/Re-auth message to inform the peer of the location of the ER server. 95 If the home EAP server does not support ERP extensions, it replies with an error since encapsulated EAP-Initiate/Re-auth command is not understood. Otherwise, it processes the EAP-Initiate/Re-auth message as described in [RFC5296] and derives the requested rDSRK or rRK, and new rMSK. It sends this material using the new ERP-RK-Answer AVP described in this document. It also includes the realm of the ER server in the EAP-Finish/Re-auth message to inform the peer of the location of the ER server.
96 96
97 The ER server receives this DEA, extracts and cache the rRK or rDSRK material, restores the application-id to Diameter ERP and forwards the message to the authenticator. 97 The ER server receives this DEA, extracts and cache the rRK or rDSRK material, restores the application-id to Diameter ERP and forwards the message to the authenticator.
98 98
99 This flow is captured bellow: 99 This flow is captured figure 3.
100 100
101 Authenticator ER server Home EAP server 101 Authenticator ER server Home EAP server
102 ============= ========= =============== 102 ============= ========= ===============
103 -----------------------> 103 ----------------------->
104 ERP, DER 104 ERP/DER
105 (EAP-Initiate) 105 (EAP-Initiate)
106 ------------------------> 106 ------------------------>
107 EAP, DER 107 EAP/DER
108 (EAP-Initiate) 108 (EAP-Initiate)
109 (rDSRK-Request or rRK-Request) 109 (ERP-RK-Request)
110 110
111 <------------------------ 111 <------------------------
112 EAP, DEA 112 EAP/DEA
113 (EAP-Finish) 113 (EAP-Finish)
114 (rDSRK or rRK) 114 (ERP-RK-Answer)
115 (rMSK) 115 (rMSK)
116 <---------------------- 116 <----------------------
117 ERP, DEA 117 ERP/DEA
118 (EAP-Finish) 118 (EAP-Finish)
119 (rMSK) 119 (rMSK)
120 120
121 Figure 3. ERP explicit bootstrapping message flow. 121 Figure 3. ERP explicit bootstrapping message flow.
122 122
123 123
124 124
125 *Scenario 2: implicit bootstrapping during full EAP authentication* 125 *Scenario 2: implicit bootstrapping during full EAP authentication*
126 126
127 In some deployment scenarii, the ER server may be collocated with the EAP proxy or server. In that case, the optional ERP AVPs defined in this document may be used during initial full EAP authentication to provide implicit bootstrapping (section 5.1 of [RFC5296]) as described bellow. 127 In some deployment scenarii, the ER server may be collocated with an EAP proxy or server. In that case, the optional ERP AVPs defined in this document may be used during initial full EAP authentication to provide implicit bootstrapping (section 5.1 of [RFC5296]) as described bellow.
128 128
129 In this situation, ERP key material is derived and cached regardless of the peer support and willingness for ERP, which may lead to scalability or other issues. Implementors may provide other ways to select which sessions should use implicit bootstrapping. 129 In this scenario, the ERP key material is derived and cached regardless of the peer support and willingness for ERP. This may lead to scalability and other issues. Implementors may provide other ways to select which sessions should use implicit bootstrapping.
130 130
131 In the first round of full EAP exchange, the ER server adds the rDSRK-Request or rRK-request to the DER message. 131 In the first round of full EAP exchange, the ER server adds the ERP-RK-Request AVP to the DER message.
132 If the home EAP server supports ERP extensions, it caches this request and continues the normal EAP authentication until completion. 132 If the home EAP server supports ERP extensions, it caches this request and continues the normal EAP authentication until completion. Otherwise, the optional AVP is simply ignored.
133 When the authentication is successful and EMSK is generated, the home EAP server will also derive the rRK or rDSRK as requested, and add this material to the final DEA in the new AVPs defined in this document. The server may check that the ER server that requested the material is in the Route-Record list of the last DER, but this is not mandatory. 133 When the authentication is successful and EMSK is generated, the home EAP server derives the rRK or rDSRK as requested, and adds this material to the last DEA in the ERP-RK-Answer AVP defined in this document. The server may check that the ER server that requested the material is in the Route-Record list of the last DER, but this is not mandatory.
134 134
135 When the ER server collocated with EAP proxy receives a DEA containing ERP AVPs, it extracts these AVP and saves the rRK or rDSRK material for later use. 135 When the ER server collocated with EAP proxy receives the DEA containing ERP-RK-Answer AVP, it extracts this AVP and saves the rRK or rDSRK material for later use.
136 136
137 EAP Proxy / 137 EAP Proxy /
138 Authenticator ER server Home EAP server 138 Authenticator ER server Home EAP server
139 ============= =========== =============== 139 ============= =========== ===============
140 -------------------------> 140 ------------------------->
141 EAP, DER 141 EAP/DER
142 (EAP-Response) 142 (EAP-Response)
143 -------------------------> 143 ------------------------->
144 EAP, DER 144 EAP/DER
145 (EAP-Response) 145 (EAP-Response)
146 (rDSRK-Request or rRK-Request) 146 (ERP-RK-Request)
147 147
148 <==================================================> 148 <==================================================>
149 Multi-round EAP unmodified exchanges 149 Multi-round EAP exchanges, unmodified
150 150
151 <------------------------- 151 <-------------------------
152 EAP, DEA 152 EAP/DEA
153 (EAP-Success) 153 (EAP-Success)
154 (MSK) 154 (MSK)
155 (rDSRK or rRK) 155 (ERP-RK-Answer)
156 <------------------------- 156 <-------------------------
157 EAP, DEA 157 EAP/DEA
158 (EAP-Success) 158 (EAP-Success)
159 (MSK) 159 (MSK)
160 160
161 Figure 4. Implicit ERP bootstrapping during full EAP authentication. 161 Figure 4. Implicit ERP bootstrapping during full EAP authentication.
162 162
163 163
164 164
165 *Scenario 4: Case of MIP6 ?* 165 *Scenario 4: Case of MIP6*
166 166
167 {TODO: study this case} 167 {TODO: study this case ?}
168 168
169 169
170 *Scenario 5: Other possibilities* 170 *Scenario 5: Other possibilities*
171 171
172 {In case implementation-specific solution is retained, list here the constraints?} 172 {In case implementation-specific solution is retained, list here the constraints?}
181 --------------------------------------------------------- 181 ---------------------------------------------------------
182 Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP 182 Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP
183 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP 183 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP
184 184
185 Figure 5: Command Codes 185 Figure 5: Command Codes
186 The following new AVPs are defined in this document.
187
188
186 189
187 *ERP-RK-Request AVP* 190 *ERP-RK-Request AVP*
188 191
189 The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. It is used by the ER server to request root key material used in ERP. 192 The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. It is used by the ER server to request root key material used in ERP.
190 193
197 200
198 201
199 *ERP-Realm AVP* 202 *ERP-Realm AVP*
200 203
201 The ERP-Realm AVP (AVP Code TBD) is of type {DiameterIdentity? OctetString?}. It contains the name of the realm in which the ER server is located. 204 The ERP-Realm AVP (AVP Code TBD) is of type {DiameterIdentity? OctetString?}. It contains the name of the realm in which the ER server is located.
205 {FFS: We may re-use Origin-Realm here instead?}
202 206
203 207
204 208
205 *ERP-RK-Answer AVP* 209 *ERP-RK-Answer AVP*
206 210
215 * [ AVP ] 219 * [ AVP ]
216 220
217 221
218 *ERP-RK AVP* 222 *ERP-RK AVP*
219 223
220 The ERP-RK AVP (AVP Code TBD) is of type OctetString. It contains the root key (either rRK or rDSRK) to be used for ERP feature with the peer to which this session belongs. How this material is derived and used is specified in [RFC5296]. 224 The ERP-RK AVP (AVP Code TBD) is of type OctetString. It contains the root key (either rRK or rDSRK) to be used for ERP with the peer to which this session belongs. How this material is derived and used is specified in [RFC5296].
221 225
222 226
223 227
224 *ERP-RK-Name AVP* 228 *ERP-RK-Name AVP*
225 229
245 It is possible to cache the necessary information at the ER server level. Is it useful to specify this mechanism in this document? 249 It is possible to cache the necessary information at the ER server level. Is it useful to specify this mechanism in this document?
246 250
247 251
248 252
249 253
250
"Welcome to our mercurial repository"