idnits 2.17.1 draft-ietf-radext-coa-proxy-02.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 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 (29 November 2017) is 2311 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: 0 errors (**), 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 29 November 2017 9 Dynamic Authorization Proxying in 10 Remote Authorization Dial-In User Service Protocol (RADIUS) 11 draft-ietf-radext-coa-proxy-01.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. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 29, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info/) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ............................................. 4 61 1.1. Terminology ......................................... 4 62 1.2. Requirements Language ............................... 5 63 2. Problem Statement ........................................ 6 64 2.1. Typical RADIUS Proxying ............................. 6 65 2.2. CoA Processing ...................................... 6 66 2.3. Failure of CoA Proxying ............................. 7 67 3. How to Perform CoA Proxying .............................. 7 68 3.1. Changes to Access-Request and Accounting-Request pack 8 69 3.2. Proxying of CoA-Request and Disconnect-Request packet 8 70 3.3. Operator-NAS-Identifier ............................. 9 71 4. Requirements ............................................. 11 72 4.1. Requirements on Home Servers ........................ 11 73 4.2. Requirements on Visited Networks .................... 11 74 4.3. Requirements on Proxies ............................. 11 75 4.3.1. Security Requirements on Proxies ............... 12 76 4.3.2. Filtering Requirements on Proxies .............. 13 77 5. Functionality ............................................ 13 78 5.1. User Login .......................................... 13 79 5.2. CoA Proxing ......................................... 14 80 6. Security Considerations .................................. 15 81 7. IANA Considerations ...................................... 15 82 8. References ............................................... 15 83 8.1. Normative References ................................ 15 84 8.2. Informative References .............................. 16 86 1. Introduction 88 RFC 5176 [RFC5176] defines Change of Authorization (CoA) and 89 Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that 90 document suggests that proxying these messages is possible, but gives 91 no guidance as to how that is done. This omission means that in 92 practice, proxying of CoA packets is impossible. 94 We correct that ommission here by explaining how proxying of these 95 packets can be done by leveraging an existing RADIUS attribute, 96 Operator-Name (Section 4.1 of [RFC5580]). We then explain how this 97 attribute can be used by CoA proxies to route packets "backwards" 98 through a RADIUS proxy chain to the Visited Network. We introduce a 99 new attribute; Operator-NAS-Identifier, which permits packets to be 100 routed from the RADIUS server at the Visited Network to the NAS. We 101 then explain how use of this attribute can increase privacy of the 102 internal implementation of the visited network. 104 We conclude with a discussion of the security implications of the 105 design, and show how they are acceptable. 107 1.1. Terminology 109 This document frequently uses the following terms: 111 CoA 113 Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK, 114 as defined in [RFC5176]. That specification also defines 115 Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For 116 simplicity here, where we use "CoA", we mean a generic "CoA- 117 Request or Disconnect-Request" packet. We use "CoA-Request" or 118 "Disconnect-Request" to refer to the specific packet types. 120 Network Access Identifier 122 The Network Access Identifier (NAI) [RFC7542] is the user identity 123 submitted by the client during network access authentication. The 124 purpose of the NAI is to identify the user as well as to assist in 125 the routing of the authentication request. Please note that the 126 NAI may not necessarily be the same as the user's email address or 127 the user identity submitted in an application layer 128 authentication. 130 Network Access Server 132 The Network Access Server (NAS) is the device that clients connect 133 to in order to get access to the network. In PPTP terminology, 134 this is referred to as the PPTP Access Concentrator (PAC), and in 135 L2TP terminology, it is referred to as the L2TP Access 136 Concentrator (LAC). In IEEE 802.11, it is referred to as an 137 Access Point. 139 Home Network 141 The network which holds the authentication credentials for a user. 143 Visited Network 145 A network other than the home network, where the user attempts to 146 gain network access. The Visited Network typically has a 147 relationship with the Home Network, possibly through one or more 148 intermediary proxies. 150 1.2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 2. Problem Statement 158 This section describes how RADIUS proxying works, how CoA packets 159 work, and why CoA proxying as discussed in RFC 5176 is insufficient 160 in practice. 162 2.1. Typical RADIUS Proxying 164 When a RADIUS server proxies an Access-Request packet, it typically 165 does so based on the contents of the User-Name attribute, which 166 contains a Network Access Identifier [RFC7542]. Other methods are 167 possible, but we restrict ourselves to this usage, as it is the most 168 common one. 170 The proxy server looks up the "Realm" portion of the NAI in a logical 171 AAA routing table, as described in Section 3 of [RFC7542]. The entry 172 in that table is the "next hop" to which the packet is sent. This 173 "next hop" may be another proxy, or it may be the home server for 174 that realm. 176 If the "next hop" is a proxy, it will perform the same Realm lookup, 177 and then proxy the packet. Alternatively, if the "next hop" is the 178 Home Server for that realm, it will try to authenticate the user, and 179 respond with an Access-Accept, Access-Reject, or Access-Challenge. 181 The RADIUS client will match the response packet to an outstanding 182 request. If the client is part of a proxy, it will then proxy that 183 response packet in turn to the system which originated the Access- 184 Request. This process occurs until the response packet arrives at 185 the NAS. 187 The proxies are typically stateful with respect to ongoing request / 188 response packets, but stateless with respect to user sessions. Once 189 a response has been received by the proxy, it can discard all 190 information about the request packet. 192 The same proxy method is used for Accounting-Request packets. The 193 combination of the two methods allows proxies to connect Visited 194 Networks to Home Networks for all AAA purposes. 196 2.2. CoA Processing 198 [RFC5176] describes how CoA clients send packets to CoA servers. We 199 note that system comprising the CoA client is typically co-located 200 with, or is the same as, the RADIUS server. Similarly, the CoA 201 server is a system that is either co-located with, or is the same as, 202 the RADIUS client. 204 In the case of packets sent inside of one network, the source and 205 destination of CoA packets is locally determined. There is thus no 206 need for standardization of that process, as networks are free to 207 send CoA packets whenever they want, for whatever reason they want. 209 2.3. Failure of CoA Proxying 211 The situation is more complicated when multiple networks are 212 involved. [RFC5176] suggests that CoA proxying is permitted, but 213 makes no suggestions for how it should be done. 215 If proxies tracked user sessions, it might be possible for a proxy to 216 match an incoming CoA-Request to a user session, and then to proxy 217 that packet to the RADIUS client which originated the Access-Request 218 for that sessions. 220 There are many problems with such a scenario. The CoA server may, in 221 fact, not be co-located with the RADIUS client. The RADIUS client 222 may be down, but there may be a different CoA server which could 223 accept the packet. User session tracking can be expensive and 224 complicated for a proxy, and many proxies do not record user 225 sessions. Finally, [RFC5176] is silent on the topic of "session 226 identification attributes", which makes it impossible for a proxy to 227 determine if a CoA packet matches a particular user session. 229 The result of all of these issues is that CoA proxying cannot be 230 performed when using the behavior defined in [RFC5176]. 232 3. How to Perform CoA Proxying 234 The solution to the above problem is to use the Operator-Name 235 attribute defined in [RFC5580], Section 4.1. We repeat a portion of 236 that definition here for clarity: 238 This attribute carries the operator namespace identifier and the 239 operator name. The operator name is combined with the namespace 240 identifier to uniquely identify the owner of an access network. 242 Followed by a description of the REALM namespace: 244 REALM ('1' (0x31)): 246 The REALM operator namespace can be used to indicate operator 247 names based on any registered domain name. Such names are 248 required to be unique, and the rights to use a given realm name 249 are obtained coincident with acquiring the rights to use a 250 particular Fully Qualified Domain Name (FQDN). ... 252 In short, the Operator-Name attribute contains the an ASCII "1", 253 followed by the Realm of the Visited Network. e.g. for the 254 "example.com" realm, the Operator-Name attribute contains the text 255 "1example.com". This information is precisely what is needed by 256 intermediate nodes, in order to perform CoA proxying. 258 3.1. Changes to Access-Request and Accounting-Request packets 260 When a Visited Network proxies an Access-Request or Accounting- 261 Request packet outside of its network, it SHOULD include an Operator- 262 Name attribute in the packet, as discussed in Section 4.1 of 263 [RFC5580]. The contents of the Operator-Name should be "1", followed 264 by the realm name of the Visited Network. Where the Visited Network 265 has more than one realm name, a "canonical" one should be chosen, and 266 used for all packets. 268 Visited Networks MUST use a consistent value for Operator-Name for 269 one user session. That is, sending "1example.com" in an Access- 270 Request packet, and "1example.org" in an Accounting-Request packet 271 for that same session is forbidden. Such behavior would make it look 272 like the users session was simultaneously in two different Visited 273 Networks, which is impossible. 275 Proxies which record user session information SHOULD also record 276 Operator-Name. Proxies which do not record user session information 277 do not need to record Operator-Name. 279 Home Networks SHOULD record Operator-Name along with any other 280 information that they record about user sessions. Home Networks 281 which expect to send CoA packets to Visited Networks MUST record 282 Operator-Name for each user session which originates from a Visited 283 Network. Failure to record the Operator-Name would mean that it 284 would be impossible to send CoA packets to the Visited Network. 286 Networks which contain both the RADIUS client and RADIUS server do 287 not need to create, record or track Operator-Name. That is, if the 288 Visited Network and Home Network are the same, there is no need to 289 use the Operator-Name attribute. 291 3.2. Proxying of CoA-Request and Disconnect-Request packets 293 When a Home Network wishes to send a CoA-Request or Disconnect- 294 Request packet to a Visited Network, it MUST include an Operator-Name 295 attribute in the packet. The value of the Operator-Name MUST be the 296 value which was recorded earlier for that user session. 298 The Home Network MUST lookup the realm from the Operator-Name in a 299 logical "realm routing table", as discussed in [RFC7542] Section 3. 301 In this case, the destination of the packet is not a RADIUS server, 302 but a CoA server. 304 In practice, this process means that CoA proxying works exactly like 305 "normal" RADIUS proxying, except that the proxy decision is made 306 using the realm from the Operator-Name attribute, instead of using 307 the realm from the User-Name attribute. 309 Proxies which receive the CoA packet MUST look up the realm from the 310 Operator-Name in a logical "realm routing table", as with Home 311 Servers, above. The packet is then sent to the realm which was found 312 in that table. This process continues with any subsequent proxies 313 until the packet reaches the Visited Network. 315 The Visited Network can then send the CoA packet to the NAS, and 316 return any response packet back up the proxy chain to the Home 317 Server. 319 The only missing piece here is how the Visited Network gets the 320 packet from its CoA server to the NAS. The Visited Network could use 321 NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these 322 attributes may be incorrect, or may be missing entirely. 324 These attributes may be incorrect because proxies which forward 325 Access-Request packets often re-write them for internal policy 326 reasons. These attributes may be missing, because the Visited 327 Network may not want all upstream proxies and Home Servers to have 328 detailed information about the internals of its private network. 330 We therefore need a way to identifier a NAS in the Visited Network, 331 in a way which is both private, and which does not use any existing 332 attribute. 334 3.3. Operator-NAS-Identifier 336 The Operator-NAS-Identifier attribute contains opaque information 337 which identifies a NAS in a Visited Network. It MAY appear in the 338 following packets: Access-Request, Accounting-Request, CoA-Request, 339 or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in 340 any other packet. 342 Operator-NAS-Identifier MAY occur in a packet if the packet also 343 contains an Operator-Name attribute. Operator-NAS-Identifier MUST 344 NOT appear in a packet if there is no Operator-Name in the packet. 345 Operator-NAS-Identifier MUST NOT occur more than once in a packet. 347 An Operator-NAS-Identifer attribute SHOULD be added to an Access- 348 Request or Accounting-Request packet by a Visited Network just before 349 proxying a packet to an external RADIUS server. When the Operator- 350 NAS-Identifer attribute is added to a packet, the following 351 attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- 352 Identifier. The proxy MUST then add a NAS-Identifier attribute, in 353 order satisfy the requirements of Section 4.1 of [RFC2865], and of 354 [RFC2866]. 356 We suggest that the contents of the NAS-Identifier be the Realm name 357 of the Visited Network. That is, for everyone outside of the Visited 358 Network, there is only one NAS: the Visited Network itself. For the 359 Visited Network, the identity of the NAS is private information, 360 which is opaque to everyone else. 362 Description 364 An opaque token describing the NAS a user has logged into. 366 Type 368 TBD. To be assigned by IANA 370 Length 372 TBD. Depends on IANA allocation. 374 Implementations supporting this attribute MUST be able to handle 375 between one (1) and twenty (20) octets of data. Implementations 376 creating an Operator-NAS-Identifier SHOULD NOT create attributes 377 with more than twenty octets of data. A twenty octet string is 378 more than sufficient to individually address all of the NASes on 379 the planet. 381 Data Type 383 string. See [RFC8044] Section 3.6 for a definition. 385 Value 387 The contents of this attribute are an opaque token interpretable 388 only by the Visited Network. 390 This token MUST allow the Visited Network to direct the packet to 391 the NAS for the users session. In practice, this requirement 392 means that the Visited Network will either track these tokens in a 393 database, or it will create tokens which can be decoded in order 394 to reveal the identity of the NAS. 396 4. Requirements 398 4.1. Requirements on Home Servers 400 The Operator-NAS-Identifier attribute MUST be stored by a Home Server 401 along with any user session identification attributes. When sending 402 a CoA packet for a user session, the Home Server MUST include any 403 Operator-NAS-Identifier it has recorded for that session. 405 A Home Server MUST NOT send CoA packets for users of other networks. 406 The provisions of the next few sections describe how other 407 participants in the RADIUS ecosystem can enforce this requirement. 409 4.2. Requirements on Visited Networks 411 A Visited Network which receives a proxied CoA packet MUST perform 412 all of the checks discussed above for proxies. This requirement is 413 because we assume that the Visited Network has a proxy in between the 414 NAS and any external (i.e. third-party) proxy. Situations where a 415 NAS sends packets directly to a third-party RADIUS server are outside 416 of the scope of this specification. 418 Due to the limited number of attributes allowed in CoA packets by 419 [RFC5176] Section 2.3, a Visited Network MUST remove the Operator- 420 Name and Operator-NAS-Identifier attributes from any CoA-Request or 421 Disconnect-Request packet prior to proxying that packet to the final 422 CoA server (i.e. NAS). This requirement is phrase more generically 423 below, in Section 4.3.2. 425 A Visited Network may create an Operator-NAS-Identifier via many 426 methods. The value SHOULD be cryptographically strong, and SHOULD be 427 verifiable by the Visited Network, without requiring it to track 428 every individual value of Operator-NAS-identifier in a database. 430 Exactly how this requirement is implemented is outside of the scope 431 of this document. 433 4.3. Requirements on Proxies 435 There are a number of requirements on proxies, both CoA proxies and 436 RADIUS proxies. For the purpose of this section, we assume that each 437 RADIUS proxy shares a common administration with a corresponding CoA 438 proxy, and that the two systems can communicate electronically. 439 There is no requirement that these systems are co-located. 441 4.3.1. Security Requirements on Proxies 443 Section 6.1 of [RFC5176] has some security requirements on proxies 444 which handle CoA-Request and Disconnect-Request packets: 446 ... a proxy MAY perform a "reverse path 447 forwarding" (RPF) check to verify that a Disconnect-Request or 448 CoA-Request originates from an authorized Dynamic Authorization 449 Client. 451 We strengthen that requirement by saying that a proxy MUST perform a 452 "reverse path forwarding" (RPF) check to verify that a Disconnect- 453 Request or CoA-Request originates from an authorized Dynamic 454 Authorization Client. Without this check, a proxy may forward forged 455 packets, and thus contribute to the forgery problem instead of 456 preventing it. 458 Proxies which record user session information SHOULD verify the 459 contents of a received CoA packet against the recorded data for that 460 user session. If the proxy determines that the information in the 461 packet does not match the recorded user session, it SHOULD return a 462 CoA-NAK or Disconnect-NAK packet, which contains an Error-Cause 463 attribute having value 503 ("Session Context Not Found"). 465 We recognize that because a RADIUS proxy will see Access-Request and 466 Accounting-Request packets, it will have sufficient information to 467 forge CoA packets. The RADIUS proxy will thus have the ability to 468 subsequently disconnect any user who was authenticated through 469 itself. 471 We suggest that the real-world effect of this security problem is 472 minimal. RADIUS proxies can already return Access-Accept or Access- 473 Reject for Access-Request packets, and can change authorization 474 attributes contained in an Access-Accept. Allowing a proxy to change 475 (or disconnect) a user session post-authentication is not 476 substantially different from changing (or refusing to connect) a user 477 session during the initial process of authentiction. 479 The largest problem is that there are no provisions in RADIUS for 480 "end to end" security. That is, the Visited Network and Home Network 481 cannot communicate privately in the presence of proxies. This 482 limitation originates from the design of RADIUS for Access-Request 483 and Accounting-Request packets. That limitation is then carried over 484 to CoA-Request and Disconnect-Request packets. 486 We cannot therefore prevent proxies or Home Servers from forging CoA 487 packets. We can only create scenarios where that forgery is hard to 488 perform, and/or is likely to be detected. 490 4.3.2. Filtering Requirements on Proxies 492 Section 2.3 of [RFC5176] makes the following requirement for CoA 493 servers: 495 In CoA-Request and Disconnect-Request packets, all attributes 496 MUST be treated as mandatory. 498 These requirements are too stringent for a CoA proxy. Instead, we 499 say that for a CoA proxy, all attributes MUST NOT be treated as 500 mandatory. Proxies SHOULD perform proxying based on Operator-Name, 501 though other schemes are possible, but are not discussed here. 502 Proxies SHOULD forward all packets as-is, with minimal changes. Only 503 the final CoA server (i.e NAS) can make a decision on which 504 attributes are mandatory and which are not. 506 Where Operator-Realm and Operator-NAS-Identifier is received by a 507 proxy, the proxy MUST pass those attributes through unchanged. This 508 requirement applies to all proxies, including ones which forward any 509 or all of Access-Request, Accounting-Request, CoA-Request, and 510 Disconnect-Request packets. 512 All attributes added by a RADIUS proxy when sending packets from the 513 Visited Network to the Home Network Network MUST be removed by the 514 corresponding CoA proxy from packets which travel the reverse path. 515 That is, any attribute editing which is done on the "forward" path 516 MUST be undone on the "reverse" path. 518 The result is that a NAS will only ever receive CoA packets which 519 either contain attributes sent by the NAS to it's local RADIUS 520 server, or contain attributes which are sent by the Home Server in 521 order to perform a change of authorization. 523 We note that the above requirement applies not only to Operator-Name 524 and Operator-NAS-Identifier, but also to any future attributes which 525 are added by a RADIUS proxy. 527 5. Functionality 529 This section describes how the two attributes work together to permit 530 CoA proxying. 532 5.1. User Login 534 In this scenario, we follow a roaming user attempting authentication 535 in a Visited Network. The login attempt is done via a NAS in the 536 Visited Network. That NAS will send an Access-Request packet to the 537 visited RADIUS server. The visited RADIUS server will see that the 538 user is roaming, and xwill add an Operator-Name attribute, with value 539 "1" followed by it's own realm name. e.g. "1example.com". The 540 visited RADIUS server MAY also add an Operator-NAS-Identifier. 542 The visited RADIUS server will then proxy the authentication request 543 to an upstream server. That server may be the Home Server, or it may 544 be a proxy. In the case of a proxy, the proxy will forward the 545 packet, until the packet reaches the Home Server. 547 The Home Server will record both Operator-Name and Operator-NAS- 548 Identfier along with other information about the users session. 550 5.2. CoA Proxing 552 When the Home Server determines that a user should be disconnecte, it 553 looks up the Operator-Name and Operator-NAS-Identifer, along with 554 other user session identifiers as described in [RFC5176]. The Home 555 Server then looks up the realm from the Operator-Name attribute in 556 the logical AAA routing table, in order to find the CoA server for 557 that realm (which may be a proxy). The Disconnect-Request is then 558 sent to that CoA server. 560 The CoA server receives the request, and if it is a proxy, performs a 561 similar lookup as done by the Home Server. The packet is then 562 proxied repeatedly until it reaches the Visited Network. 564 If the proxy cannot find a destination for the request, or if no 565 Operator-Name attribute exists in the request, the proxy will return 566 a CoA-NAK with Error-Cause 502 (Request Not Routable). 568 The Visited Network will recieve the CoA-Request packet, and will use 569 the Operator-NAS-Identifier (if available) attribute to determine 570 which local CoA server (i.e. NAS) the packet should be sent to. If 571 there is no Opertor-NAS-Identifier attribute, the Visited Network may 572 use other means to locate the NAS, such as consulting a local 573 database which tracks user sessions. 575 The Operator-Name and Operator-NAS-Identifer attributes are then 576 removed fromt he packet, and it is then sent to the CoA server. 578 If no CoA server can be found, the Visited Network return a CoA-NAK 579 with Error-Cause 403 (NAS Identification Mismatch). 581 Any response from the CoA server (NAS) is returned to the Home 582 Network, via the normal method of returning responses to requests. 584 6. Security Considerations 586 This specification incorporates by reference the [RFC6929] Section 587 11. In short, RADIUS has many known issues which are discussed in 588 detail there, and which do not need to be repeated here. 590 This specification adds one new attribute, and defines new behavior 591 for RADIUS proxying. As this behavior mirrors existing RADIUS 592 proxying, we do not believe that it introduces any new security 593 issues. 595 The Operator-NAS-Identifier SHOULD be created by the Visited Network 596 such that its contents are opaque to all other parties. This ensures 597 that anyone observing unencrypted RADIUS traffic gains no information 598 about the internals of the Visited Network. 600 7. IANA Considerations 602 IANA is instructed to allocated one new RADIUS attribute, as per 603 Section 3.3, above. 605 8. References 607 8.1. Normative References 609 [RFC2119] 610 Bradner, S., "Key words for use in RFCs to Indicate Requirement 611 Levels", RFC 2119, March, 1997. 613 [RFC2865] 614 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 615 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 617 [RFC5580] 618 Tschofenig H., Ed. "Carrying Location Objects in RADIUS and 619 Diameter", RFC 5580, August 2009. 621 [RFC6929] 622 DeKok A. and Lior, A., "Remote Authentication Dial-In User Service 623 (RADIUS) Protocol Extensions", RFC 6929, April 2013. 625 [RFC7542] 626 DeKok A., "The Network Access Identifier", RFC 7542, May 2015. 628 [RFC8044] 629 DeKok A., "Data Types in the Remote Authentication Dial-In User 630 Service Protocol (RADIUS)", RFC 8044, January 2017. 632 8.2. Informative References 634 [RFC2866] 635 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 637 [RFC5176] 638 Chiba, M. et al, "Dynamic Authorization Extensions to Remote 639 Authentication Dial In User Service (RADIUS)", RFC 5176, January 640 2008. 642 Authors' Addresses 644 Alan DeKok 645 The FreeRADIUS Server Project 647 Email: aland@freeradius.org 649 Jouni Korhonen 650 Broadcom 651 Porkkalankatu 24 652 FIN-00180 Helsinki 653 Finland 655 EMail: jouni.nospam@gmail.com