draft-ietf-radext-radius-fragmentation-05.txt   draft-ietf-radext-radius-fragmentation-06.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: RFC6929 (if approved) F. Pereniguez-Garcia Updates: RFC6929 (if approved) F. Pereniguez-Garcia
Intended status: Experimental G. Lopez-Millan Intended status: Experimental G. Lopez-Millan
Expires: September 8, 2014 University of Murcia Expires: October 9, 2014 University of Murcia
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
March 7, 2014 April 7, 2014
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-05 draft-ietf-radext-radius-fragmentation-06
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 September 8, 2014. This Internet-Draft will expire on October 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 40 skipping to change at page 2, line 40
7.4. Rebuilding the original large packet . . . . . . . . . . . 20 7.4. Rebuilding the original large packet . . . . . . . . . . . 20
8. New flag T field for the Long Extended Type attribute 8. New flag T field for the Long Extended Type attribute
definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20 definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. New attribute definition . . . . . . . . . . . . . . . . . . . 21 9. New attribute definition . . . . . . . . . . . . . . . . . . . 21
9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21 9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21
9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22 9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22
9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23 9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23
10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23 10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23
10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24 10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Operational considerations . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.3. Proxying based on User-Name . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 27 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The RADIUS [RFC2865] protocol carries authentication, authorization, The RADIUS [RFC2865] protocol carries authentication, authorization,
and accounting information between a Network Access Server (NAS) and and accounting information between a Network Access Server (NAS) and
an Authentication Server (AS). Information is exchanged between the an Authentication Server (AS). Information is exchanged between the
NAS and the AS through RADIUS packets. Each RADIUS packet is NAS and the AS through RADIUS packets. Each RADIUS packet is
composed of a header, and zero or more attributes, up to a maximum composed of a header, and zero or more attributes, up to a maximum
packet size of 4096 octets. The protocol is a request/response packet size of 4096 octets. The protocol is a request/response
protocol, as described in the operational model ( [RFC6158], Section protocol, as described in the operational model ( [RFC6158], Section
skipping to change at page 10, line 29 skipping to change at page 10, line 29
Message-Authenticator Message-Authenticator
Figure 2: Access-Request (chunk 1) Figure 2: Access-Request (chunk 1)
Compliant servers (i.e. servers implementing fragmentation) receiving Compliant servers (i.e. servers implementing fragmentation) receiving
this packet will see the Frag-Status attribute, and postpone all this packet will see the Frag-Status attribute, and postpone all
authorization and authentication handling until all of the chunks authorization and authentication handling until all of the chunks
have been received. This postponement also affects to the have been received. This postponement also affects to the
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]. This checking or other future attribute), as required by [RFC2865] (see
will therefore be delayed until the original large packet has been Section 11.2 for more information on this).
rebuilt, as some of the chunks may not contain any of them. The
authors acknowledge this is formally violating [RFC2865], but there
are no known operational issues with it. Once this document goes
beyond being considered as experimental, it will state it updates
[RFC2865].
Non-compliant servers (i.e. servers not implementing fragmentation) Non-compliant servers (i.e. servers not implementing fragmentation)
should also see the Service-Type requesting provisioning for an should also see the Service-Type requesting provisioning for an
unknown service, and return Access-Reject. Other non-compliant unknown service, and return Access-Reject. Other non-compliant
servers may return an Access-Reject, Access-Challenge, or an Access- servers may return an Access-Reject, Access-Challenge, or an Access-
Accept with a particular Service-Type other then Additional- Accept with a particular Service-Type other then Additional-
Authorization. Compliant NAS implementations MUST treat these Authorization. Compliant NAS implementations MUST treat these
responses as if they had received Access-Reject instead. responses as if they had received Access-Reject instead.
Compliant servers who wish to receive all of the chunks will respond Compliant servers who wish to receive all of the chunks will respond
skipping to change at page 21, line 10 skipping to change at page 21, line 10
for Truncation. It indicates that the attribute is intentionally for Truncation. It indicates that the attribute is intentionally
truncated in this chunk, and is to be continued in the next chunk of truncated in this chunk, and is to be continued in the next chunk of
the sequence. The combination of the flags "M" and "T" indicates the sequence. The combination of the flags "M" and "T" indicates
that the attribute is fragmented (flag M), but that all the fragments that the attribute is fragmented (flag M), but that all the fragments
are not available in this chunk (flag T). Proxies implementing are not available in this chunk (flag T). Proxies implementing
[RFC6929] will see these attributes as invalid (they will not be able [RFC6929] will see these attributes as invalid (they will not be able
to reconstruct them), but they will still forward them as [RFC6929] to reconstruct them), but they will still forward them as [RFC6929]
section 5.2 indicates they SHOULD forward unknown attributes anyway. section 5.2 indicates they SHOULD forward unknown attributes anyway.
As a consequence of this addition, the Reserved field is now 6 bits As a consequence of this addition, the Reserved field is now 6 bits
long. The following figure represents the new attribute format. long (see Section 11.1 for some considerations). The following
figure represents the new attribute format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M|T| Reserved | | Type | Length | Extended-Type |M|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Updated Long Extended Type attribute format Figure 12: Updated Long Extended Type attribute format
skipping to change at page 24, line 9 skipping to change at page 24, line 9
As every chunk is indeed a RADIUS packet, legacy proxies treat them As every chunk is indeed a RADIUS packet, legacy proxies treat them
as the rest of packets, routing them to their destination. Proxies as the rest of packets, routing them to their destination. Proxies
can introduce Proxy-State attributes to Access-Request packets, even can introduce Proxy-State attributes to Access-Request packets, even
if they are indeed chunks. This will not affect how fragmentation is if they are indeed chunks. This will not affect how fragmentation is
managed. The server will include all the received Proxy-State managed. The server will include all the received Proxy-State
attributes into the generated response, as described in [RFC2865]. attributes into the generated response, as described in [RFC2865].
Hence, proxies do not distinguish between a regular RADIUS packet and Hence, proxies do not distinguish between a regular RADIUS packet and
a chunk. a chunk.
This proposal assumes legacy proxies to base their routing decisions
on the value of the User-Name attribute. For this reason, every
packet sent from the client to the server (either chunks or requests
for more chunks) MUST contain a User-Name attribute.
10.2. Updated proxies 10.2. Updated proxies
Updated proxies can interact with clients and servers in order to Updated proxies can interact with clients and servers in order to
obtain the complete large packet before starting forwarding it. In obtain the complete large packet before starting forwarding it. In
this way, proxies can manipulate (modify and/or remove) any attribute this way, proxies can manipulate (modify and/or remove) any attribute
of the packet, or introduce new attributes, without worrying about of the packet, or introduce new attributes, without worrying about
crossing the boundaries of the chunk size. Once the manipulated crossing the boundaries of the chunk size. Once the manipulated
packet is ready, it is sent to the original destination using the packet is ready, it is sent to the original destination using the
fragmentation mechanism (if required). The following example shows fragmentation mechanism (if required). The following example shows
how an updated proxy interacts with the NAS to obtain a large Access- how an updated proxy interacts with the NAS to obtain a large Access-
skipping to change at page 25, line 34 skipping to change at page 25, line 34
| | | |
| 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 17: Updated proxy interacts with AS Figure 17: Updated proxy interacts with AS
11. Security Considerations 11. Operational considerations
11.1. Flag T
As described in Section 8, this document modifies the definition of
the "Reserved" field of the "Long Extended Type" attribute [RFC6929],
by allocating an additional flag "T". The meaning and position of
this flag is defined in this document, and nowhere else. This might
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
parts of the "Reserved" field have already been defined.
An immediate and reasonable solution for this issue would be
declaring that this draft updates [RFC6929]. In this way, [RFC6929]
would include an "Updated by" clause that will point readers to this
document. However, since this draft belongs to the Experimental
track and [RFC6929] belongs to the Standards track, we do not know if
including that "Updates" clause would be acceptable.
Another alternative would be creating an IANA registry for the
"Reserved" field. However, the working group thinks that would be
overkill, as not such a great number of specifications extending that
field are expected.
Hence, we have decided to include the "Updates" clause in the
document so far.
11.2. Violation of RFC2865
Section 4.1 indicates that all authorization and authentication
handling will be postponed until all the chunks have been received.
This postponement also affects to the verification that the Access-
Request packet contains some kind of authentication attribute (e.g.
User-Password, CHAP-Password, State or other future attribute), as
required by [RFC2865]. This checking will therefore be delayed until
the original large packet has been rebuilt, as some of the chunks may
not contain any of them. The authors acknowledge this is formally
violating [RFC2865], but there are no known operational issues with
it. Proxies are supposed to not check this, as [RFC2865] specifies
that other attributes might be considered as authentication
information in future extensions, and doing so would make them too
restrictive. Once this document goes beyond being considered as
experimental, it will state it updates [RFC2865].
11.3. Proxying based on User-Name
This proposal assumes legacy proxies to base their routing decisions
on the value of the User-Name attribute. For this reason, every
packet sent from the client to the server (either chunks or requests
for more chunks) MUST contain a User-Name attribute.
12. Security Considerations
As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) As noted in many earlier specifications ([RFC5080], [RFC6158], etc.)
RADIUS security is problematic. This specification changes nothing RADIUS security is problematic. This specification changes nothing
related to the security of the RADIUS protocol. It requires that all related to the security of the RADIUS protocol. It requires that all
Access-Request packets associated with fragmentation are Access-Request packets associated with fragmentation are
authenticated using the existing Message-Authenticator attribute. authenticated using the existing Message-Authenticator attribute.
This signature prevents forging and replay, to the limits of the This signature prevents forging and replay, to the limits of the
existing security. existing security.
The ability to send bulk data from one party to another creates new The ability to send bulk data from one party to another creates new
skipping to change at page 26, line 11 skipping to change at page 27, line 14
stored per session. The exact method for this limitation is stored per session. The exact method for this limitation is
implementation-specific. Section 6 gives some indications on what implementation-specific. Section 6 gives some indications on what
could be reasonable limits. could be reasonable limits.
The bulk data can often be pushed off to storage methods other than The bulk data can often be pushed off to storage methods other than
the memory of the RADIUS implementation. For example, it can be the memory of the RADIUS implementation. For example, it can be
stored in an external database, or in files. This approach mitigates stored in an external database, or in files. This approach mitigates
the resource exhaustion issue, as servers today already store large the resource exhaustion issue, as servers today already store large
amounts of accounting data. amounts of accounting data.
12. IANA Considerations 13. IANA Considerations
The authors request that Attribute Types and Attribute Values defined The authors request that Attribute Types and Attribute Values defined
in this document be registered by the Internet Assigned Numbers in this document be registered by the Internet Assigned Numbers
Authority (IANA) from the RADIUS namespaces as described in the "IANA Authority (IANA) from the RADIUS namespaces as described in the "IANA
Considerations" section of [RFC3575], in accordance with BCP 26 Considerations" section of [RFC3575], in accordance with BCP 26
[RFC5226]. For RADIUS packets, attributes and registries created by [RFC5226]. For RADIUS packets, attributes and registries created by
this document IANA is requested to place them at this document IANA is requested to place them at
http://www.iana.org/assignments/radius-types. http://www.iana.org/assignments/radius-types.
This document defines the following RADIUS messages: This document defines the following RADIUS messages:
o Frag-Status o Frag-Status
o Proxy-State-Len o Proxy-State-Len
Additionally, allocation of a new Service-Type value for "Additional- Additionally, allocation of a new Service-Type value for "Additional-
Authorization" is requested. Authorization" is requested.
13. References 14. Acknowledgements
13.1. Normative References The authors would like to thank the members of the RADEXT working
group who have contributed to the development of this specification,
either by participating on the discussions on the mailing lists or by
sending comments about our draft.
The authors also thank David Cuenca (University of Murcia) for
implementing a proof of concept implementation of this draft that has
been useful to improve the quality of the specification.
This work has been partly funded by the GEANT GN3+ SA5 and CLASSe
(http://sec.cs.kent.ac.uk/CLASSe/) projects.
15. References
15.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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, Authentication Dial In User Service)", RFC 3575,
skipping to change at page 27, line 9 skipping to change at page 28, line 28
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[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.
13.2. Informative References 15.2. Informative References
[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.
 End of changes. 13 change blocks. 
28 lines changed or deleted 88 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/