draft-ietf-radext-coa-proxy-02.txt   draft-ietf-radext-coa-proxy-03.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-02.txt> <draft-ietf-radext-coa-proxy-03.txt>
29 November 2017 6 April 2018
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-01.txt draft-ietf-radext-coa-proxy-03.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 for
scenarios where networks use Realm-based proxying as defined in
[RFC7542].
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 42 skipping to change at page 1, line 44
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 May 29, 2018. This Internet-Draft will expire on October 10, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 21 skipping to change at page 3, line 21
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. 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 8 3.2. Proxying of CoA-Request and Disconnect-Request packet 8
3.3. Operator-NAS-Identifier ............................. 9 3.3. Operator-NAS-Identifier ............................. 9
4. Requirements ............................................. 11 4. Requirements ............................................. 11
4.1. Requirements on Home Servers ........................ 11 4.1. Requirements on Home Servers ........................ 11
4.2. Requirements on Visited Networks .................... 11 4.2. Requirements on Visited Networks .................... 11
4.3. Requirements on Proxies ............................. 11 4.3. Requirements on Proxies ............................. 12
4.3.1. Security Requirements on Proxies ............... 12 4.3.1. Security Requirements on Proxies ............... 12
4.3.2. Filtering Requirements on Proxies .............. 13 4.3.2. Filtering Requirements on Proxies .............. 13
5. Functionality ............................................ 13 5. Functionality ............................................ 14
5.1. User Login .......................................... 13 5.1. User Login .......................................... 14
5.2. CoA Proxing ......................................... 14 5.2. CoA Proxing ......................................... 14
6. Security Considerations .................................. 15 6. Security Considerations .................................. 15
7. IANA Considerations ...................................... 15 7. IANA Considerations ...................................... 15
8. References ............................................... 15 8. References ............................................... 15
8.1. Normative References ................................ 15 8.1. Normative References ................................ 15
8.2. Informative References .............................. 16 8.2. Informative References .............................. 16
1. Introduction 1. Introduction
RFC 5176 [RFC5176] defines Change of Authorization (CoA) and RFC 5176 [RFC5176] defines Change of Authorization (CoA) and
skipping to change at page 9, line 5 skipping to change at page 9, line 5
3.2. Proxying of CoA-Request and Disconnect-Request packets 3.2. Proxying of CoA-Request and Disconnect-Request packets
When a Home Network wishes to send a CoA-Request or Disconnect- When a Home Network wishes to send a CoA-Request or Disconnect-
Request packet to a Visited Network, it MUST include an Operator-Name Request packet to a Visited Network, it MUST include an Operator-Name
attribute in the packet. The value of the Operator-Name MUST be the attribute in the packet. The value of the Operator-Name MUST be the
value which was recorded earlier for that user session. value which was recorded earlier for that user session.
The Home Network MUST lookup the realm from the Operator-Name in a The Home Network MUST lookup the realm from the Operator-Name in a
logical "realm routing table", as discussed in [RFC7542] Section 3. logical "realm routing table", as discussed in [RFC7542] Section 3.
In this case, the destination of the packet is not a RADIUS server, That logical realm table is defined there as:
but a CoA server.
a logical AAA routing table, where the "utf8-realm" portion
acts as a key, and the values stored in the table are one or more
"next hop" AAA servers.
In order to support proxying of CoA packets, this table is extended
to include a mapping between "utf8-realm" and one ore more "next hop"
CoA servers.
When proxying CoA-Request and Disconnect-Request packets, the lookups
will return data from the "CoA server" field, instead of the "AAA
server" field.
In practice, this process means that CoA proxying works exactly like In practice, this process means that CoA proxying works exactly like
"normal" RADIUS proxying, except that the proxy decision is made "normal" RADIUS proxying, except that the proxy decision is made
using the realm from the Operator-Name attribute, instead of using using the realm from the Operator-Name attribute, instead of using
the realm from the User-Name attribute. the realm from the User-Name attribute.
Proxies which receive the CoA packet MUST look up the realm from the Proxies which receive the CoA packet MUST look up the realm from the
Operator-Name in a logical "realm routing table", as with Home Operator-Name in a logical "realm routing table", as with Home
Servers, above. The packet is then sent to the realm which was found Servers, above. The packet is then sent to the realm which was found
in that table. This process continues with any subsequent proxies in that table. This process continues with any subsequent proxies
skipping to change at page 10, line 23 skipping to change at page 10, line 34
Network, there is only one NAS: the Visited Network itself. For the Network, there is only one NAS: the Visited Network itself. For the
Visited Network, the identity of the NAS is private information, Visited Network, the identity of the NAS is private information,
which is 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 from the "short extended space".
Length Length
TBD. Depends on IANA allocation. 4 to 23.
Implementations supporting this attribute MUST be able to handle Implementations supporting this attribute MUST be able to handle
between one (1) and twenty (20) octets of data. Implementations between one (1) and twenty (20) octets of data. Implementations
creating an Operator-NAS-Identifier SHOULD NOT create attributes creating an Operator-NAS-Identifier MUST NOT create attributes
with more than twenty octets of data. A twenty octet string is with more than twenty octets of data. A twenty octet string is
more than sufficient to individually address all of the NASes on more than sufficient to individually address all of the NASes on
the planet. the planet.
Data Type Data Type
string. See [RFC8044] Section 3.6 for a definition. string. See [RFC8044] Section 3.6 for a definition.
Value Value
The contents of this attribute are an opaque token interpretable The contents of this attribute are an opaque token interpretable
only by the Visited Network. only by the Visited Network.
This token MUST allow the Visited Network to direct the packet to This token MUST allow the Visited Network to direct the packet to
the NAS for the users session. In practice, this requirement the NAS for the users session. In practice, this requirement
means that the Visited Network will either track these tokens in a means that the Visited Network will either track these tokens in a
database, or it will create tokens which can be decoded in order database, or it will create tokens which can be decoded in order
to reveal the identity of the NAS. to reveal the identity of the NAS.
4. Requirements 4. Requirements
skipping to change at page 15, line 23 skipping to change at page 15, line 32
proxying, we do not believe that it introduces any new security proxying, we do not believe that it introduces any new security
issues. issues.
The Operator-NAS-Identifier SHOULD be created by the Visited Network The Operator-NAS-Identifier SHOULD be created by the Visited Network
such that its contents are opaque to all other parties. This ensures such that its contents are opaque to all other parties. This ensures
that anyone observing unencrypted RADIUS traffic gains no information that anyone observing unencrypted RADIUS traffic gains no information
about the internals of the Visited Network. about the internals of the Visited Network.
7. IANA Considerations 7. IANA Considerations
IANA is instructed to allocated one new RADIUS attribute, as per IANA is instructed to allocate one new RADIUS attribute, as per
Section 3.3, above. Section 3.3, above.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997. Levels", RFC 2119, March, 1997.
 End of changes. 13 change blocks. 
16 lines changed or deleted 28 lines changed or added

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