idnits 2.17.1 draft-ietf-radext-filter-02.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 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 357. ** 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) == Unused Reference: 'RFC3629' is defined on line 273, but no explicit reference was found in the text ** 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 (~~), 3 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 October 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 April 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 ................................... 6 53 6. Security Considerations ............................... 6 54 7. References ............................................ 7 55 7.1 Normative References ............................ 7 56 7.2 Informative References .......................... 7 57 ACKNOWLEDGMENTS .............................................. 7 58 AUTHORS' ADDRESSES ........................................... 8 59 Intellectual Property Statement............................... 9 60 Disclaimer of Validity........................................ 9 61 Full Copyright Statement ..................................... 9 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 non- 127 zero Tag field value is included in a RADIUS packet, the String 128 field of the attributes are to be concatenated to form a single 129 filter. As noted in [RFC2865] Section 2.3, "the forwarding server 130 MUST NOT change the order of any attributes of the same type", so 131 that 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 used to identify the filter rule that is 153 represented; the length of the Tag field is one octet and it MUST 154 always be present. The Tag field value MUST be in the range 155 0x01-0x3F; NAS-Filter-Rule attributes with a Tag field value of 156 0x00 are ignored upon receipt. 158 Where a single filter rule is less than or equal to 252 octets in 159 length, it MUST be encoded with a tag value of '0' (0x30) and MUST 160 NOT be split between multiple NAS-Filter-Rule attributes. Where a 161 single filter rule is split into multiple NAS-Filter-Rule 162 attributes, the attributes SHOULD be sent consecutively, without 163 intervening attributes with another Tag field value. On receipt, 164 attributes with a Tag value of '0' (0x30) MUST NOT be concatenated 165 to form a single filter rule. 167 Where a single filter rule exceeds 252 octets in length, the rule 168 MUST be encoded across multiple NAS-Filter-Rule attributes, each 169 with the same Tag value which MUST NOT be '0' (0x30). Tag values 170 MUST be unique for each filter rule present in a RADIUS packet 171 with the exception of a Tag value of '0' (0x30), which may be used 172 in multiple attributes, each describing a single filter rule. 174 String 176 The String field is one or more octets. It contains filter rules 177 in the IPFilterRule syntax defined in [RFC3588] Section 4.3. A 178 robust implementation SHOULD support the field as undistinguished 179 octets. 181 3. Table of Attributes 183 The following table provides a guide to which attributes may be found 184 in which kinds of packets, and in what quantity. 186 Access- Access- Access- Access- CoA- Acct- 187 Request Accept Reject Challenge Req Req # Attribute 188 0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule 190 The following table defines the meaning of the above table entries. 192 0 This attribute MUST NOT be present in the packet. 193 0+ Zero or more instances of this attribute MAY be 194 present in the packet. 195 0-1 Zero or one instance of this attribute MAY be 196 present in the packet. 198 4. Diameter Considerations 200 [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the 201 same functionality as the RADIUS NAS-Filter-Rule attribute. In order 202 to support interoperability, Diameter/RADIUS gateways will need to be 203 configured to translate RADIUS attribute TBD to Diameter AVP 400 and 204 vice-versa. Where a Diameter NAS-Filter-Rule AVP contains a filter 205 rule larger than 252 octets, Diameter/RADIUS gateways translate the 206 AVP to multiple RADIUS NAS-Filter-Rule attributes, each with the same 207 Tag field value not equal to '0' (0x30). Similarly, when multiple 208 RADIUS NAS-Filter-Rule attributes are received with the same Tag 209 field value not equal to '0' (0x30), the String fields of the 210 attributes are concatenated together and encoded as the value in a 211 single Diameter NAS-Filter-Rule AVP. RADIUS NAS-Filter-Rule 212 attributes with a Tag field of '0' (0x30) are encoded as distinct 213 Diameter NAS-Filter-Rule AVPs. 215 Note that a translated Diameter message can be larger than the 216 maximum RADIUS packet size (4096). Where a Diameter/RADIUS gateway 217 receives a Diameter message containing a NAS-Filter-Rule AVP that is 218 too large to fit into a RADIUS packet, the Diameter/RADIUS gateway 219 will respond to the originating Diameter peer with the 220 DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP 221 containing the NAS-Filter-Rule AVP. Since repairing the error will 222 probably require re-working the filter rules, the originating peer 223 should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error 224 and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal 225 error. 227 5. IANA Considerations 229 This specification does not create any new registries. 231 This document uses the RADIUS [RFC2865] namespace, see 232 . Allocation of one 233 update for the section "RADIUS Attribute Types" is requested. The 234 RADIUS attribute for which a value is requested is: 236 TBD - NAS-Filter-Rule 238 6. Security Considerations 240 This specification describes the use of RADIUS for purposes of 241 authentication, authorization and accounting. Threats and security 242 issues for this application are described in [RFC3579] and [RFC3580]; 243 security issues encountered in roaming are described in [RFC2607]. 245 This document specifies a new attribute that can be included in 246 existing RADIUS packets, which are protected as described in 247 [RFC3579] and [RFC3576]. See those documents for a more detailed 248 description. 250 A NAS-Filter-Rule attribute sent by a RADIUS server may not be 251 understood by the NAS which receives it. A legacy NAS not compliant 252 with this specification may silently discard the NAS-Filter-Rule 253 attribute while permitting the user to access the network. This can 254 lead to users improperly receiving unfiltered access to the network. 256 As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a 257 NAS that is known to support it. 259 7. References 261 7.1. Normative references 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", RFC 2119, March, 1997. 266 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 267 Authentication Dial In User Service (RADIUS)", RFC 2865, June 268 2000. 270 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 271 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 273 [RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 3629, 274 November 2003. 276 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 277 Network Access Server Application", RFC 4005, August 2005. 279 7.2. Informative references 281 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 282 Implementation in Roaming", RFC 2607, June 1999. 284 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 285 "Dynamic Authorization Extensions to Remote Authentication 286 Dial In User Service (RADIUS)", RFC 3576, July 2003. 288 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 289 Authentication Protocol (EAP)", RFC 3579, September 2003. 291 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 292 802.1X Remote Authentication Dial In User Service (RADIUS) 293 Usage Guidelines", RFC3580, September 2003. 295 [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, 296 "Filter Attributes", Internet draft (work in progress), draft- 297 ietf-radext-filter-rules-00.txt, February 2006. 299 Acknowledgments 301 The authors would like to acknowledge Greg Weber of Cisco and David 302 Nelson of Enterasys. 304 Authors' Addresses 306 Paul Congdon 307 Hewlett Packard Company 308 HP ProCurve Networking 309 8000 Foothills Blvd, M/S 5662 310 Roseville, CA 95747 312 EMail: paul.congdon@hp.com 313 Phone: +1 916 785 5753 314 Fax: +1 916 785 8478 316 Mauricio Sanchez 317 Hewlett Packard Company 318 HP ProCurve Networking 319 8000 Foothills Blvd, M/S 5559 320 Roseville, CA 95747 322 EMail: mauricio.sanchez@hp.com 323 Phone: +1 916 785 1910 324 Fax: +1 916 785 1815 326 Bernard Aboba 327 Microsoft Corporation 328 One Microsoft Way 329 Redmond, WA 98052 331 EMail: bernarda@microsoft.com 332 Phone: +1 425 706 6605 333 Fax: +1 425 936 7329 335 Intellectual Property Statement 337 The IETF takes no position regarding the validity or scope of any 338 Intellectual Property Rights or other rights that might be claimed to 339 pertain to the implementation or use of the technology described in 340 this document or the extent to which any license under such rights 341 might or might not be available; nor does it represent that it has 342 made any independent effort to identify any such rights. Information 343 on the procedures with respect to rights in RFC documents can be 344 found in BCP 78 and BCP 79. 346 Copies of IPR disclosures made to the IETF Secretariat and any 347 assurances of licenses to be made available, or the result of an 348 attempt made to obtain a general license or permission for the use of 349 such proprietary rights by implementers or users of this 350 specification can be obtained from the IETF on-line IPR repository at 351 http://www.ietf.org/ipr. 353 The IETF invites any interested party to bring to its attention any 354 copyrights, patents or patent applications, or other proprietary 355 rights that may cover technology that may be required to implement 356 this standard. Please address the information to the IETF at ietf- 357 ipr@ietf.org. 359 Disclaimer of Validity 361 This document and the information contained herein are provided on an 362 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 363 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 364 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 365 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 366 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Copyright Statement 371 Copyright (C) The Internet Society (2006). This document is subject 372 to the rights, licenses and restrictions contained in BCP 78, and 373 except as set forth therein, the authors retain all their rights. 375 Acknowledgment 377 Funding for the RFC Editor function is currently provided by the 378 Internet Society. 380 Open issues 382 Open issues relating to this specification are tracked on the 383 following web site: 385 http://www.drizzle.com/~aboba/RADEXT/