idnits 2.17.1 draft-ietf-radext-filter-07.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 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. 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 10 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 10, 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 A NAS-Filter-Rule attribute sent by a RADIUS server may not be 263 understood by the NAS which receives it. A legacy NAS not compliant 264 with this specification may silently discard the NAS-Filter-Rule 265 attribute while permitting the user to access the network. This can 266 lead to users improperly receiving unfiltered access to the network. 267 As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a 268 NAS that is known to support it. 270 7. References 272 7.1. Normative references 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", RFC 2119, March, 1997. 277 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 278 Authentication Dial In User Service (RADIUS)", RFC 2865, June 279 2000. 281 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 282 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 284 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 285 Network Access Server Application", RFC 4005, August 2005. 287 7.2. Informative references 289 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 290 Implementation in Roaming", RFC 2607, June 1999. 292 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 293 "Dynamic Authorization Extensions to Remote Authentication 294 Dial In User Service (RADIUS)", RFC 3576, July 2003. 296 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 297 Authentication Protocol (EAP)", RFC 3579, September 2003. 299 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 300 802.1X Remote Authentication Dial In User Service (RADIUS) 301 Usage Guidelines", RFC3580, September 2003. 303 [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, 304 "RADIUS Attributes for Filtering and Redirection", Internet 305 draft (work in progress), draft-ietf-radext-filter- 306 rules-01.txt, June 2006. 308 Acknowledgments 310 The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg 311 Weber, Glen Zorn, Pasi Eronen, David Mitton and David Nelson for 312 contributions to this document. 314 Authors' Addresses 316 Paul Congdon 317 Hewlett Packard Company 318 HP ProCurve Networking 319 8000 Foothills Blvd, M/S 5662 320 Roseville, CA 95747 322 EMail: paul.congdon@hp.com 323 Phone: +1 916 785 5753 324 Fax: +1 916 785 8478 326 Mauricio Sanchez 327 Hewlett Packard Company 328 HP ProCurve Networking 329 8000 Foothills Blvd, M/S 5559 330 Roseville, CA 95747 332 EMail: mauricio.sanchez@hp.com 333 Phone: +1 916 785 1910 334 Fax: +1 916 785 1815 336 Bernard Aboba 337 Microsoft Corporation 338 One Microsoft Way 339 Redmond, WA 98052 341 EMail: bernarda@microsoft.com 342 Phone: +1 425 706 6605 343 Fax: +1 425 936 7329 345 Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at ietf- 367 ipr@ietf.org. 369 Disclaimer of Validity 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 374 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 375 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Copyright Statement 381 Copyright (C) The IETF Trust (2007). This document is subject to the 382 rights, licenses and restrictions contained in BCP 78, and except as 383 set forth therein, the authors retain all their rights. 385 Acknowledgment 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society. 390 Open issues 392 Open issues relating to this specification are tracked on the 393 following web site: 395 http://www.drizzle.com/~aboba/RADEXT/