draft-ietf-radext-coa-proxy-00.txt   draft-ietf-radext-coa-proxy-01.txt 
Network Working Group DeKok, Alan Network Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Updates: 5176 J. Korhonen Updates: 5176 J. Korhonen
Category: Standards Track Nokia Siemens Networks Category: Standards Track Nokia Siemens Networks
<draft-ietf-radext-coa-proxy-00.txt> <draft-ietf-radext-coa-proxy-01.txt>
11 January 2016 8 July 2016
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-00.txt draft-ietf-radext-coa-proxy-01.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. Section 3.1 of that document suggests that (DM) behavior for RADIUS. Section 3.1 of that document suggests that
proxying these messages is possible, but gives no guidance as to how proxying these messages is possible, but gives no guidance as to how
that is done. This specification corrects that omission. that is done. This specification corrects that omission.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 June 11, 2016. This Internet-Draft will expire on February 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2. Problem Statement ........................................ 6 2. Problem Statement ........................................ 6
2.1. Typical RADIUS Proxying ............................. 6 2.1. Typical RADIUS Proxying ............................. 6
2.2. CoA Processing ...................................... 6 2.2. CoA Processing ...................................... 6
2.3. Failure of CoA Proxying ............................. 7 2.3. Failure of CoA Proxying ............................. 7
3. How to Perform CoA Proxying .............................. 7 3. How to Perform CoA Proxying .............................. 7
3.1. Operator-Name in Access-Request and Accounting-Reques 8 3.1. Operator-Name in Access-Request and Accounting-Reques 8
3.2. Operator-Name in CoA-Request and Disconnect-Request p 8 3.2. Operator-Name in CoA-Request and Disconnect-Request p 8
3.3. Operator-NAS-Identifier ............................. 9 3.3. Operator-NAS-Identifier ............................. 9
4. Requirements ............................................. 10 4. Requirements ............................................. 10
4.1. Requirements on Home Servers ........................ 10 4.1. Requirements on Home Servers ........................ 10
4.2. Requirements on Proxies ............................. 11 4.2. Requirements on Visited Networks .................... 11
4.3. Requirements on Visited Networks .................... 12 4.3. Requirements on Proxies ............................. 11
4.3.1. Security Requirements on Proxies ............... 11
4.3.2. Filtering Requirements on Proxies .............. 12
5. Functionality ............................................ 13 5. Functionality ............................................ 13
5.1. User Login .......................................... 13 5.1. User Login .......................................... 13
5.2. CoA Proxing ......................................... 13 5.2. CoA Proxing ......................................... 13
6. Security Considerations .................................. 14 6. Security Considerations .................................. 14
7. IANA Considerations ...................................... 14 7. IANA Considerations ...................................... 14
8. References ............................................... 14 8. References ............................................... 14
8.1. Normative References ................................ 14 8.1. Normative References ................................ 14
8.2. Informative References .............................. 15 8.2. Informative References .............................. 15
1. Introduction 1. Introduction
skipping to change at page 9, line 50 skipping to change at page 9, line 50
Request or Accounting-Request packet by a Visited Network just before Request or Accounting-Request packet by a Visited Network just 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 MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS-
Identifier. The proxy MUST then add a NAS-Identifier attribute, in Identifier. The proxy MUST then add a NAS-Identifier attribute, in
order satisfy the requirements of Section 4.1 of [RFC2865], and of order satisfy the requirements of Section 4.1 of [RFC2865], and of
[RFC2866]. [RFC2866].
We suggest that the contents of the NAS-Identifier be the Realm name We suggest that the contents of the NAS-Identifier be the Realm name
of the Visited Network. That is, for everyone outside of the Visited of the Visited Network. That is, for everyone outside of the Visited
Network, the identity NAS is the Visited Network. For the Visited Network, the identity of the NAS is the Visited Network. For the
Network, the identity of the NAS is private information, which is Visited Network, the identity of the NAS is private information,
opaque to everyone else. which is opaque to everyone else.
Description Description
An opaque token describing the NAS a user has logged into. An opaque token describing the NAS a user has logged into.
Type Type
TBD. To be assigned by IANA TBD. To be assigned by IANA
Length Length
skipping to change at page 11, line 5 skipping to change at page 11, line 5
A Home Server MUST NOT send CoA packets for users who are not part of A Home Server MUST NOT send CoA packets for users who are not part of
its realm. The provisions of the next few sections describe how its realm. The provisions of the next few sections describe how
other participants in the RADIUS ecosystem can enforce this other participants in the RADIUS ecosystem can enforce this
requirement. requirement.
The Operator-NAS-Identifier attribute MUST be stored by a Home Server The Operator-NAS-Identifier attribute MUST be stored by a Home Server
along with any user session identification attributes. When sending along with any user session identification attributes. When sending
a CoA packet for a user session, the Home Server MUST include any a CoA packet for a user session, the Home Server MUST include any
Operator-NAS-Identifier it has recorded for that session. Operator-NAS-Identifier it has recorded for that session.
4.2. Requirements on Proxies 4.2. Requirements on Visited Networks
Section 6.1 of [RFC5176] says: A Visited Network which receives a proxied CoA packet MUST perform
all of the checks discussed above for proxies. This requirement is
because we assume that the Visited Network has a proxy in between the
NAS and any external (i.e. third-party) proxy. Situations where a
NAS sends packets directly to a third-party RADIUS server are outside
of the scope of this specification.
... a proxy MAY perform a "reverse Due to the requirements of Section 2.3 of [RFC5176], a Visited
path forwarding" (RPF) check to verify that a Disconnect-Request Network MUST remove Operator-Name and Operator-NAS-Identifier from
or any CoA-Request or Disconnect-Request packet prior to proxying that
packet to a CoA server. This requirement is phrase more generically
below, in Section XX.
While a Visited Network may create an Operator-NAS-Identifier via
many methods. The value SHOULD be cryptographically strong. It
SHOULD be verifiable by the Visited Network, without tracking every
single user session.
4.3. Requirements on Proxies
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 proxy shares a common administration with a corresponding CoA
proxy, and that the two systems can communicate electronically.
There is no requirement that these systems are co-located.
4.3.1. Security Requirements on Proxies
Section 6.1 of [RFC5176] has some security requirements on proxies
which handle CoA-Request and Disconnect-Request packets:
... a proxy MAY perform a "reverse path
forwarding" (RPF) check to verify that a Disconnect-Request or
CoA-Request originates from an authorized Dynamic Authorization CoA-Request originates from an authorized Dynamic Authorization
Client. Client.
We change that requirement to a proxy MUST perform a "reverse path We change that requirement to a proxy MUST perform a "reverse path
forwarding" (RPF) check to verify that a Disconnect-Request or CoA- forwarding" (RPF) check to verify that a Disconnect-Request or CoA-
Request originates from an authorized Dynamic Authorization Client. Request originates from an authorized Dynamic Authorization Client.
Without this change, a proxy may forward forged packets, and thus Without this change, a proxy may forward forged packets, and thus
contribute to the forgery problem instead of preventing it. contribute to the forgery problem instead of preventing it.
Proxies which record user session information MAY verify the contents Proxies which record user session information SHOULD verify the
of the CoA packet against any recorded user session data. If the contents of a received CoA packet against the recorded data for that
proxy determines that the information in the packet does not match user session. If the proxy determines that the information in the
the recorded user session, it SHOULD return a CoA-NAK or Disconnect- packet does not match the recorded user session, it SHOULD return a
NAK packet, which contains an Error-Cause attribute having value 503 CoA-NAK or Disconnect-NAK packet, which contains an Error-Cause
("Session Context Not Found"). attribute having value 503 ("Session Context Not Found").
Section 2.3 of [RFC5176] makes the following requirement for CoA
servers:
In CoA-Request and Disconnect-Request packets, all attributes
MUST
be treated as mandatory.
These requirements are too stringent for a CoA proxy. Instead, we
say that for a CoA proxy, all attributes MUST NOT be treated as
mandatory. Proxies SHOULD perform proxying based on Operator-Name,
but other schemes are possible (though not discussed here). Proxies
SHOULD forward all packets as-is, with minimal changes. Only the
final CoA server (i.e RADIUS NAS) is definitive on which attributes
are mandatory, and which are not.
Proxies MUST pass any Operator-Realm and Operator-NAS-Identifier
attributes through unchanged.
In short, proxies SHOULD behave much like a CoA server, and where
possible, perform many of the same validations done by a CoA server.
We recognize that because a proxy will see Access-Request and We recognize that because a RADIUS proxy will see Access-Request and
Accounting-Request packets, that it will have sufficient information Accounting-Request packets, that it will have sufficient information
to forge CoA packets. It will thus have the ability to subsequently to forge CoA packets. It will thus have the ability to subsequently
disconnect any user who was authenticated via the proxy. disconnect any user who was authenticated via the RADIUS proxy.
We suggest that the real-world effect of this security problem is We suggest that the real-world effect of this security problem is
minimal. Proxies can already return Access-Accept or Access-Reject minimal. RADIUS proxies can already return Access-Accept or Access-
for Access-Request packets, and can change authorization attributes Reject for Access-Request packets, and can change authorization
contained in an Access-Accept. Allowing a proxy to change (or attributes contained in an Access-Accept. Allowing a proxy to change
disconnect) a user session post-authentication is not substantiall (or disconnect) a user session post-authentication is not
different from changing (or refusing to connect) a user session substantiall different from changing (or refusing to connect) a user
during the initial process of authentiction. session during the initial process of authentiction.
There are no provisions in RADIUS for "end to end" security. That There are no provisions in RADIUS for "end to end" security. That
is, the Visited Network and Home Network cannot communicate privately is, the Visited Network and Home Network cannot communicate privately
in the presence of proxies. This limitation originates from the in the presence of proxies. This limitation originates from the
design of RADIUS for Access-Request and Accounting-Request packets. design of RADIUS for Access-Request and Accounting-Request packets.
That limitation is then carried over to CoA-Request and Disconnect- That limitation is then carried over to CoA-Request and Disconnect-
Request packets. Request packets.
We cannot therefore prevent proxies or Home Servers from forging CoA We cannot therefore prevent proxies or Home Servers from forging CoA
packets. We can only create scenarios where that forgery is hard to packets. We can only create scenarios where that forgery is hard to
perform, and/or is likely to be detected. perform, and/or is likely to be detected.
4.3. Requirements on Visited Networks 4.3.2. Filtering Requirements on Proxies
A Visited Network which receives a proxied CoA packet MUST perform Section 2.3 of [RFC5176] makes the following requirement for CoA
all of the checks discussed above for proxies. This requirement is servers:
because we assume that the Visited Network has a proxy in between the
NAS and any external (i.e. third-party) proxy. Situations where a
NAS sends packets directly to a third-party RADIUS server are outside
of the scope of this specification.
Due to the requirements of Section 2.3 of [RFC5176], a Visited In CoA-Request and Disconnect-Request packets, all attributes
Netowkr MUST remove Operator-Name and Operator-NAS-Identifier from MUST be treated as mandatory.
any CoA-Request or Disconnect-Request packet prior to proxying that
packet to a CoA server.
That is, all attributes added to outbound packets by the Visited These requirements are too stringent for a CoA proxy. Instead, we
Network MUST be removed from inbound packets before sending those say that for a CoA proxy, all attributes MUST NOT be treated as
packets to the NAS. mandatory. Proxies SHOULD perform proxying based on Operator-Name,
but other schemes are possible (though not discussed here). Proxies
SHOULD forward all packets as-is, with minimal changes. Only the
final CoA server (i.e RADIUS NAS) can make a decision on which
attributes are mandatory and which are not.
Where Operator-Realm and Operator-NAS-Identifier is received by a
proxy, the proxy MUST pass those attributes through unchanged.
All attributes added by a RADIUS proxy when sending packets from the
Visited Network to the Home Network Network MUST be removed by the
corresponding CoA proxy from packets which travel the reverse path.
The result is that a NAS will only ever receive CoA packets which
contain either attributes sent by the NAS to the RADIUS server, or
attributes which are required to perform a change of authorization.
We note that the above requirement applies not only to Operator-Name We note that the above requirement applies not only to Operator-Name
and Operator-NAS-Identifier, but also to any future attributes which and Operator-NAS-Identifier, but also to any future attributes which
are added by the Visited Network. are added by a RADIUS proxy.
When a Visited Network may create an Operator-Name via many methods. In short, proxies SHOULD behave much like a CoA server, and where
The value SHOULD be cryptographically strong. It SHOULD be possible, perform many of the same validations done by a CoA server.
verifiable by the Visited Network, without tracking every single user
session.
5. Functionality 5. Functionality
This section describes how the two attributes work together to permit This section describes how the two attributes work together to permit
CoA proxying. CoA proxying.
5.1. User Login 5.1. User Login
In this scenario, we follow a roaming user attempting authenticastion In this scenario, we follow a roaming user attempting authenticastion
in a visited network. The login attempt is done via a visited NAS. in a visited network. The login attempt is done via a visited NAS.
 End of changes. 18 change blocks. 
68 lines changed or deleted 83 lines changed or added

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