idnits 2.17.1 draft-ietf-radext-filter-06.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 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 (~~), 4 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 1 December 2006 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 May 10, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2006). 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 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 .............................................. 7 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 the 226 DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP 227 containing the NAS-Filter-Rule AVP. Since repairing the error will 228 probably require re-working the filter rules, the originating peer 229 should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error 230 and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal 231 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 6. Security Considerations 246 This specification describes the use of RADIUS for purposes of 247 authentication, authorization and accounting. Threats and security 248 issues for this application are described in [RFC3579] and [RFC3580]; 249 security issues encountered in roaming are described in [RFC2607]. 251 This document specifies a new attribute that can be included in 252 existing RADIUS packets, which are protected as described in 253 [RFC3579] and [RFC3576]. See those documents for a more detailed 254 description. 256 A NAS-Filter-Rule attribute sent by a RADIUS server may not be 257 understood by the NAS which receives it. A legacy NAS not compliant 258 with this specification may silently discard the NAS-Filter-Rule 259 attribute while permitting the user to access the network. This can 260 lead to users improperly receiving unfiltered access to the network. 261 As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a 262 NAS that is known to support it. 264 7. References 266 7.1. Normative references 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", RFC 2119, March, 1997. 271 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 272 Authentication Dial In User Service (RADIUS)", RFC 2865, June 273 2000. 275 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 276 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 278 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 279 Network Access Server Application", RFC 4005, August 2005. 281 7.2. Informative references 283 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 284 Implementation in Roaming", RFC 2607, June 1999. 286 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 287 "Dynamic Authorization Extensions to Remote Authentication 288 Dial In User Service (RADIUS)", RFC 3576, July 2003. 290 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 291 Authentication Protocol (EAP)", RFC 3579, September 2003. 293 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 294 802.1X Remote Authentication Dial In User Service (RADIUS) 295 Usage Guidelines", RFC3580, September 2003. 297 [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, 298 "RADIUS Attributes for Filtering and Redirection", Internet 299 draft (work in progress), draft-ietf-radext-filter- 300 rules-01.txt, June 2006. 302 Acknowledgments 304 The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg 305 Weber, Pasi Eronen, David Mitton and David Nelson for contributions 306 to this document. 308 Authors' Addresses 310 Paul Congdon 311 Hewlett Packard Company 312 HP ProCurve Networking 313 8000 Foothills Blvd, M/S 5662 314 Roseville, CA 95747 316 EMail: paul.congdon@hp.com 317 Phone: +1 916 785 5753 318 Fax: +1 916 785 8478 320 Mauricio Sanchez 321 Hewlett Packard Company 322 HP ProCurve Networking 323 8000 Foothills Blvd, M/S 5559 324 Roseville, CA 95747 326 EMail: mauricio.sanchez@hp.com 327 Phone: +1 916 785 1910 328 Fax: +1 916 785 1815 330 Bernard Aboba 331 Microsoft Corporation 332 One Microsoft Way 333 Redmond, WA 98052 335 EMail: bernarda@microsoft.com 336 Phone: +1 425 706 6605 337 Fax: +1 425 936 7329 339 Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at ietf- 361 ipr@ietf.org. 363 Disclaimer of Validity 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 368 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 369 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 370 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Copyright Statement 375 Copyright (C) The IETF Trust (2006). This document is subject to the 376 rights, licenses and restrictions contained in BCP 78, and except as 377 set forth therein, the authors retain all their rights. 379 Acknowledgment 381 Funding for the RFC Editor function is currently provided by the 382 Internet Society. 384 Open issues 386 Open issues relating to this specification are tracked on the 387 following web site: 389 http://www.drizzle.com/~aboba/RADEXT/