draft-ietf-radext-radius-fragmentation-09.txt   draft-ietf-radext-radius-fragmentation-10.txt 
RADIUS EXTensions Working Group A. Perez-Mendez RADIUS EXTensions Working Group A. Perez-Mendez
Internet-Draft R. Marin-Lopez Internet-Draft R. Marin-Lopez
Updates: 2865, 6158, 6929 F. Pereniguez-Garcia Updates: 2865, 6158, 6929 F. Pereniguez-Garcia
(if approved) G. Lopez-Millan (if approved) G. Lopez-Millan
Intended status: Experimental University of Murcia Intended status: Experimental University of Murcia
Expires: June 13, 2015 D. Lopez Expires: July 13, 2015 D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
December 10, 2014 January 9, 2015
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-09 draft-ietf-radext-radius-fragmentation-10
Abstract Abstract
The Remote Authentication Dial-In User Service (RADIUS) protocol is The Remote Authentication Dial-In User Service (RADIUS) protocol is
limited to a total packet size of 4096 octets. Provisions exist for limited to a total packet size of 4096 octets. Provisions exist for
fragmenting large amounts of authentication data across multiple fragmenting large amounts of authentication data across multiple
packets, via Access-Challenge. No similar provisions exist for packets, via Access-Challenge. No similar provisions exist for
fragmenting large amounts of authorization data. This document fragmenting large amounts of authorization data. This document
specifies how existing RADIUS mechanisms can be leveraged to provide specifies how existing RADIUS mechanisms can be leveraged to provide
that functionality. These mechanisms are largely compatible with that functionality. These mechanisms are largely compatible with
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on June 13, 2015. This Internet-Draft will expire on July 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Status of this document . . . . . . . . . . . . . . . . . . . 5 2. Status of this document . . . . . . . . . . . . . . . . . . . 6
3. Scope of this document . . . . . . . . . . . . . . . . . . . . 6 3. Scope of this document . . . . . . . . . . . . . . . . . . . . 7
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 11 5. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 12
5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 12 5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 12
5.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 17 5.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 17
6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Allowed large packet size . . . . . . . . . . . . . . . . . . 20 7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21
8. Handling special attributes . . . . . . . . . . . . . . . . . 21 8. Handling special attributes . . . . . . . . . . . . . . . . . 22
8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 21 8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22
8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23 8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23
8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 23 8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24
8.4. Rebuilding the original large packet . . . . . . . . . . . 23 8.4. Rebuilding the original large packet . . . . . . . . . . . 24
9. New flag T field for the Long Extended Type attribute 9. New flag T field for the Long Extended Type attribute
definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24 definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. New attribute definition . . . . . . . . . . . . . . . . . . . 25 10. New attribute definition . . . . . . . . . . . . . . . . . . . 25
10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25 10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25
10.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 26 10.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 26
10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27 10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27
11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27 11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27
11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27
11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 27 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28
12. Operational considerations . . . . . . . . . . . . . . . . . . 29 12. General considerations . . . . . . . . . . . . . . . . . . . . 29
12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30
12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30
12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32
16.2. Informative References . . . . . . . . . . . . . . . . . . 33 16.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The RADIUS [RFC2865] protocol carries authentication, authorization, The RADIUS [RFC2865] protocol carries authentication, authorization,
and accounting information between a RADIUS Client and an RADIUS and accounting information between a RADIUS Client and an RADIUS
Server. Information is exchanged between them through RADIUS Server. Information is exchanged between them through RADIUS
packets. Each RADIUS packet is composed of a header, and zero or packets. Each RADIUS packet is composed of a header, and zero or
more attributes, up to a maximum packet size of 4096 octets. The more attributes, up to a maximum packet size of 4096 octets. The
protocol is a request/response protocol, as described in the protocol is a request/response protocol, as described in the
operational model ([RFC6158], Section 3.1). operational model ([RFC6158], Section 3.1).
The above packet size limitation mean that peers desiring to send The intention of the above packet size limitation was to avoid as
large amounts of data must fragment it across multiple packets. For much as possible UDP fragmentation. Back then, 4096 seemed large
example, RADIUS-EAP [RFC3579] defines how an EAP exchange occurs enough for any purpose. Now, new scenarios are emerging that require
across multiple Access-Request / Access-Challenge sequences. No such the exchange of authorization information exceeding this 4096 limit.
exchange is possible for accounting or authorization data. [RFC6158] For instance, the Application Bridging for Federated Access Beyond
Section 3.1 suggests that exchanging large amounts authorization data web (ABFAB) IETF WG defines the transport of Security Assertion
is unnecessary in RADIUS. Instead, the data should be referenced by Markup Language (SAML) sentences from the RADIUS server to the RADIUS
name. This requirement allows large policies to be pre-provisioned, client [I-D.ietf-abfab-aaa-saml]. This assertion is likely to be
and then referenced in an Access-Accept. In some cases, however, the larger than 4096 octets.
authorization data sent by the RADIUS Server is large and highly
dynamic. In other cases, the RADIUS Client needs to send large This means that peers desiring to send large amounts of data must
amounts of authorization data to the RADIUS Server. Both of these fragment it across multiple packets. For example, RADIUS-EAP
cases are un-met by the requirements in [RFC6158]. As noted in that [RFC3579] defines how an Extensible Authentication Protocol (EAP)
document, the practical limit on RADIUS packet sizes is governed by exchange occurs across multiple Access-Request / Access-Challenge
the Path MTU (PMTU), which may be significantly smaller than 4096 sequences. No such exchange is possible for accounting or
octets. The combination of the two limitations means that there is a authorization data. [RFC6158] Section 3.1 suggests that exchanging
pressing need for a method to send large amounts of authorization large amounts authorization data is unnecessary in RADIUS. Instead,
data between RADIUS Client and Server, with no accompanying solution. the data should be referenced by name. This requirement allows large
policies to be pre-provisioned, and then referenced in an Access-
Accept. In some cases, however, the authorization data sent by the
RADIUS Server is large and highly dynamic. In other cases, the
RADIUS Client needs to send large amounts of authorization data to
the RADIUS Server. Both of these cases are un-met by the
requirements in [RFC6158]. As noted in that document, the practical
limit on RADIUS packet sizes is governed by the Path MTU (PMTU),
which may be significantly smaller than 4096 octets. The combination
of the two limitations means that there is a pressing need for a
method to send large amounts of authorization data between RADIUS
Client and Server, with no accompanying solution.
[RFC6158] section 3.1 recommends three approaches for the [RFC6158] section 3.1 recommends three approaches for the
transmission of large amount of data within RADIUS. However, they transmission of large amount of data within RADIUS. However, they
are not applicable to the problem statement of this document for the are not applicable to the problem statement of this document for the
following reasons: following reasons:
o The first approach (utilization of a sequence of packets) does not o The first approach (utilization of a sequence of packets) does not
talk about large amounts of data sent from the RADIUS Client to a talk about large amounts of data sent from the RADIUS Client to a
RADIUS Server. Leveraging EAP (request/challenge) to send the RADIUS Server. Leveraging EAP (request/challenge) to send the
data is not feasible, as EAP already fills packet to PMTU, and not data is not feasible, as EAP already fills packet to PMTU, and not
all authentications use EAP. Moreover, as noted for NAS-Filter- all authentications use EAP. Moreover, as noted for NAS-Filter-
Rule ([RFC4849]), this approach does entirely solve the problem of Rule ([RFC4849]), this approach does not entirely solve the
sending large amounts of data from a RADIUS Server to a RADIUS problem of sending large amounts of data from a RADIUS Server to a
Client, as many current RADIUS attributes are not permitted in an RADIUS Client, as many current RADIUS attributes are not permitted
Access-Challenge packets. in an Access-Challenge packets.
o The second approach (utilization of names rather than values) is o The second approach (utilization of names rather than values) is
not usable either, as using names rather than values is difficult not usable either, as using names rather than values is difficult
when the nature of the data to be sent is highly dynamic (e.g. when the nature of the data to be sent is highly dynamic (e.g.
SAML statement or NAS-Filter-Rule attributes). URLs could be used SAML statement or NAS-Filter-Rule attributes). URLs could be used
as a pointer to the location of the actual data, but their use as a pointer to the location of the actual data, but their use
would require them to be (a) dynamically created and modified, (b) would require them to be (a) dynamically created and modified, (b)
securely accessed and (c) accessible from remote systems. securely accessed and (c) accessible from remote systems.
Satisfying these constraints would require the modification of Satisfying these constraints would require the modification of
several networking systems (e.g. firewalls and web servers). several networking systems (e.g. firewalls and web servers).
Furthermore, the set up of an additional trust infrastructure Furthermore, the setup of an additional trust infrastructure (e.g.
(e.g. PKI) would be required to allow secure retrieving of the Public Key Infrastructure - PKI) would be required to allow secure
information from the web server. retrieving of the information from the web server.
o PMTU discovery does not solve the problem, as it does not allow to o PMTU discovery does not solve the problem, as it does not allow to
send data larger than the minimum of (PMTU or 4096) octets. send data larger than the minimum of (PMTU or 4096) octets.
This document provides a mechanism to allow RADIUS peers to exchange This document provides a mechanism to allow RADIUS peers to exchange
large amounts of authorization data exceeding the 4096 octet limit, large amounts of authorization data exceeding the 4096 octet limit,
by fragmenting it across several exchanges. The proposed solution by fragmenting it across several exchanges. The proposed solution
does not impose any additional requirements to the RADIUS system does not impose any additional requirements to the RADIUS system
administrators (e.g. need to modify firewall rules, set up web administrators (e.g. need to modify firewall rules, set up web
servers, configure routers, or modify any application server). It servers, configure routers, or modify any application server). It
maintains compatibility with intra-packet fragmentation mechanisms maintains compatibility with intra-packet fragmentation mechanisms
(like those defined in [RFC3579] or in [RFC6929]). It is also (like those defined in [RFC3579] or in [RFC6929]). It is also
transparent to existing RADIUS proxies, which do not implement this transparent to existing RADIUS proxies, which do not implement this
specification. The only systems needing to implement the draft are specification. The only systems needing to implement this RFC are
the ones which either generate, or consume the fragmented data being the ones which either generate, or consume the fragmented data being
transmitted. Intermediate proxies just pass the packets without transmitted. Intermediate proxies just pass the packets without
changes. Nevertheless, if a proxy supports this specification, it changes. Nevertheless, if a proxy supports this specification, it
may re-assemble the data in order to either examine and/or modify it. may re-assemble the data in order to either examine and/or modify it.
A different approach to deal with RADIUS packets above the 4096 octet
limit is described in [I-D.ietf-radext-bigger-packets], which
proposes to extend RADIUS over TCP by allowing the length field in
the RADIUS header to take values up to 65535 octets. This provides a
simpler operation, but it has the drawback of requiring every RADIUS
proxy in the path between the RADIUS client and the RADIUS server to
implement the extension as well.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
When these words appear in lower case, they have their natural When these words appear in lower case, they have their natural
language meaning. language meaning.
2. Status of this document 2. Status of this document
skipping to change at page 6, line 44 skipping to change at page 7, line 17
The other Standards Track document that requires a minor update is The other Standards Track document that requires a minor update is
[RFC6158]. It states that "attribute designers SHOULD NOT assume [RFC6158]. It states that "attribute designers SHOULD NOT assume
that a RADIUS implementation can successfully process RADIUS packets that a RADIUS implementation can successfully process RADIUS packets
larger than 4096 octets", something no longer true if this document larger than 4096 octets", something no longer true if this document
advances. advances.
3. Scope of this document 3. Scope of this document
This specification describes how a RADIUS Client and a RADIUS Server This specification describes how a RADIUS Client and a RADIUS Server
can exchange data exceeding the 4096 octet limit imposed by one can exchange data exceeding the 4096 octet limit imposed by one
packet. However, the mechanism described in this specification MUST packet. However, the mechanism described in this specification
NOT be used to exchange more than 100K of data. It has not been SHOULD NOT be used to exchange more than 100 kilo-octets of data.
designed to substitute for stream-oriented transport protocols, such Any more than this may turn RADIUS into a generic transport protocol,
as TCP or SCTP. Experience shows that attempts to transport bulk such as TCP or SCTP, which is undesired. Experience shows that
data across the Internet with UDP will inevitably fail, unless they attempts to transport bulk data across the Internet with UDP will
re-implement all of the behavior of TCP. The underlying design of inevitably fail, unless they re-implement all of the behavior of TCP.
RADIUS lacks the proper retransmission policies or congestion control The underlying design of RADIUS lacks the proper retransmission
mechanisms which would make it a competitor to TCP. policies or congestion control mechanisms which would make it a
competitor to TCP.
Therefore, RADIUS/UDP transport is by design unable to transport bulk Therefore, RADIUS/UDP transport is by design unable to transport bulk
data. It is both undesired and impossible to change the protocol at data. It is both undesired and impossible to change the protocol at
this point in time. This specification is intended to allow the this point in time. This specification is intended to allow the
transport of more than 4096 octets of data through existing RADIUS/ transport of more than 4096 octets of data through existing RADIUS/
UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a
"green field" deployment requires the transport of bulk data. "green field" deployment requires the transport of bulk data.
Section 7, below, describes with further details the reasoning for Section 7, below, describes with further details the reasoning for
this limitation, and recommends administrators to adjust it according this limitation, and recommends administrators to adjust it according
skipping to change at page 7, line 29 skipping to change at page 7, line 50
as other exchanges do not require of such a mechanism. In as other exchanges do not require of such a mechanism. In
particular, authentication exchanges have already been defined to particular, authentication exchanges have already been defined to
overcome this limitation (e.g. RADIUS-EAP). Moreover, as they overcome this limitation (e.g. RADIUS-EAP). Moreover, as they
represent the most critical part of a RADIUS conversation, it is represent the most critical part of a RADIUS conversation, it is
preferable to not introduce any modification to their operation that preferable to not introduce any modification to their operation that
may affect existing equipment. may affect existing equipment.
There is no need to fragment accounting packets either. While the There is no need to fragment accounting packets either. While the
accounting process can send large amounts of data, that data is accounting process can send large amounts of data, that data is
typically composed of many small updates. That is, there is no typically composed of many small updates. That is, there is no
demonstrated need to send indivisible blocks of more than 4K of data. demonstrated need to send indivisible blocks of more than 4 kilo-
The need to send large amounts of data per user session often octets of data. The need to send large amounts of data per user
originates from the need for flow-based accounting. In this use- session often originates from the need for flow-based accounting. In
case, the RADIUS Client may send accounting data for many thousands this use-case, the RADIUS Client may send accounting data for many
of flows, where all those flows are tied to one user session. The thousands of flows, where all those flows are tied to one user
existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section session. The existing Acct-Multi-Session-Id attribute defined in
5.11 has been proven to work here. [RFC2866] Section 5.11 has been proven to work here.
Similarly, there is no need to fragment Change of Authorization (CoA) Similarly, there is no need to fragment Change of Authorization (CoA)
[RFC5176] packets. Instead, the CoA client MUST send a CoA-Request [RFC5176] packets. Instead, the CoA client MUST send a CoA-Request
packet containing session identification attributes, along with packet containing session identification attributes, along with
Service-Type = Additional-Authorization, and a State attribute. Service-Type = Additional-Authorization, and a State attribute.
Implementations not supporting fragmentation will respond with a CoA- Implementations not supporting fragmentation will respond with a CoA-
NAK, and an Error-Cause of Unsupported-Service. NAK, and an Error-Cause of Unsupported-Service.
The above requirement does not assume that the CoA client and the The above requirement does not assume that the CoA client and the
RADIUS Server are co-located. They may, in fact be run on separate RADIUS Server are co-located. They may, in fact be run on separate
skipping to change at page 9, line 24 skipping to change at page 9, line 38
| Proxy Proxy | | Proxy Proxy |
+---------------------+ +---------------------+
| ^ | ^
Access-Request | | CoA-Request Access-Request | | CoA-Request
v | v |
+---------------------+ +---------------------+
| RADIUS CoA client | | RADIUS CoA client |
| Server | | Server |
+---------------------+ +---------------------+
That is, the RADIUS and COA subsystems at each hop are strongly That is, the RADIUS and CoA subsystems at each hop are strongly
connected. Where they are not strongly connected, it will be connected. Where they are not strongly connected, it will be
impossible to use CoA-Request packets to transport large amounts of impossible to use CoA-Request packets to transport large amounts of
authorization data. authorization data.
This design is more complicated than allowing for fragmented CoA This design is more complicated than allowing for fragmented CoA
packets. However, the CoA client and the RADIUS Server must packets. However, the CoA client and the RADIUS Server must
communicate even when not using this specification. We believe that communicate even when not using this specification. We believe that
standardizing that communication, and using one method for exchange standardizing that communication, and using one method for exchange
of large data is preferred to unspecified communication methods and of large data is preferred to unspecified communication methods and
multiple ways of achieving the same result. If we were to allow multiple ways of achieving the same result. If we were to allow
skipping to change at page 14, line 17 skipping to change at page 14, line 34
verification that the Access-Request packet contains some kind of verification that the Access-Request packet contains some kind of
authentication attribute (e.g. User-Password, CHAP-Password, State authentication attribute (e.g. User-Password, CHAP-Password, State
or other future attribute), as required by [RFC2865] (see or other future attribute), as required by [RFC2865] (see
Section 12.2 for more information on this). Section 12.2 for more information on this).
Non-compliant RADIUS Servers (i.e. servers not implementing Non-compliant RADIUS Servers (i.e. servers not implementing
fragmentation) should also see the Service-Type requesting fragmentation) should also see the Service-Type requesting
provisioning for an unknown service, and return Access-Reject. Other provisioning for an unknown service, and return Access-Reject. Other
non-compliant RADIUS Servers may return an Access-Reject, Access- non-compliant RADIUS Servers may return an Access-Reject, Access-
Challenge, or an Access-Accept with a particular Service-Type other Challenge, or an Access-Accept with a particular Service-Type other
then Additional-Authorization. Compliant RADIUS Client than Additional-Authorization. Compliant RADIUS Client
implementations MUST treat these responses as if they had received implementations MUST treat these responses as if they had received
Access-Reject instead. Access-Reject instead.
Compliant RADIUS Servers who wish to receive all of the chunks will Compliant RADIUS Servers who wish to receive all of the chunks will
respond with the following packet. The value of the State here is respond with the following packet. The value of the State here is
arbitrary, and serves only as a unique token for example purposes. arbitrary, and serves only as a unique token for example purposes.
We only note that it MUST be temporally unique to the RADIUS Server. We only note that it MUST be temporally unique to the RADIUS Server.
Access-Accept (ID = 23) Access-Accept (ID = 23)
Frag-Status = More-Data-Request Frag-Status = More-Data-Request
skipping to change at page 21, line 15 skipping to change at page 21, line 41
RADIUS Server, having the potential to allow Denial of Service (DoS) RADIUS Server, having the potential to allow Denial of Service (DoS)
attacks. An attacker could initiate a large number of connections, attacks. An attacker could initiate a large number of connections,
each of which requests the RADIUS Server to store a large amount of each of which requests the RADIUS Server to store a large amount of
data. This data could cause memory exhaustion on the RADIUS Server, data. This data could cause memory exhaustion on the RADIUS Server,
and result in authentic users being denied access. It is worth and result in authentic users being denied access. It is worth
noting that authentication mechanisms are already designed to avoid noting that authentication mechanisms are already designed to avoid
exceeding the size limit. exceeding the size limit.
Hence, implementations of this specification MUST limit the total Hence, implementations of this specification MUST limit the total
amount of data they send and/or receive via this specification. Its amount of data they send and/or receive via this specification. Its
default value SHOULD be 100K. Any more than this may turn RADIUS into default value SHOULD be 100 kilo-octets. Any more than this may turn
a generic transport protocol, which is undesired. This limit SHOULD RADIUS into a generic transport protocol, which is undesired. This
be configurable, so that it can be changed if necessary. limit SHOULD be configurable, so that it can be changed if necessary.
Implementations of this specification MUST limit the total number of Implementations of this specification MUST limit the total number of
round trips used during the fragmentation process. Its default value round trips used during the fragmentation process. Its default value
SHOULD be to 25. Any more than this may indicate an implementation SHOULD be to 25. Any more than this may indicate an implementation
error, misconfiguration, or a denial of service (DoS) attack. This error, misconfiguration, or a denial of service (DoS) attack. This
limit SHOULD be configurable, so that it can be changed if necessary. limit SHOULD be configurable, so that it can be changed if necessary.
For instance, let's imagine the RADIUS Server wants to transport an For instance, let's imagine the RADIUS Server wants to transport an
SAML assertion which is 15000 octets long, to the RADIUS Client. In SAML assertion which is 15000 octets long, to the RADIUS Client. In
this hypothetical scenario, we assume there are 3 intermediate this hypothetical scenario, we assume there are 3 intermediate
skipping to change at page 27, line 49 skipping to change at page 28, line 22
Updated proxies can interact with RADIUS Clients and Servers in order Updated proxies can interact with RADIUS Clients and Servers in order
to obtain the complete large packet before starting forwarding it. to obtain the complete large packet before starting forwarding it.
In this way, proxies can manipulate (modify and/or remove) any In this way, proxies can manipulate (modify and/or remove) any
attribute of the packet, or introduce new attributes, without attribute of the packet, or introduce new attributes, without
worrying about crossing the boundaries of the chunk size. Once the worrying about crossing the boundaries of the chunk size. Once the
manipulated packet is ready, it is sent to the original destination manipulated packet is ready, it is sent to the original destination
using the fragmentation mechanism (if required). The following using the fragmentation mechanism (if required). The following
example shows how an updated proxy interacts with the RADIUS Client example shows how an updated proxy interacts with the RADIUS Client
to obtain a large Access-Request packet, modify an attribute to obtain a large Access-Request packet, modify an attribute
resulting into a even more large packet, and interacts with the resulting into an even more large packet, and interacts with the
RADIUS Server to complete the transmission of the modified packet. RADIUS Server to complete the transmission of the modified packet.
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| RADIUS | | RADIUS | | RADIUS | | RADIUS |
| Client | | Proxy | | Client | | Proxy |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | |
| Access-Request(1){User-Name,Calling-Station-Id, | | Access-Request(1){User-Name,Calling-Station-Id, |
| Example-Long-1[M],Example-Long-1[M], | | Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], | | Example-Long-1[M],Example-Long-1[M], |
skipping to change at page 29, line 35 skipping to change at page 29, line 35
| | | |
| Access-Challenge(1){User-Name, | | Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State3} | | Frag-Status(MDR),State3} |
|<---------------------------------------------------| |<---------------------------------------------------|
| | | |
| Access-Request(5){User-Name,State3,Example-Long-1} | | Access-Request(5){User-Name,State3,Example-Long-1} |
|--------------------------------------------------->| |--------------------------------------------------->|
Figure 16: Updated proxy interacts with RADIUS Server Figure 16: Updated proxy interacts with RADIUS Server
12. Operational considerations 12. General considerations
12.1. Flag T 12.1. Flag T
As described in Section 9, this document modifies the definition of As described in Section 9, this document modifies the definition of
the "Reserved" field of the "Long Extended Type" attribute [RFC6929], the "Reserved" field of the "Long Extended Type" attribute [RFC6929],
by allocating an additional flag "T". The meaning and position of by allocating an additional flag "T". The meaning and position of
this flag is defined in this document, and nowhere else. This might this flag is defined in this document, and nowhere else. This might
generate an issue if subsequent specifications want to allocate a new generate an issue if subsequent specifications want to allocate a new
flag as well, as there would be no direct way for them to know which flag as well, as there would be no direct way for them to know which
parts of the "Reserved" field have already been defined. parts of the "Reserved" field have already been defined.
An immediate and reasonable solution for this issue would be An immediate and reasonable solution for this issue would be
declaring that this draft updates [RFC6929]. In this way, [RFC6929] declaring that this RFC updates [RFC6929]. In this way, [RFC6929]
would include an "Updated by" clause that will point readers to this would include an "Updated by" clause that will point readers to this
document. Another alternative would be creating an IANA registry for document. Another alternative would be creating an IANA registry for
the "Reserved" field. However, the working group thinks that would the "Reserved" field. However, the working group thinks that would
be overkill, as not such a great number of specifications extending be overkill, as not such a great number of specifications extending
that field are expected. that field are expected.
Hence, we have decided to include the "Updates" clause in the Hence, we have decided to include the "Updates" clause in the
document so far. Note that if this experiment does not succeed, the document so far. Note that if this experiment does not succeed, the
"T" flag allocation would not persist, as it is tightly associated to "T" flag allocation would not persist, as it is tightly associated to
this document. this document.
skipping to change at page 32, line 31 skipping to change at page 32, line 31
Value Service Type Value Definition Value Service Type Value Definition
---- ------------------------ ---------- ---- ------------------------ ----------
TBA Additional-Authorization See section 4.1 TBA Additional-Authorization See section 4.1
15. Acknowledgements 15. Acknowledgements
The authors would like to thank the members of the RADEXT working The authors would like to thank the members of the RADEXT working
group who have contributed to the development of this specification, group who have contributed to the development of this specification,
either by participating on the discussions on the mailing lists or by either by participating on the discussions on the mailing lists or by
sending comments about our draft. sending comments about our RFC.
The authors also thank David Cuenca (University of Murcia) for The authors also thank David Cuenca (University of Murcia) for
implementing a proof of concept implementation of this draft that has implementing a proof of concept implementation of this RFC that has
been useful to improve the quality of the specification. been useful to improve the quality of the specification.
This work has been partly funded by the GEANT GN3+ SA5 and CLASSe This work has been partly funded by the GEANT GN3+ SA5 and CLASSe
(http://sec.cs.kent.ac.uk/CLASSe/) projects. (http://sec.cs.kent.ac.uk/CLASSe/) projects.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 33, line 22 skipping to change at page 33, line 22
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, March 2011. BCP 158, RFC 6158, March 2011.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929, Service (RADIUS) Protocol Extensions", RFC 6929,
April 2013. April 2013.
16.2. Informative References 16.2. Informative References
[I-D.ietf-abfab-aaa-saml]
Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding,
Profiles, Name Identifier Format, and Confirmation Methods
for SAML", draft-ietf-abfab-aaa-saml-09 (work in
progress), February 2014.
[I-D.ietf-abfab-arch] [I-D.ietf-abfab-arch]
Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
Schaad, "Application Bridging for Federated Access Beyond Schaad, "Application Bridging for Federated Access Beyond
Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work
in progress), July 2014. in progress), July 2014.
[I-D.ietf-radext-bigger-packets]
Hartman, S., "Larger Packets for RADIUS over TCP",
draft-ietf-radext-bigger-packets-01 (work in progress),
July 2014.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
Rule Attribute", RFC 4849, April 2007. Rule Attribute", RFC 4849, April 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
 End of changes. 27 change blocks. 
70 lines changed or deleted 101 lines changed or added

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