--- 1/draft-ietf-radext-radius-fragmentation-05.txt 2014-04-07 02:14:36.627292229 -0700 +++ 2/draft-ietf-radext-radius-fragmentation-06.txt 2014-04-07 02:14:36.687293668 -0700 @@ -1,24 +1,24 @@ RADIUS EXTensions Working Group A. Perez-Mendez Internet-Draft R. Marin-Lopez Updates: RFC6929 (if approved) F. Pereniguez-Garcia Intended status: Experimental G. Lopez-Millan -Expires: September 8, 2014 University of Murcia +Expires: October 9, 2014 University of Murcia D. Lopez Telefonica I+D A. DeKok Network RADIUS - March 7, 2014 + April 7, 2014 Support of fragmentation of RADIUS packets - draft-ietf-radext-radius-fragmentation-05 + draft-ietf-radext-radius-fragmentation-06 Abstract The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -75,26 +75,31 @@ 7.4. Rebuilding the original large packet . . . . . . . . . . . 20 8. New flag T field for the Long Extended Type attribute definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. New attribute definition . . . . . . . . . . . . . . . . . . . 21 9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21 9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22 9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23 10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23 10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23 10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11. Operational considerations . . . . . . . . . . . . . . . . . . 25 + 11.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 11.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 26 + 11.3. Proxying based on User-Name . . . . . . . . . . . . . . . 26 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 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 The RADIUS [RFC2865] protocol carries authentication, authorization, and accounting information between a Network Access Server (NAS) and an Authentication Server (AS). Information is exchanged between the NAS and the AS through RADIUS packets. Each RADIUS packet is composed of a header, and zero or more attributes, up to a maximum packet size of 4096 octets. The protocol is a request/response protocol, as described in the operational model ( [RFC6158], Section @@ -441,27 +446,22 @@ Message-Authenticator Figure 2: Access-Request (chunk 1) Compliant servers (i.e. servers implementing fragmentation) receiving this packet will see the Frag-Status attribute, and postpone all authorization and authentication handling until all of 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. Once this document goes - beyond being considered as experimental, it will state it updates - [RFC2865]. + or other future attribute), as required by [RFC2865] (see + Section 11.2 for more information on this). Non-compliant servers (i.e. servers not implementing fragmentation) should also see the Service-Type requesting provisioning for an unknown service, and return Access-Reject. Other non-compliant servers may return an Access-Reject, Access-Challenge, or an Access- Accept with a particular Service-Type other then Additional- Authorization. Compliant NAS implementations MUST treat these responses as if they had received Access-Reject instead. Compliant servers who wish to receive all of the chunks will respond @@ -932,21 +931,22 @@ for Truncation. It indicates that the attribute is intentionally 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 that the attribute is fragmented (flag M), but that all the fragments are not available in this chunk (flag T). Proxies implementing [RFC6929] will see these attributes as invalid (they will not be able to reconstruct them), but they will still forward them as [RFC6929] section 5.2 indicates they SHOULD forward unknown attributes anyway. 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Updated Long Extended Type attribute format @@ -1072,25 +1072,20 @@ As every chunk is indeed a RADIUS packet, legacy proxies treat them as the rest of packets, routing them to their destination. Proxies can introduce Proxy-State attributes to Access-Request packets, even if they are indeed chunks. This will not affect how fragmentation is managed. The server will include all the received Proxy-State attributes into the generated response, as described in [RFC2865]. Hence, proxies do not distinguish between a regular RADIUS packet and 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 Updated proxies can interact with clients and servers in order to obtain the complete large packet before starting forwarding it. In this way, proxies can manipulate (modify and/or remove) any attribute of the packet, or introduce new attributes, without worrying about crossing the boundaries of the chunk size. Once the manipulated packet is ready, it is sent to the original destination using the fragmentation mechanism (if required). The following example shows how an updated proxy interacts with the NAS to obtain a large Access- @@ -1144,21 +1139,72 @@ | | | Access-Challenge(1){User-Name, | | Frag-Status(MDR),State3} | |<---------------------------------------------------| | | | Access-Request(5){User-Name,State3,Example-Long-1} | |--------------------------------------------------->| 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.) RADIUS security is problematic. This specification changes nothing related to the security of the RADIUS protocol. It requires that all Access-Request packets associated with fragmentation are authenticated using the existing Message-Authenticator attribute. This signature prevents forging and replay, to the limits of the existing security. The ability to send bulk data from one party to another creates new @@ -1169,42 +1215,55 @@ stored per session. The exact method for this limitation is implementation-specific. Section 6 gives some indications on what could be reasonable limits. The bulk data can often be pushed off to storage methods other than the memory of the RADIUS implementation. For example, it can be stored in an external database, or in files. This approach mitigates the resource exhaustion issue, as servers today already store large amounts of accounting data. -12. IANA Considerations +13. IANA Considerations The authors request that Attribute Types and Attribute Values defined in this document be registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS namespaces as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes and registries created by this document IANA is requested to place them at http://www.iana.org/assignments/radius-types. This document defines the following RADIUS messages: o Frag-Status o Proxy-State-Len Additionally, allocation of a new Service-Type value for "Additional- 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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, @@ -1214,21 +1273,21 @@ IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. -13.2. Informative References +15.2. Informative References [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007.