idnits 2.17.1 draft-ietf-radext-filter-01.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 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 329. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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-00 Summary: 5 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 20 August 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 March 10, 2007. 33 Copyright Notice 35 Copyright (C) The Internet Society 2006. 37 Abstract 39 This document defines the NAS-Filter-Rule attribute within the Remote 40 Authentication Dial In User Service (RADIUS), equivalent to the 41 Diameter NAS-Filter-Rule AVP described in RFC 4005. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Terminology ..................................... 3 47 1.2 Requirements Language ........................... 3 48 1.3 Attribute Interpretation ........................ 3 49 2. NAS-Filter-Rule Attribute ............................. 4 50 3. Table of Attributes ................................... 5 51 4. Diameter Considerations ............................... 5 52 5. IANA Considerations ................................... 5 53 6. Security Considerations ............................... 5 54 7. References ............................................ 6 55 7.1 Normative References ............................ 6 56 7.2 Informative References .......................... 6 57 ACKNOWLEDGMENTS .............................................. 7 58 AUTHORS' ADDRESSES ........................................... 7 59 Intellectual Property Statement............................... 7 60 Disclaimer of Validity........................................ 8 61 Full Copyright Statement ..................................... 8 62 1. Introduction 64 This document defines the NAS-Filter-Rule attribute within the Remote 65 Authentication Dialin User Service (RADIUS) which has the same 66 functionality as the Diameter NAS-Filter-Rule AVP (400) defined in 67 [RFC4005] Section 6.6. This attribute may prove useful for 68 provisioning of filter rules. 70 While [RFC2865] Section 5.11 defines the Filter-Id attribute (11), 71 this requires that the NAS be pre-populated with the desired filters. 72 However, in situations where the server operator does not know which 73 filters have been pre-populated, it useful to specify filter rules 74 explicitly. 76 1.1. Terminology 78 This document uses the following terms: 80 Network Access Server (NAS) 81 A device that provides an access service for a user to a network. 83 RADIUS server 84 A RADIUS authentication server is an entity that provides an 85 authentication service to a NAS. 87 RADIUS proxy 88 A RADIUS proxy acts as an authentication server to the NAS, and a 89 RADIUS client to the RADIUS server. 91 1.2. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 1.3. Attribute Interpretation 99 If a NAS conforming to this specification receives an Access-Accept 100 packet containing a NAS-Filter-Rule attribute which it cannot apply, 101 it MUST act as though it had received an Access-Reject. [RFC3576] 102 requires that a NAS receiving a Change of Authorization Request 103 (CoA-Request) reply with a CoA-NAK if the Request contains an 104 unsupported attribute. It is recommended that an Error-Cause 105 attribute with value set to "Unsupported Attribute" (401) be included 106 in the CoA-NAK. As noted in [RFC3576], authorization changes are 107 atomic so that this situation does not result in session termination 108 and the pre-existing configuration remains unchanged. As a result, 109 no accounting packets should be generated. 111 2. NAS-Filter-Rule Attribute 113 Description 115 This attribute indicates filter rules to be applied for this user. 116 Zero or more NAS-Filter-Rule attributes MAY be sent in Access- 117 Accept, CoA-Request, or Accounting-Request packets. 119 The NAS-Filter-Rule attribute is not intended to be used 120 concurrently with any other filter rule attribute, including 121 Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and 122 SHOULD NOT appear in the same RADIUS packet. If a Filter-Id 123 attribute is present, then implementations of this specification 124 MUST silently discard NAS-Filter-Rule attributes, if present. 126 Where more than one NAS-Filter-Rule attribute with the same Tag 127 field value is included in a RADIUS packet, the String field of 128 the attributes are to be concatenated to form a single filter. As 129 noted in [RFC2865] Section 2.3, "the forwarding server MUST NOT 130 change the order of any attributes of the same type", so that 131 RADIUS proxies will not reorder NAS-Filter-Rule attributes. 133 A summary of the NAS-Filter-Rule Attribute format is shown below. 134 The fields are transmitted from left to right. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type | Length | Tag | String... 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Type 144 TBD 146 Length 148 >=4 150 Tag 152 The Tag field is one octet, and is used to identify the filter 153 rule that is represented. Each filter rule being represented MUST 154 utilize a unique Tag field value. Where a single filter rule 155 exceeds 253 octets in length, the filter rule may be encoded 156 across multiple NAS-Filter-Rule attributes, each with the same Tag 157 value. 159 String 161 The String field is one or more octets. It contains filter rules 162 in the IPFilterRule syntax defined in [RFC3588] Section 4.3. 163 [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a 164 robust implementation SHOULD support the field as undistinguished 165 octets. 167 3. Table of Attributes 169 The following table provides a guide to which attributes may be found 170 in which kinds of packets, and in what quantity. 172 Access- Access- Access- Access- CoA- Acct- 173 Request Accept Reject Challenge Req Req # Attribute 174 0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule 176 The following table defines the meaning of the above table entries. 178 0 This attribute MUST NOT be present in the packet. 179 0+ Zero or more instances of this attribute MAY be 180 present in the packet. 181 0-1 Zero or one instance of this attribute MAY be 182 present in the packet. 184 4. Diameter Considerations 186 [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the 187 same functionality as the RADIUS NAS-Filter-Rule attribute. In order 188 to support interoperability, Diameter/RADIUS gateways will need to be 189 configured to translate RADIUS attribute TBD to Diameter AVP 400 and 190 vice-versa. Where a Diameter NAS-Filter-Rule AVP contains a filter 191 rule larger than 253 octets, Diameter/RADIUS gateways translate the 192 AVP to multiple RADIUS NAS-Filter-Rule attributes, each with the same 193 Tag field value. Similarly, when multiple RADIUS NAS-Filter-Rule 194 attributes are received with the same Tag field value, the String 195 fields of the attributes are concatenated together and encoded as the 196 value in a single Diameter NAS-Filter-Rule AVP. Note that since a 197 Diameter AVP can be larger than the maximum RADIUS packet size 198 (4096), translation from Diameter to RADIUS may not be possible in 199 all cases. 201 5. IANA Considerations 203 This specification does not create any new registries. 205 This document uses the RADIUS [RFC2865] namespace, see 206 . Allocation of four 207 updates for the section "RADIUS Attribute Types" is requested. The 208 RADIUS attributes for which values are requested are: 210 TBD - NAS-Filter-Rule 212 6. Security Considerations 214 This specification describes the use of RADIUS for purposes of 215 authentication, authorization and accounting. Threats and security 216 issues for this application are described in [RFC3579] and [RFC3580]; 217 security issues encountered in roaming are described in [RFC2607]. 219 This document specifies a new attribute that can be included in 220 existing RADIUS packets, which are protected as described in 221 [RFC3579] and [RFC3576]. See those documents for a more detailed 222 description. 224 A NAS-Filter-Rule attribute sent by a RADIUS server may not be 225 understood by the NAS which receives it. A legacy NAS not compliant 226 with this specification may silently discard the NAS-Filter-Rule 227 attribute while permitting the user to access the network. This can 228 lead to users improperly receiving unfiltered access to the network. 229 As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a 230 NAS that is known to support it. 232 7. References 234 7.1. Normative references 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", RFC 2119, March, 1997. 239 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 240 Authentication Dial In User Service (RADIUS)", RFC 2865, June 241 2000. 243 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 244 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 246 [RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 3629, 247 November 2003. 249 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 250 Network Access Server Application", RFC 4005, August 2005. 252 7.2. Informative references 254 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 255 Implementation in Roaming", RFC 2607, June 1999. 257 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 258 "Dynamic Authorization Extensions to Remote Authentication 259 Dial In User Service (RADIUS)", RFC 3576, July 2003. 261 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 262 Authentication Protocol (EAP)", RFC 3579, September 2003. 264 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 265 802.1X Remote Authentication Dial In User Service (RADIUS) 266 Usage Guidelines", RFC3580, September 2003. 268 [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, 269 "Filter Attributes", Internet draft (work in progress), draft- 270 ietf-radext-filter-rules-00.txt, February 2006. 272 Acknowledgments 274 The authors would like to acknowledge Greg Weber of Cisco and David 275 Nelson of Enterasys. 277 Authors' Addresses 279 Paul Congdon 280 Hewlett Packard Company 281 HP ProCurve Networking 282 8000 Foothills Blvd, M/S 5662 283 Roseville, CA 95747 285 EMail: paul.congdon@hp.com 286 Phone: +1 916 785 5753 287 Fax: +1 916 785 8478 289 Mauricio Sanchez 290 Hewlett Packard Company 291 HP ProCurve Networking 292 8000 Foothills Blvd, M/S 5559 293 Roseville, CA 95747 295 EMail: mauricio.sanchez@hp.com 296 Phone: +1 916 785 1910 297 Fax: +1 916 785 1815 298 Bernard Aboba 299 Microsoft Corporation 300 One Microsoft Way 301 Redmond, WA 98052 303 EMail: bernarda@microsoft.com 304 Phone: +1 425 706 6605 305 Fax: +1 425 936 7329 307 Intellectual Property Statement 309 The IETF takes no position regarding the validity or scope of any 310 Intellectual Property Rights or other rights that might be claimed to 311 pertain to the implementation or use of the technology described in 312 this document or the extent to which any license under such rights 313 might or might not be available; nor does it represent that it has 314 made any independent effort to identify any such rights. Information 315 on the procedures with respect to rights in RFC documents can be 316 found in BCP 78 and BCP 79. 318 Copies of IPR disclosures made to the IETF Secretariat and any 319 assurances of licenses to be made available, or the result of an 320 attempt made to obtain a general license or permission for the use of 321 such proprietary rights by implementers or users of this 322 specification can be obtained from the IETF on-line IPR repository at 323 http://www.ietf.org/ipr. 325 The IETF invites any interested party to bring to its attention any 326 copyrights, patents or patent applications, or other proprietary 327 rights that may cover technology that may be required to implement 328 this standard. Please address the information to the IETF at ietf- 329 ipr@ietf.org. 331 Disclaimer of Validity 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 336 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 337 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 338 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Copyright Statement 343 Copyright (C) The Internet Society (2006). This document is subject 344 to the rights, licenses and restrictions contained in BCP 78, and 345 except as set forth therein, the authors retain all their rights. 347 Acknowledgment 349 Funding for the RFC Editor function is currently provided by the 350 Internet Society. 352 Open issues 354 Open issues relating to this specification are tracked on the 355 following web site: 357 http://www.drizzle.com/~aboba/RADEXT/