idnits 2.17.1 draft-ietf-radext-coa-proxy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7542]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5176, but the abstract doesn't seem to directly say this. It does mention RFC5176 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5176, updated by this document, for RFC5378 checks: 2007-01-22) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 April 2018) is 2193 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Updates: 5176 J. Korhonen 5 Category: Standards Track Nokia Siemens Networks 6 7 24 April 2018 9 Dynamic Authorization Proxying in 10 Remote Authorization Dial-In User Service Protocol (RADIUS) 11 draft-ietf-radext-coa-proxy-04.txt 13 Abstract 15 RFC 5176 defines Change of Authorization (CoA) and Disconnect Message 16 (DM) behavior for RADIUS. Section 3.1 of that document suggests that 17 proxying these messages is possible, but gives no guidance as to how 18 that is done. This specification corrects that omission for 19 scenarios where networks use Realm-based proxying as defined in 20 [RFC7542]. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on October 24, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info/) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ............................................. 4 63 1.1. Terminology ......................................... 4 64 1.2. Requirements Language ............................... 5 65 2. Problem Statement ........................................ 6 66 2.1. Typical RADIUS Proxying ............................. 6 67 2.2. CoA Processing ...................................... 6 68 2.3. Failure of CoA Proxying ............................. 7 69 3. How to Perform CoA Proxying .............................. 7 70 3.1. Changes to Access-Request and Accounting-Request pack 8 71 3.2. Proxying of CoA-Request and Disconnect-Request packet 8 72 3.3. Operator-NAS-Identifier ............................. 9 73 4. Requirements ............................................. 11 74 4.1. Requirements on Home Servers ........................ 11 75 4.2. Requirements on Visited Networks .................... 11 76 4.3. Requirements on Proxies ............................. 12 77 4.3.1. Security Requirements on Proxies ............... 12 78 4.3.2. Filtering Requirements on Proxies .............. 13 79 5. Functionality ............................................ 14 80 5.1. User Login .......................................... 14 81 5.2. CoA Proxing ......................................... 14 82 6. Security Considerations .................................. 15 83 7. IANA Considerations ...................................... 15 84 8. References ............................................... 15 85 8.1. Normative References ................................ 15 86 8.2. Informative References .............................. 16 88 1. Introduction 90 RFC 5176 [RFC5176] defines Change of Authorization (CoA) and 91 Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that 92 document suggests that proxying these messages is possible, but gives 93 no guidance as to how that is done. This omission means that in 94 practice, proxying of CoA packets is impossible. 96 We correct that ommission here by explaining how proxying of these 97 packets can be done by leveraging an existing RADIUS attribute, 98 Operator-Name (Section 4.1 of [RFC5580]). We then explain how this 99 attribute can be used by CoA proxies to route packets "backwards" 100 through a RADIUS proxy chain to the Visited Network. We introduce a 101 new attribute; Operator-NAS-Identifier, which permits packets to be 102 routed from the RADIUS server at the Visited Network to the NAS. We 103 then explain how use of this attribute can increase privacy of the 104 internal implementation of the visited network. 106 We limit the use-case of CoA proxying to Realm-based proxying as 107 defined in [RFC7542]. Other forms of CoA proxying are possible, but 108 are not specified here. 110 We conclude with a discussion of the security implications of the 111 design, and show how they are acceptable. 113 1.1. Terminology 115 This document frequently uses the following terms: 117 CoA 119 Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK, 120 as defined in [RFC5176]. That specification also defines 121 Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For 122 simplicity here, where we use "CoA", we mean a generic "CoA- 123 Request or Disconnect-Request" packet. We use "CoA-Request" or 124 "Disconnect-Request" to refer to the specific packet types. 126 Network Access Identifier 128 The Network Access Identifier (NAI) [RFC7542] is the user identity 129 submitted by the client during network access authentication. The 130 purpose of the NAI is to identify the user as well as to assist in 131 the routing of the authentication request. Please note that the 132 NAI may not necessarily be the same as the user's email address or 133 the user identity submitted in an application layer 134 authentication. 136 Network Access Server 138 The Network Access Server (NAS) is the device that clients connect 139 to in order to get access to the network. In PPTP terminology, 140 this is referred to as the PPTP Access Concentrator (PAC), and in 141 L2TP terminology, it is referred to as the L2TP Access 142 Concentrator (LAC). In IEEE 802.11, it is referred to as an 143 Access Point. 145 Home Network 147 The network which holds the authentication credentials for a user. 149 Visited Network 151 A network other than the home network, where the user attempts to 152 gain network access. The Visited Network typically has a 153 relationship with the Home Network, possibly through one or more 154 intermediary proxies. 156 1.2. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. Problem Statement 164 This section describes how RADIUS proxying works, how CoA packets 165 work, and why CoA proxying as discussed in RFC 5176 is insufficient 166 in practice. 168 2.1. Typical RADIUS Proxying 170 When a RADIUS server proxies an Access-Request packet, it typically 171 does so based on the contents of the User-Name attribute, which 172 contains a Network Access Identifier [RFC7542]. Other methods are 173 possible, but we restrict ourselves to this usage, as it is the most 174 common one. 176 The proxy server looks up the "Realm" portion of the NAI in a logical 177 AAA routing table, as described in Section 3 of [RFC7542]. The entry 178 in that table is the "next hop" to which the packet is sent. This 179 "next hop" may be another proxy, or it may be the home server for 180 that realm. 182 If the "next hop" is a proxy, it will perform the same Realm lookup, 183 and then proxy the packet. Alternatively, if the "next hop" is the 184 Home Server for that realm, it will try to authenticate the user, and 185 respond with an Access-Accept, Access-Reject, or Access-Challenge. 187 The RADIUS client will match the response packet to an outstanding 188 request. If the client is part of a proxy, it will then proxy that 189 response packet in turn to the system which originated the Access- 190 Request. This process occurs until the response packet arrives at 191 the NAS. 193 The proxies are typically stateful with respect to ongoing request / 194 response packets, but stateless with respect to user sessions. Once 195 a response has been received by the proxy, it can discard all 196 information about the request packet. 198 The same proxy method is used for Accounting-Request packets. The 199 combination of the two methods allows proxies to connect Visited 200 Networks to Home Networks for all AAA purposes. 202 2.2. CoA Processing 204 [RFC5176] describes how CoA clients send packets to CoA servers. We 205 note that system comprising the CoA client is typically co-located 206 with, or is the same as, the RADIUS server. Similarly, the CoA 207 server is a system that is either co-located with, or is the same as, 208 the RADIUS client. 210 In the case of packets sent inside of one network, the source and 211 destination of CoA packets is locally determined. There is thus no 212 need for standardization of that process, as networks are free to 213 send CoA packets whenever they want, for whatever reason they want. 215 2.3. Failure of CoA Proxying 217 The situation is more complicated when multiple networks are 218 involved. [RFC5176] suggests that CoA proxying is permitted, but 219 makes no suggestions for how it should be done. 221 If proxies tracked user sessions, it might be possible for a proxy to 222 match an incoming CoA-Request to a user session, and then to proxy 223 that packet to the RADIUS client which originated the Access-Request 224 for that sessions. 226 There are many problems with such a scenario. The CoA server may, in 227 fact, not be co-located with the RADIUS client. The RADIUS client 228 may be down, but there may be a different CoA server which could 229 accept the packet. User session tracking can be expensive and 230 complicated for a proxy, and many proxies do not record user 231 sessions. Finally, [RFC5176] is silent on the topic of "session 232 identification attributes", which makes it impossible for a proxy to 233 determine if a CoA packet matches a particular user session. 235 The result of all of these issues is that CoA proxying cannot be 236 performed when using the behavior defined in [RFC5176]. 238 3. How to Perform CoA Proxying 240 The solution to the above problem is to use the Operator-Name 241 attribute defined in [RFC5580], Section 4.1. We repeat a portion of 242 that definition here for clarity: 244 This attribute carries the operator namespace identifier and the 245 operator name. The operator name is combined with the namespace 246 identifier to uniquely identify the owner of an access network. 248 Followed by a description of the REALM namespace: 250 REALM ('1' (0x31)): 252 The REALM operator namespace can be used to indicate operator 253 names based on any registered domain name. Such names are 254 required to be unique, and the rights to use a given realm name 255 are obtained coincident with acquiring the rights to use a 256 particular Fully Qualified Domain Name (FQDN). ... 258 In short, the Operator-Name attribute contains the an ASCII "1", 259 followed by the Realm of the Visited Network. e.g. for the 260 "example.com" realm, the Operator-Name attribute contains the text 261 "1example.com". This information is precisely what is needed by 262 intermediate nodes, in order to perform CoA proxying. 264 3.1. Changes to Access-Request and Accounting-Request packets 266 When a Visited Network proxies an Access-Request or Accounting- 267 Request packet outside of its network, it SHOULD include an Operator- 268 Name attribute in the packet, as discussed in Section 4.1 of 269 [RFC5580]. The contents of the Operator-Name should be "1", followed 270 by the realm name of the Visited Network. Where the Visited Network 271 has more than one realm name, a "canonical" one should be chosen, and 272 used for all packets. 274 Visited Networks MUST use a consistent value for Operator-Name for 275 one user session. That is, sending "1example.com" in an Access- 276 Request packet, and "1example.org" in an Accounting-Request packet 277 for that same session is forbidden. Such behavior would make it look 278 like the users session was simultaneously in two different Visited 279 Networks, which is impossible. 281 Proxies which record user session information SHOULD also record 282 Operator-Name. Proxies which do not record user session information 283 do not need to record Operator-Name. 285 Home Networks SHOULD record Operator-Name along with any other 286 information that they record about user sessions. Home Networks 287 which expect to send CoA packets to Visited Networks MUST record 288 Operator-Name for each user session which originates from a Visited 289 Network. Failure to record the Operator-Name would mean that it 290 would be impossible to send CoA packets to the Visited Network. 292 Networks which contain both the RADIUS client and RADIUS server do 293 not need to create, record or track Operator-Name. That is, if the 294 Visited Network and Home Network are the same, there is no need to 295 use the Operator-Name attribute. 297 3.2. Proxying of CoA-Request and Disconnect-Request packets 299 When a Home Network wishes to send a CoA-Request or Disconnect- 300 Request packet to a Visited Network, it MUST include an Operator-Name 301 attribute in the packet. The value of the Operator-Name MUST be the 302 value which was recorded earlier for that user session. 304 The Home Network MUST lookup the realm from the Operator-Name in a 305 logical "realm routing table", as discussed in [RFC7542] Section 3. 307 That logical realm table is defined there as: 309 a logical AAA routing table, where the "utf8-realm" portion 310 acts as a key, and the values stored in the table are one or more 311 "next hop" AAA servers. 313 In order to support proxying of CoA packets, this table is extended 314 to include a mapping between "utf8-realm" and one ore more "next hop" 315 CoA servers. 317 When proxying CoA-Request and Disconnect-Request packets, the lookups 318 will return data from the "CoA server" field, instead of the "AAA 319 server" field. 321 In practice, this process means that CoA proxying works exactly like 322 "normal" RADIUS proxying, except that the proxy decision is made 323 using the realm from the Operator-Name attribute, instead of using 324 the realm from the User-Name attribute. 326 Proxies which receive the CoA packet MUST look up the realm from the 327 Operator-Name in a logical "realm routing table", as with Home 328 Servers, above. The packet is then sent to the realm which was found 329 in that table. This process continues with any subsequent proxies 330 until the packet reaches the Visited Network. 332 The Visited Network can then send the CoA packet to the NAS, and 333 return any response packet back up the proxy chain to the Home 334 Server. 336 The only missing piece here is how the Visited Network gets the 337 packet from its CoA server to the NAS. The Visited Network could use 338 NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these 339 attributes may be incorrect, or may be missing entirely. 341 These attributes may be incorrect because proxies which forward 342 Access-Request packets often re-write them for internal policy 343 reasons. These attributes may be missing, because the Visited 344 Network may not want all upstream proxies and Home Servers to have 345 detailed information about the internals of its private network. 347 We therefore need a way to identifier a NAS in the Visited Network, 348 in a way which is both private, and which does not use any existing 349 attribute. 351 3.3. Operator-NAS-Identifier 353 The Operator-NAS-Identifier attribute contains opaque information 354 which identifies a NAS in a Visited Network. It MAY appear in the 355 following packets: Access-Request, Accounting-Request, CoA-Request, 356 or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in 357 any other packet. 359 Operator-NAS-Identifier MAY occur in a packet if the packet also 360 contains an Operator-Name attribute. Operator-NAS-Identifier MUST 361 NOT appear in a packet if there is no Operator-Name in the packet. 362 Operator-NAS-Identifier MUST NOT occur more than once in a packet. 364 An Operator-NAS-Identifer attribute SHOULD be added to an Access- 365 Request or Accounting-Request packet by a Visited Network just before 366 proxying a packet to an external RADIUS server. When the Operator- 367 NAS-Identifer attribute is added to a packet, the following 368 attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- 369 Identifier. The proxy MUST then add a NAS-Identifier attribute, in 370 order satisfy the requirements of Section 4.1 of [RFC2865], and of 371 [RFC2866]. 373 We suggest that the contents of the NAS-Identifier be the Realm name 374 of the Visited Network. That is, for everyone outside of the Visited 375 Network, there is only one NAS: the Visited Network itself. For the 376 Visited Network, the identity of the NAS is private information, 377 which is opaque to everyone else. 379 Description 381 An opaque token describing the NAS a user has logged into. 383 Type 385 TBD. To be assigned by IANA from the "short extended space". 387 Length 389 4 to 23. 391 Implementations supporting this attribute MUST be able to handle 392 between one (1) and twenty (20) octets of data. Implementations 393 creating an Operator-NAS-Identifier MUST NOT create attributes 394 with more than twenty octets of data. A twenty octet string is 395 more than sufficient to individually address all of the NASes on 396 the planet. 398 Data Type 400 string. See [RFC8044] Section 3.6 for a definition. 402 Value 403 The contents of this attribute are an opaque token interpretable 404 only by the Visited Network. 406 This token MUST allow the Visited Network to direct the packet to 407 the NAS for the users session. In practice, this requirement 408 means that the Visited Network will either track these tokens in a 409 database, or it will create tokens which can be decoded in order 410 to reveal the identity of the NAS. 412 4. Requirements 414 4.1. Requirements on Home Servers 416 The Operator-NAS-Identifier attribute MUST be stored by a Home Server 417 along with any user session identification attributes. When sending 418 a CoA packet for a user session, the Home Server MUST include any 419 Operator-NAS-Identifier it has recorded for that session. 421 A Home Server MUST NOT send CoA packets for users of other networks. 422 The provisions of the next few sections describe how other 423 participants in the RADIUS ecosystem can enforce this requirement. 425 4.2. Requirements on Visited Networks 427 A Visited Network which receives a proxied CoA packet MUST perform 428 all of the checks discussed above for proxies. This requirement is 429 because we assume that the Visited Network has a proxy in between the 430 NAS and any external (i.e. third-party) proxy. Situations where a 431 NAS sends packets directly to a third-party RADIUS server are outside 432 of the scope of this specification. 434 Due to the limited number of attributes allowed in CoA packets by 435 [RFC5176] Section 2.3, a Visited Network MUST remove the Operator- 436 Name and Operator-NAS-Identifier attributes from any CoA-Request or 437 Disconnect-Request packet prior to proxying that packet to the final 438 CoA server (i.e. NAS). This requirement is phrase more generically 439 below, in Section 4.3.2. 441 A Visited Network may create an Operator-NAS-Identifier via many 442 methods. The value SHOULD be cryptographically strong, and SHOULD be 443 verifiable by the Visited Network, without requiring it to track 444 every individual value of Operator-NAS-identifier in a database. 446 Exactly how this requirement is implemented is outside of the scope 447 of this document. 449 4.3. Requirements on Proxies 451 There are a number of requirements on proxies, both CoA proxies and 452 RADIUS proxies. For the purpose of this section, we assume that each 453 RADIUS proxy shares a common administration with a corresponding CoA 454 proxy, and that the two systems can communicate electronically. 455 There is no requirement that these systems are co-located. 457 4.3.1. Security Requirements on Proxies 459 Section 6.1 of [RFC5176] has some security requirements on proxies 460 which handle CoA-Request and Disconnect-Request packets: 462 ... a proxy MAY perform a "reverse path 463 forwarding" (RPF) check to verify that a Disconnect-Request or 464 CoA-Request originates from an authorized Dynamic Authorization 465 Client. 467 We strengthen that requirement by saying that a proxy MUST perform a 468 "reverse path forwarding" (RPF) check to verify that a Disconnect- 469 Request or CoA-Request originates from an authorized Dynamic 470 Authorization Client. Without this check, a proxy may forward forged 471 packets, and thus contribute to the forgery problem instead of 472 preventing it. 474 Proxies which record user session information SHOULD verify the 475 contents of a received CoA packet against the recorded data for that 476 user session. If the proxy determines that the information in the 477 packet does not match the recorded user session, it SHOULD return a 478 CoA-NAK or Disconnect-NAK packet, which contains an Error-Cause 479 attribute having value 503 ("Session Context Not Found"). 481 We recognize that because a RADIUS proxy will see Access-Request and 482 Accounting-Request packets, it will have sufficient information to 483 forge CoA packets. The RADIUS proxy will thus have the ability to 484 subsequently disconnect any user who was authenticated through 485 itself. 487 We suggest that the real-world effect of this security problem is 488 minimal. RADIUS proxies can already return Access-Accept or Access- 489 Reject for Access-Request packets, and can change authorization 490 attributes contained in an Access-Accept. Allowing a proxy to change 491 (or disconnect) a user session post-authentication is not 492 substantially different from changing (or refusing to connect) a user 493 session during the initial process of authentiction. 495 The largest problem is that there are no provisions in RADIUS for 496 "end to end" security. That is, the Visited Network and Home Network 497 cannot communicate privately in the presence of proxies. This 498 limitation originates from the design of RADIUS for Access-Request 499 and Accounting-Request packets. That limitation is then carried over 500 to CoA-Request and Disconnect-Request packets. 502 We cannot therefore prevent proxies or Home Servers from forging CoA 503 packets. We can only create scenarios where that forgery is hard to 504 perform, and/or is likely to be detected. 506 4.3.2. Filtering Requirements on Proxies 508 Section 2.3 of [RFC5176] makes the following requirement for CoA 509 servers: 511 In CoA-Request and Disconnect-Request packets, all attributes 512 MUST be treated as mandatory. 514 These requirements are too stringent for a CoA proxy. Instead, we 515 say that for a CoA proxy, all attributes MUST NOT be treated as 516 mandatory. Proxies SHOULD perform proxying based on Operator-Name, 517 though other schemes are possible, but are not discussed here. 518 Proxies SHOULD forward all packets as-is, with minimal changes. Only 519 the final CoA server (i.e NAS) can make a decision on which 520 attributes are mandatory and which are not. 522 Where Operator-Realm and Operator-NAS-Identifier is received by a 523 proxy, the proxy MUST pass those attributes through unchanged. This 524 requirement applies to all proxies, including ones which forward any 525 or all of Access-Request, Accounting-Request, CoA-Request, and 526 Disconnect-Request packets. 528 All attributes added by a RADIUS proxy when sending packets from the 529 Visited Network to the Home Network Network MUST be removed by the 530 corresponding CoA proxy from packets which travel the reverse path. 531 That is, any attribute editing which is done on the "forward" path 532 MUST be undone on the "reverse" path. 534 The result is that a NAS will only ever receive CoA packets which 535 either contain attributes sent by the NAS to it's local RADIUS 536 server, or contain attributes which are sent by the Home Server in 537 order to perform a change of authorization. 539 We note that the above requirement applies not only to Operator-Name 540 and Operator-NAS-Identifier, but also to any future attributes which 541 are added by a RADIUS proxy. 543 5. Functionality 545 This section describes how the two attributes work together to permit 546 CoA proxying. 548 5.1. User Login 550 In this scenario, we follow a roaming user attempting authentication 551 in a Visited Network. The login attempt is done via a NAS in the 552 Visited Network. That NAS will send an Access-Request packet to the 553 visited RADIUS server. The visited RADIUS server will see that the 554 user is roaming, and xwill add an Operator-Name attribute, with value 555 "1" followed by it's own realm name. e.g. "1example.com". The 556 visited RADIUS server MAY also add an Operator-NAS-Identifier. 558 The visited RADIUS server will then proxy the authentication request 559 to an upstream server. That server may be the Home Server, or it may 560 be a proxy. In the case of a proxy, the proxy will forward the 561 packet, until the packet reaches the Home Server. 563 The Home Server will record both Operator-Name and Operator-NAS- 564 Identfier along with other information about the users session. 566 5.2. CoA Proxing 568 When the Home Server determines that a user should be disconnecte, it 569 looks up the Operator-Name and Operator-NAS-Identifer, along with 570 other user session identifiers as described in [RFC5176]. The Home 571 Server then looks up the realm from the Operator-Name attribute in 572 the logical AAA routing table, in order to find the CoA server for 573 that realm (which may be a proxy). The Disconnect-Request is then 574 sent to that CoA server. 576 The CoA server receives the request, and if it is a proxy, performs a 577 similar lookup as done by the Home Server. The packet is then 578 proxied repeatedly until it reaches the Visited Network. 580 If the proxy cannot find a destination for the request, or if no 581 Operator-Name attribute exists in the request, the proxy will return 582 a CoA-NAK with Error-Cause 502 (Request Not Routable). 584 The Visited Network will recieve the CoA-Request packet, and will use 585 the Operator-NAS-Identifier (if available) attribute to determine 586 which local CoA server (i.e. NAS) the packet should be sent to. If 587 there is no Opertor-NAS-Identifier attribute, the Visited Network may 588 use other means to locate the NAS, such as consulting a local 589 database which tracks user sessions. 591 The Operator-Name and Operator-NAS-Identifer attributes are then 592 removed fromt he packet, and it is then sent to the CoA server. 594 If no CoA server can be found, the Visited Network return a CoA-NAK 595 with Error-Cause 403 (NAS Identification Mismatch). 597 Any response from the CoA server (NAS) is returned to the Home 598 Network, via the normal method of returning responses to requests. 600 6. Security Considerations 602 This specification incorporates by reference the [RFC6929] Section 603 11. In short, RADIUS has many known issues which are discussed in 604 detail there, and which do not need to be repeated here. 606 This specification adds one new attribute, and defines new behavior 607 for RADIUS proxying. As this behavior mirrors existing RADIUS 608 proxying, we do not believe that it introduces any new security 609 issues. 611 The Operator-NAS-Identifier SHOULD be created by the Visited Network 612 such that its contents are opaque to all other parties. This ensures 613 that anyone observing unencrypted RADIUS traffic gains no information 614 about the internals of the Visited Network. 616 7. IANA Considerations 618 IANA is instructed to allocate one new RADIUS attribute, as per 619 Section 3.3, above. 621 8. References 623 8.1. Normative References 625 [RFC2119] 626 Bradner, S., "Key words for use in RFCs to Indicate Requirement 627 Levels", RFC 2119, March, 1997. 629 [RFC2865] 630 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 631 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 633 [RFC5580] 634 Tschofenig H., Ed. "Carrying Location Objects in RADIUS and 635 Diameter", RFC 5580, August 2009. 637 [RFC6929] 638 DeKok A. and Lior, A., "Remote Authentication Dial-In User Service 639 (RADIUS) Protocol Extensions", RFC 6929, April 2013. 641 [RFC7542] 642 DeKok A., "The Network Access Identifier", RFC 7542, May 2015. 644 [RFC8044] 645 DeKok A., "Data Types in the Remote Authentication Dial-In User 646 Service Protocol (RADIUS)", RFC 8044, January 2017. 648 8.2. Informative References 650 [RFC2866] 651 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 653 [RFC5176] 654 Chiba, M. et al, "Dynamic Authorization Extensions to Remote 655 Authentication Dial In User Service (RADIUS)", RFC 5176, January 656 2008. 658 Authors' Addresses 660 Alan DeKok 661 The FreeRADIUS Server Project 663 Email: aland@freeradius.org 665 Jouni Korhonen 667 EMail: jouni.nospam@gmail.com