draft-ietf-radext-bigger-packets-04.txt   draft-ietf-radext-bigger-packets-05.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Updates: 6613, 6614 (if approved) October 19, 2015 Updates: 6613, 6614 (if approved) December 9, 2015
Intended status: Experimental Intended status: Experimental
Expires: April 21, 2016 Expires: June 11, 2016
Larger Packets for RADIUS over TCP Larger Packets for RADIUS over TCP
draft-ietf-radext-bigger-packets-04.txt draft-ietf-radext-bigger-packets-05.txt
Abstract Abstract
The RADIUS over TLS experiment described in RFC 6614 has opened The RADIUS over TLS experiment described in RFC 6614 has opened
RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS to new use cases where the 4096-octet maximum size limit of
RADIUS packet proves problematic. This specification extends the RADIUS packet proves problematic. This specification extends the
RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS
packets. This specification compliments other ongoing work to permit packets. This specification compliments other ongoing work to permit
fragmentation of RADIUS authorization information. This document fragmentation of RADIUS authorization information. This document
registers a new RADIUS code, an action which requires IESG approval. registers a new RADIUS code, an action which requires IESG approval.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 April 21, 2016. This Internet-Draft will expire on June 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Remote Authentication DialIn User Service (RADIUS) over TLS The Remote Authentication Dial In User Service (RADIUS) over TLS
[RFC6614] experiment provides strong confidentiality and integrity [RFC6614] experiment provides strong confidentiality and integrity
for RADIUS [RFC2865]. This enhanced security has opened new for RADIUS [RFC2865]. This enhanced security has opened new
opportunities for using RADIUS to convey additional authorization opportunities for using RADIUS to convey additional authorization
information. As an example, [I-D.ietf-abfab-aaa-saml] describes a information. As an example, [I-D.ietf-abfab-aaa-saml] describes a
mechanism for using RADIUS to carry Security Assertion Markup mechanism for using RADIUS to carry Security Assertion Markup
Language (SAML) messages in RADIUS. Many attributes carried in these Language (SAML) messages in RADIUS. Many attributes carried in these
SAML messages will require confidentiality or integrity such as that SAML messages will require confidentiality or integrity such as that
provided by TLS. provided by TLS.
These new use cases involve carrying additional information in RADIUS These new use cases involve carrying additional information in RADIUS
skipping to change at page 4, line 46 skipping to change at page 4, line 46
support this specification removing the need for interoperability support this specification removing the need for interoperability
with RFC 6613. It is likely that these guidelines will be relaxed to with RFC 6613. It is likely that these guidelines will be relaxed to
the MAY level and support for this specification made a requirement the MAY level and support for this specification made a requirement
if RADIUS over TLS and TCP are moved to the standards track in the if RADIUS over TLS and TCP are moved to the standards track in the
future. future.
Clients SHOULD provide configuration for the maximum size of a Clients SHOULD provide configuration for the maximum size of a
request sent to each server. Servers SHOULD provide configuration request sent to each server. Servers SHOULD provide configuration
for the maximum size of a response sent to each client. If dynamic for the maximum size of a response sent to each client. If dynamic
discovery mechanisms are supported, configuration SHOULD be provided discovery mechanisms are supported, configuration SHOULD be provided
for the maximum size of clients and servers in each dynamic discovery for the default maximum size of packets sent to clients and servers.
category. If an implementation provides more granular configuration for some
classes of dynamic resources, then the implementation SHOULD also
provide configuration of default maximum packet sizes at the same
granularity. As an example, an implementation that provided granular
configuration for resources using a particular trust anchor or
belonging to a particular roaming consortium SHOULD provide default
packet size configuration at the same granularity.
If a client sends a request larger than 4096 octets and the TCP If a client sends a request larger than 4096 octets and the TCP
connection is closed without a response, the client SHOULD treat the connection is closed without a response, the client SHOULD treat the
request as if a request too big error (Section 5) specifying a request as if a request too big error (Section 5) specifying a
maximum size of 4096 is received. Clients or proxies sending maximum size of 4096 is received. Clients or proxies sending
multiple requests over a single TCP connection without waiting for multiple requests over a single TCP connection without waiting for
responses SHOULD implement capability discovery as discussed in responses SHOULD implement capability discovery as discussed in
Section 3.2. Section 3.2.
By default, a server SHOULD not generate a response larger than 4096 By default, a server SHOULD not generate a response larger than 4096
skipping to change at page 7, line 39 skipping to change at page 7, line 42
name is "Protocol-Error" and the code is TBDCODE. The IESG is name is "Protocol-Error" and the code is TBDCODE. The IESG is
requested to approve this registration along with approving requested to approve this registration along with approving
publication of this document. publication of this document.
The following RADIUS attribute type values [RFC3575] are assigned. The following RADIUS attribute type values [RFC3575] are assigned.
The assignment rules in section 10.3 of [RFC6929] are used. The assignment rules in section 10.3 of [RFC6929] are used.
+----------------------+-----------+--------------------------------+ +----------------------+-----------+--------------------------------+
| Name | Attribute | Description | | Name | Attribute | Description |
+----------------------+-----------+--------------------------------+ +----------------------+-----------+--------------------------------+
| Response-Length | TBD | 2-octet unsigned integer | | Response-Length | TBD | attribute of type "integer" |
| | | maximum response length | | | | per Section 5 of RFC 2865 |
| | | containing maximum response |
| | | length |
| | | | | | | |
| Original-Packet-Code | TBD2 | An integer attribute | | Original-Packet-Code | TBD2 | An integer attribute |
| | | containing the code from a | | | | containing the code from a |
| | | packet resulting in a | | | | packet resulting in a |
| | | Protocol-Error response. | | | | Protocol-Error response. |
+----------------------+-----------+--------------------------------+ +----------------------+-----------+--------------------------------+
The Response-Length attribute MAY be included in any RADIUS request. The Response-Length attribute MAY be included in any RADIUS request.
In this context it indicates the maximum length of a response the In this context it indicates the maximum length of a response the
client is prepared to receive. Values are between 4096 and 65535. client is prepared to receive. Values are between 4096 and 65535.
The attribute MAY also be included in a response to a Status-Server The attribute MAY also be included in a response to a Status-Server
message. In this case the attribute indicates the maximum size message. In this case the attribute indicates the maximum size
RADIUS request that is permitted. RADIUS request that is permitted.
A new Error-Cause value is registered in the registry at A new Error-Cause value is registered in the registry at
http://www.iana.org/assignments/radius-types/radius- http://www.iana.org/assignments/radius-types/radius-
types.xhtml#radius-types-18 for "Response Too Big" with value types.xhtml#radius-types-18 for "Response Too Big" with value
skipping to change at page 8, line 14 skipping to change at page 8, line 18
message. In this case the attribute indicates the maximum size message. In this case the attribute indicates the maximum size
RADIUS request that is permitted. RADIUS request that is permitted.
A new Error-Cause value is registered in the registry at A new Error-Cause value is registered in the registry at
http://www.iana.org/assignments/radius-types/radius- http://www.iana.org/assignments/radius-types/radius-
types.xhtml#radius-types-18 for "Response Too Big" with value types.xhtml#radius-types-18 for "Response Too Big" with value
TOOBIGTBD. TOOBIGTBD.
7. Security Considerations 7. Security Considerations
This specification updates RFC 6613 and will be used with [RFC6614]. This specification updates [RFC6613] and will be used with [RFC6614].
When used over plain TCP, this specification creates new When used over plain TCP, this specification creates new
opportunities for an on-path attacker to impact availability. These opportunities for an on-path attacker to impact availability. These
attacks can be entirely mitigated by using TLS. If these attacks ar attacks can be entirely mitigated by using TLS. If these attacks are
acceptable, then this specification can be used over TCP. acceptable, then this specification can be used over TCP.
8. Acknowledgements 8. Acknowledgements
Sam Hartman's time on this draft was funded by JANET as part of Sam Hartman's time on this draft was funded by JANET as part of
Project Moonshot. Project Moonshot.
Alan DeKok provided valuable review and text for the Protocol-Error Alan DeKok provided valuable review and text for the Protocol-Error
packet code. packet code.
 End of changes. 10 change blocks. 
12 lines changed or deleted 19 lines changed or added

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