draft-ietf-radext-coa-proxy-07.txt   draft-ietf-radext-coa-proxy-08.txt 
Network Working Group DeKok, Alan Network Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Updates: 5176 J. Korhonen Updates: 5176, 5580 J. Korhonen
Category: Standards Track Category: Standards Track
<draft-ietf-radext-coa-proxy-07.txt> <draft-ietf-radext-coa-proxy-08.txt>
16 August 2018 22 January 2019
Dynamic Authorization Proxying in Dynamic Authorization Proxying in
Remote Authorization Dial-In User Service Protocol (RADIUS) Remote Authorization Dial-In User Service Protocol (RADIUS)
draft-ietf-radext-coa-proxy-07.txt draft-ietf-radext-coa-proxy-08.txt
Abstract Abstract
RFC 5176 defines Change of Authorization (CoA) and Disconnect Message RFC 5176 defines Change of Authorization (CoA) and Disconnect Message
(DM) behavior for RADIUS. That document suggests that proxying these (DM) behavior for RADIUS. That document suggests that proxying these
messages is possible, but gives no guidance as to how it is done. messages is possible, but gives no guidance as to how it is done.
This specification updates RFC 5176 to correct that omission for This specification updates RFC 5176 to correct that omission for
scenarios where networks use Realm-based proxying as defined in RFC scenarios where networks use Realm-based proxying as defined in RFC
7542. 7542. This specification also updates RFC 5580 to allow the
Operator-Name attribute in CoA-Request and Disconnect-Request
packets.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 16, 2019. This Internet-Draft will expire on July 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 5
2. Problem Statement ........................................ 6 2. Problem Statement ........................................ 6
2.1. Typical RADIUS Proxying ............................. 6 2.1. Typical RADIUS Proxying ............................. 6
2.2. CoA Processing ...................................... 7 2.2. CoA Processing ...................................... 7
2.3. Failure of CoA Proxying ............................. 7 2.3. Failure of CoA Proxying ............................. 7
3. How to Perform CoA Proxying .............................. 8 3. How to Perform CoA Proxying .............................. 8
3.1. Changes to Access-Request and Accounting-Request pack 8 3.1. Changes to Access-Request and Accounting-Request pack 8
3.2. Proxying of CoA-Request and Disconnect-Request packet 9 3.2. Proxying of CoA-Request and Disconnect-Request packet 9
3.3. Reception of CoA-Request and Disconnect-Request packe 10 3.3. Reception of CoA-Request and Disconnect-Request packe 10
3.4. Operator-NAS-Identifier ............................. 11 3.4. Operator-NAS-Identifier ............................. 11
4. Requirements ............................................. 13 4. Requirements ............................................. 14
4.1. Requirements on Home Servers ........................ 14 4.1. Requirements on Home Servers ........................ 14
4.2. Requirements on Visited Networks .................... 14 4.2. Requirements on Visited Networks .................... 14
4.3. Requirements on Proxies ............................. 14 4.3. Requirements on Proxies ............................. 14
4.3.1. Security Requirements on Proxies ............... 15 4.3.1. Security Requirements on Proxies ............... 15
4.3.2. Filtering Requirements on Proxies .............. 16 4.3.2. Filtering Requirements on Proxies .............. 16
5. Functionality ............................................ 17 5. Functionality ............................................ 17
5.1. User Login .......................................... 17 5.1. User Login .......................................... 17
5.2. CoA Proxying ........................................ 17 5.2. CoA Proxying ........................................ 17
6. Security Considerations .................................. 18 6. Security Considerations .................................. 18
6.1. RADIUS Security and Proxies ......................... 18 6.1. RADIUS Security and Proxies ......................... 18
skipping to change at page 4, line 24 skipping to change at page 4, line 24
of these packets can be done by leveraging an existing RADIUS of these packets can be done by leveraging an existing RADIUS
attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain
how this attribute can be used by proxies to route packets how this attribute can be used by proxies to route packets
"backwards" through a RADIUS proxy chain from a Home Network to a "backwards" through a RADIUS proxy chain from a Home Network to a
Visited Network. We then introduce a new attribute; Operator-NAS- Visited Network. We then introduce a new attribute; Operator-NAS-
Identifier. This attribute permits packets to be routed from the Identifier. This attribute permits packets to be routed from the
RADIUS server at the Visited Network to the NAS. RADIUS server at the Visited Network to the NAS.
This correction is limited to the use-case of Realm-based proxying as This correction is limited to the use-case of Realm-based proxying as
defined in [RFC7542]. Other forms of proxying are possible, but are defined in [RFC7542]. Other forms of proxying are possible, but are
not discussed here. not discussed here. We note that the recommendations of this
document apply only to those systems which implement proxying of CoA
packets, and then only to those that implement Realm-based CoA
proxying. This specification neither requires nor suggests changes
to any implementation or deployment of any other RADIUS systems.
We conclude with a discussion of the security implications of the We also update the behavior of [RFC5580] to allow the Operator-Name
design, and show that they do not decrease the security of the attribute to be used in CoA-Request and Disconnect-Request packets,
as further described in this document.
This document is a Proposed Standard in order to update the behavior
of [RFC5580], which is also a Proposed Standard. This document
relies heavily upon and also updates some behavior of RFC 5176, which
is an Informational document; though the applicability statements in
Section 1.1 of [RFC5176] do not apply to this document, this document
does not change the status of [RFC5176].
We finally conclude with a discussion of the security implications of
this design, and show that they do not decrease the security of the
network. network.
1.1. Terminology 1.1. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
CoA CoA
Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK, Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK,
as defined in [RFC5176]. That specification also defines as defined in [RFC5176]. That specification also defines
skipping to change at page 8, line 49 skipping to change at page 8, line 49
The remainder of this document describes how CoA proxying can be The remainder of this document describes how CoA proxying can be
performed by using the Operator-Name attribute. We describe how the performed by using the Operator-Name attribute. We describe how the
forward path has to change in order to allow reverse path proxying. forward path has to change in order to allow reverse path proxying.
We then describe how reverse path proxying works. And we describe We then describe how reverse path proxying works. And we describe
how Visited Networks and Home Networks have to behave in order for how Visited Networks and Home Networks have to behave in order for
CoA proxying to work. CoA proxying to work.
3.1. Changes to Access-Request and Accounting-Request packets 3.1. Changes to Access-Request and Accounting-Request packets
When a Visited Network proxies an Access-Request or Accounting- When a Visited Network proxies an Access-Request or Accounting-
Request packet outside of its network, the Visited Network SHOULD Request packet outside of its network, a Visited Network that wishes
include an Operator-Name attribute in the packet, as discussed in to support Realm-based CoA proxying SHOULD include an Operator-Name
Section 4.1 of [RFC5580]. The contents of the Operator-Name should attribute in the packet, as discussed in Section 4.1 of [RFC5580].
be "1", followed by the realm name of the Visited Network. Where the The contents of the Operator-Name should be "1", followed by the
Visited Network has more than one realm name, a "canonical" one realm name of the Visited Network. Where the Visited Network has
SHOULD be chosen, and used for all packets. more than one realm name, a "canonical" one SHOULD be chosen, and
used for all packets.
Visited Networks MUST use a consistent value for Operator-Name for Visited Networks MUST use a consistent value for Operator-Name for
any one user session. That is, sending "1example.com" in an Access- any one user session. That is, sending "1example.com" in an Access-
Request packet, and "1example.org" in an Accounting-Request packet Request packet, and "1example.org" in an Accounting-Request packet
for that same session is forbidden. Such behavior would make it look for that same session is forbidden. Such behavior would make it look
like a single user session was active simultaneously in two different like a single user session was active simultaneously in two different
Visited Networks, which is impossible. Visited Networks, which is impossible.
Proxies that record user session information SHOULD also record Proxies that record user session information SHOULD also record
Operator-Name. Proxies that do not record user session information Operator-Name. Proxies that do not record user session information
skipping to change at page 11, line 50 skipping to change at page 12, line 4
The Operator-NAS-Identifier attribute is an opaque token that The Operator-NAS-Identifier attribute is an opaque token that
identifies an individual NAS in a Visited Network. It MAY appear in identifies an individual NAS in a Visited Network. It MAY appear in
the following packets: Access-Request, Accounting-Request, CoA- the following packets: Access-Request, Accounting-Request, CoA-
Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT
appear in any other packet. appear in any other packet.
Operator-NAS-Identifier MAY occur in a packet if the packet also Operator-NAS-Identifier MAY occur in a packet if the packet also
contains an Operator-Name attribute. Operator-NAS-Identifier MUST contains an Operator-Name attribute. Operator-NAS-Identifier MUST
NOT appear in a packet if there is no Operator-Name in the packet. NOT appear in a packet if there is no Operator-Name in the packet.
Operator-NAS-Identifier MUST NOT occur more than once in a packet. Operator-NAS-Identifier MUST NOT occur more than once in a packet.
If a packet contains more than one Operator-NAS-Identifier, If a packet contains more than one Operator-NAS-Identifier,
implementations MUST ignore the second and subsequent attributes, and implementations MUST treat the second and subsequent attributes as
treat them as "invalid attributes", as discussed in Section 2.8 of "invalid attributes", as discussed in Section 2.8 of [RFC6929].
[RFC6929]. Since packets can be proxied only to one destination, there is no
reason to have multiple Operator-Realm attributes in a packet.
An Operator-NAS-Identifer attribute SHOULD be added to an Access- An Operator-NAS-Identifer attribute SHOULD be added to an Access-
Request or Accounting-Request packet by a Visited Network, before Request or Accounting-Request packet by a Visited Network, before
proxying a packet to an external RADIUS server. When the Operator- proxying a packet to an external RADIUS server. When the Operator-
NAS-Identifer attribute is added to a packet, the following NAS-Identifer attribute is added to a packet, the following
attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- attributes SHOULD be deleted from the packet: NAS-IP-Address, NAS-
Identifier. The proxy MUST then add a NAS-Identifier attribute, in IPv6-Address, NAS-Identifier. If these attributes are deleted, the
order satisfy the requirements of Section 4.1 of [RFC2865], and proxy MUST then add a NAS-Identifier attribute, in order satisfy the
Section 4.1 of [RFC2866]. The contents of the NAS-Identifier SHOULD requirements of Section 4.1 of [RFC2865], and Section 4.1 of
be the Realm name of the visited network. [RFC2866]. The contents of the new NAS-Identifier SHOULD be the
Realm name of the visited network.
When a server receives a packet that already contains an Operator- When a server receives a packet that already contains an Operator-
NAS-Identifer attribute, no such editing is performed. NAS-Identifer attribute, no such editing is performed.
The Operator-NAS-Attribute MUST NOT be added to any packet by any The Operator-NAS-Attribute MUST NOT be added to any packet by any
other proxy or server in the network. Only the Visited Network (i.e. other proxy or server in the network. Only the Visited Network (i.e.
the operator) can name a NAS which is inside of the Visited Network. the operator) can name a NAS which is inside of the Visited Network.
The result of these requirements is that for everyone outside of the The result of these requirements is that for everyone outside of the
Visited Network, there is only one NAS: the Visited Network itself. Visited Network, there is only one NAS: the Visited Network itself.
skipping to change at page 14, line 37 skipping to change at page 14, line 40
attribute to determine which NAS will receive the packet. attribute to determine which NAS will receive the packet.
The Visited Network MUST remove the Operator-Name and Operator-NAS- The Visited Network MUST remove the Operator-Name and Operator-NAS-
Identifier attributes from any CoA packet packet prior to sending Identifier attributes from any CoA packet packet prior to sending
that packet to the final CoA server (i.e. NAS). This step is that packet to the final CoA server (i.e. NAS). This step is
necessary due to the the limits of Section 2.3 of [RFC5176]. necessary due to the the limits of Section 2.3 of [RFC5176].
The Visited Network MUST also ensure that the CoA packet sent to the The Visited Network MUST also ensure that the CoA packet sent to the
NAS contains one of the following attributes: NAS-IP-Address, NAS- NAS contains one of the following attributes: NAS-IP-Address, NAS-
IPv6-Address, or NAS-Identifier. This step is the inverse of the IPv6-Address, or NAS-Identifier. This step is the inverse of the
removal required above in Section 3.4. removal suggested above in Section 3.4.
In general, the NAS should only receive attributes which identify or In general, the NAS should only receive attributes which identify or
modify a user's session. It is not appropriate to send a NAS modify a user's session. It is not appropriate to send a NAS
attributes which are used only for inter-proxy signaling. attributes which are used only for inter-proxy signaling.
4.3. Requirements on Proxies 4.3. Requirements on Proxies
There are a number of requirements on proxies, both CoA proxies and There are a number of requirements on proxies, both CoA proxies and
RADIUS proxies. For the purpose of this section, we assume that each RADIUS proxies. For the purpose of this section, we assume that each
RADIUS proxy shares a common administration with a corresponding CoA RADIUS proxy shares a common administration with a corresponding CoA
 End of changes. 14 change blocks. 
27 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/