idnits 2.17.1 draft-ietf-radext-filter-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) == Outdated reference: A later version (-03) exists of draft-ietf-radext-filter-rules-01 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul Congdon 3 INTERNET-DRAFT Mauricio Sanchez 4 Category: Proposed Standard Hewlett-Packard Company 5 Bernard Aboba 6 13 January 2007 Microsoft Corporation 8 RADIUS Filter Rule Attribute 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 18, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). All rights reserved. 37 Abstract 39 While RFC 2865 defines the Filter-Id attribute, this requires that 40 the Network Access Server (NAS) be pre-populated with the desired 41 filters. However, in situations where the server operator does not 42 know which filters have been pre-populated, it is useful to specify 43 filter rules explicitly. This document defines the NAS-Filter-Rule 44 attribute within the Remote Authentication Dial In User Service 45 (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule 46 Attribute Value Pair (AVP) described in RFC 4005, and the 47 IPFilterRule syntax defined in RFC 3588. 49 Table of Contents 51 1. Introduction .......................................... 3 52 1.1 Terminology ..................................... 3 53 1.2 Requirements Language ........................... 3 54 1.3 Attribute Interpretation ........................ 3 55 2. NAS-Filter-Rule Attribute ............................. 4 56 3. Table of Attributes ................................... 5 57 4. Diameter Considerations ............................... 5 58 5. IANA Considerations ................................... 6 59 6. Security Considerations ............................... 6 60 7. References ............................................ 7 61 7.1 Normative References ............................ 7 62 7.2 Informative References .......................... 7 63 ACKNOWLEDGMENTS .............................................. 8 64 AUTHORS' ADDRESSES ........................................... 8 65 Intellectual Property Statement............................... 9 66 Disclaimer of Validity........................................ 9 67 Full Copyright Statement ..................................... 9 68 1. Introduction 70 This document defines the NAS-Filter-Rule attribute within the Remote 71 Authentication Dialin User Service (RADIUS). This attribute has the 72 same functionality as the Diameter NAS-Filter-Rule AVP (400) defined 73 in [RFC4005] Section 6.6 and the same syntax as an IPFilterRule 74 defined in [RFC3588] Section 4.3. This attribute may prove useful 75 for provisioning of filter rules. 77 While [RFC2865] Section 5.11 defines the Filter-Id attribute (11), 78 this requires that the Network Access Server (NAS) be pre-populated 79 with the desired filters. However, in situations where the server 80 operator does not know which filters have been pre-populated, it 81 useful to specify filter rules explicitly. 83 1.1. Terminology 85 This document uses the following terms: 87 Network Access Server (NAS) 88 A device that provides an access service for a user to a network. 90 RADIUS server 91 A RADIUS authentication server is an entity that provides an 92 authentication service to a NAS. 94 RADIUS proxy 95 A RADIUS proxy acts as an authentication server to the NAS, and a 96 RADIUS client to the RADIUS server. 98 1.2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 1.3. Attribute Interpretation 106 If a NAS conforming to this specification receives an Access-Accept 107 packet containing a NAS-Filter-Rule attribute which it cannot apply, 108 it MUST act as though it had received an Access-Reject. [RFC3576] 109 requires that a NAS receiving a Change of Authorization Request 110 (CoA-Request) reply with a CoA-NAK if the Request contains an 111 unsupported attribute. It is RECOMMENDED that an Error-Cause 112 attribute with value set to "Unsupported Attribute" (401) be included 113 in the CoA-NAK. As noted in [RFC3576], authorization changes are 114 atomic so that this situation does not result in session termination 115 and the pre-existing configuration remains unchanged. As a result, 116 no accounting packets should be generated as a result of the CoA- 117 Request. 119 2. NAS-Filter-Rule Attribute 121 Description 123 This attribute indicates filter rules to be applied for this user. 124 Zero or more NAS-Filter-Rule attributes MAY be sent in Access- 125 Accept, CoA-Request, or Accounting-Request packets. 127 The NAS-Filter-Rule attribute is not intended to be used 128 concurrently with any other filter rule attribute, including 129 Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes. NAS- 130 Filter-Rule and NAS-Traffic-Rule attributes MUST NOT appear in the 131 same RADIUS packet. If a NAS-Traffic-Rule attribute is present, a 132 NAS implementing this specification MUST silently discard NAS- 133 Filter-Rule attributes, if present. Filter-Id and NAS-Filter-Rule 134 attributes SHOULD NOT appear in the same RADIUS packet. Given the 135 absence in [RFC4005] of well-defined precedence rules for 136 combining Filter-Id and NAS-Filter-Rule attributes into a single 137 rule set, the behavior of NASes receiving both attributes is 138 undefined, and therefore a RADIUS server implementation cannot 139 assume a consistent behavior. 141 Where multiple NAS-Filter-Rule attributes are included in a RADIUS 142 packet, the String field of the attributes are to be concatenated 143 to form a set of filter rules. As noted in [RFC2865] Section 2.3, 144 "the forwarding server MUST NOT change the order of any attributes 145 of the same type", so that RADIUS proxies will not reorder NAS- 146 Filter-Rule attributes. 148 A summary of the NAS-Filter-Rule Attribute format is shown below. 149 The fields are transmitted from left to right. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type | Length | String... 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Type 159 TBD 161 Length 163 >=3 165 String 167 The String field is one or more octets. It contains filter rules 168 in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with 169 individual filter rules separated by a NUL (0x00). A NAS-Filter- 170 Rule attribute may contain a partial rule, one rule, or more than 171 one rule. Filter rules may be continued across attribute 172 boundaries, so implementations cannot assume that individual 173 filter rules begin or end on attribute boundaries. 175 The set of NAS-Filter-Rule attributes SHOULD be created by 176 concatenating the individual filter rules, separated by a NUL 177 (0x00) octet. The resulting data should be split on 253 byte 178 boundaries to obtain a set of NAS-Filter-Rule attributes. On 179 reception, the individual filter rules are determined by 180 concatenating the contents of all NAS-Filter-Rule attributes, and 181 then splitting individual filter rules with the the NUL octet 182 (0x00) as a delimeter. 184 3. Table of Attributes 186 The following table provides a guide to which attributes may be found 187 in which kinds of packets, and in what quantity. 189 Access- Access- Access- Access- CoA- Acct- 190 Request Accept Reject Challenge Req Req # Attribute 191 0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule 193 The following table defines the meaning of the above table entries. 195 0 This attribute MUST NOT be present in the packet. 196 0+ Zero or more instances of this attribute MAY be 197 present in the packet. 198 0-1 Zero or one instance of this attribute MAY be 199 present in the packet. 201 4. Diameter Considerations 203 [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the 204 same functionality as the RADIUS NAS-Filter-Rule attribute. In order 205 to support interoperability, Diameter/RADIUS gateways will need to be 206 configured to translate RADIUS attribute TBD to Diameter AVP 400 and 207 vice-versa. 209 When translating Diameter NAS-Filter-Rule AVPs to RADIUS NAS-Filter- 210 Rule attributes, the set of NAS-Filter-Rule attributes is created by 211 concatenating the individual filter rules, separated by a NUL octet. 212 The resulting data SHOULD then be split on 253 byte boundaries. 214 When translating RADIUS NAS-Filter-Rule attributes to Diameter NAS- 215 Filter-Rule AVPs, the individual rules are determined by 216 concatenating the contents of all NAS-Filter-Rule attributes, and 217 then splitting individual filter rules with the NUL octet as a 218 delimeter. Each rule is then encoded as a single Diameter NAS- 219 Filter-Rule AVP. 221 Note that a translated Diameter message can be larger than the 222 maximum RADIUS packet size (4096). Where a Diameter/RADIUS gateway 223 receives a Diameter message containing a NAS-Filter-Rule AVP that is 224 too large to fit into a RADIUS packet, the Diameter/RADIUS gateway 225 will respond to the originating Diameter peer with a Result-Code AVP 226 with the value DIAMETER_RADIUS_AVP_UNTRANSLATABLE (TBD), and with a 227 Failed-AVP AVP containing the NAS-Filter-Rule AVP. Since repairing 228 the error will probably require re-working the filter rules, the 229 originating peer should treat the combination of a Result-Code AVP 230 with value DIAMETER_RADIUS_AVP_UNTRANSLATABLE and a Failed-AVP AVP 231 containing a NAS-Filter-Rule AVP as a terminal error. 233 5. IANA Considerations 235 This specification does not create any new registries. 237 This document uses the RADIUS [RFC2865] namespace, see 238 . Allocation of one 239 update for the section "RADIUS Attribute Types" is requested. The 240 RADIUS attribute for which a value is requested is: 242 TBD - NAS-Filter-Rule 244 This document also utilizes the Diameter [RFC3588] namespace. 245 Allocation of a Diameter Result-Code AVP value for the 246 DIAMETER_RADIUS_AVP_UNTRANSLATABLE error is requested. Since this is 247 a permanent failure, an allocation should be provided in the 5xxx 248 range. 250 6. Security Considerations 252 This specification describes the use of RADIUS for purposes of 253 authentication, authorization and accounting. Threats and security 254 issues for this application are described in [RFC3579] and [RFC3580]; 255 security issues encountered in roaming are described in [RFC2607]. 257 This document specifies a new attribute that can be included in 258 existing RADIUS packets, which are protected as described in 259 [RFC3579] and [RFC3576]. See those documents for a more detailed 260 description. 262 The security mechanisms supported in RADIUS and Diameter are focused 263 on preventing an attacker from spoofing packets or modifying packets 264 in transit. They do not prevent an authorized RADIUS/Diameter server 265 or proxy from modifying, inserting or removing attributes with 266 malicious intent. Filter attributes modified or removed by a 267 RADIUS/Diameter proxy may enable a user to obtain network access 268 without the appropriate filters; if the proxy were also to modify 269 accounting packets, then the modification would not be reflected in 270 the accounting server logs. 272 Since the RADIUS protocol currently does not support capability 273 negotiation, a RADIUS server cannot automatically discover whether a 274 NAS supports the NAS-Filter-Rule attribute. A legacy NAS not 275 compliant with this specification may silently discard the NAS- 276 Filter-Rule attribute while permitting the user to access the 277 network. This can lead to users improperly receiving unfiltered 278 access to the network. As a result, the NAS-Filter-Rule attribute 279 SHOULD only be sent to a NAS that is known to support it. 281 7. References 283 7.1. Normative references 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", RFC 2119, March, 1997. 288 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 289 Authentication Dial In User Service (RADIUS)", RFC 2865, June 290 2000. 292 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 293 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 295 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 296 Network Access Server Application", RFC 4005, August 2005. 298 7.2. Informative references 300 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 301 Implementation in Roaming", RFC 2607, June 1999. 303 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 304 "Dynamic Authorization Extensions to Remote Authentication 305 Dial In User Service (RADIUS)", RFC 3576, July 2003. 307 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 308 Authentication Protocol (EAP)", RFC 3579, September 2003. 310 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 311 802.1X Remote Authentication Dial In User Service (RADIUS) 312 Usage Guidelines", RFC3580, September 2003. 314 [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, 315 "RADIUS Attributes for Filtering and Redirection", Internet 316 draft (work in progress), draft-ietf-radext-filter- 317 rules-01.txt, June 2006. 319 Acknowledgments 321 The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg 322 Weber, Glen Zorn, Pasi Eronen, David Mitton and David Nelson for 323 contributions to this document. 325 Authors' Addresses 327 Paul Congdon 328 Hewlett Packard Company 329 HP ProCurve Networking 330 8000 Foothills Blvd, M/S 5662 331 Roseville, CA 95747 333 EMail: paul.congdon@hp.com 334 Phone: +1 916 785 5753 335 Fax: +1 916 785 8478 337 Mauricio Sanchez 338 Hewlett Packard Company 339 HP ProCurve Networking 340 8000 Foothills Blvd, M/S 5559 341 Roseville, CA 95747 343 EMail: mauricio.sanchez@hp.com 344 Phone: +1 916 785 1910 345 Fax: +1 916 785 1815 347 Bernard Aboba 348 Microsoft Corporation 349 One Microsoft Way 350 Redmond, WA 98052 352 EMail: bernarda@microsoft.com 353 Phone: +1 425 706 6605 354 Fax: +1 425 936 7329 356 Intellectual Property Statement 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at ietf- 378 ipr@ietf.org. 380 Disclaimer of Validity 382 This document and the information contained herein are provided on an 383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 385 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 386 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 387 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Copyright Statement 392 Copyright (C) The IETF Trust (2007). This document is subject to the 393 rights, licenses and restrictions contained in BCP 78, and except as 394 set forth therein, the authors retain all their rights. 396 Acknowledgment 398 Funding for the RFC Editor function is currently provided by the 399 Internet Society. 401 Open issues 403 Open issues relating to this specification are tracked on the 404 following web site: 406 http://www.drizzle.com/~aboba/RADEXT/