idnits 2.17.1 draft-ietf-radext-filter-00.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 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 315. ** 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 16 June 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 December 10, 2006. 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 is included in a 127 RADIUS packet, the attributes MUST be consecutive and it is 128 assumed that the attributes are to be concatenated to form a 129 single filter list. As noted in [RFC2865] Section 2.3, "the 130 forwarding server MUST NOT change the order of any attributes of 131 the same type", so that RADIUS proxies will not reorder NAS- 132 Filter-Rule attributes. 134 A summary of the NAS-Filter-Rule Attribute format is shown below. 135 The fields are transmitted from left to right. 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type | Length | String... 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Type 145 TBD 147 Length 149 >=3 151 String 153 The string field is one or more octets. It contains filter rules 154 in the IPFilterRule syntax defined in [RFC3588] Section 4.3. 155 [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a 156 robust implementation SHOULD support the field as undistinguished 157 octets. 159 3. Table of Attributes 161 The following table provides a guide to which attributes may be found 162 in which kinds of packets, and in what quantity. 164 Access- Access- Access- Access- CoA- Acct- 165 Request Accept Reject Challenge Req Req # Attribute 166 0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule 168 The following table defines the meaning of the above table entries. 170 0 This attribute MUST NOT be present in the packet. 171 0+ Zero or more instances of this attribute MAY be 172 present in the packet. 173 0-1 Zero or one instance of this attribute MAY be 174 present in the packet. 176 4. Diameter Considerations 178 [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the 179 same functionality as the RADIUS NAS-Filter-Rule attribute. In order 180 to support interoperability, Diameter/RADIUS gateways will need to be 181 configured to translate RADIUS attribute TBD to Diameter AVP 400 and 182 vice-versa. Note that since a Diameter AVP can be larger than the 183 maximum RADIUS packet size (4096), this translation may not be 184 possible in all cases. 186 5. IANA Considerations 188 This specification does not create any new registries. 190 This document uses the RADIUS [RFC2865] namespace, see 191 . Allocation of four 192 updates for the section "RADIUS Attribute Types" is requested. The 193 RADIUS attributes for which values are requested are: 195 TBD - NAS-Filter-Rule 197 6. Security Considerations 199 This specification describes the use of RADIUS for purposes of 200 authentication, authorization and accounting. Threats and security 201 issues for this application are described in [RFC3579] and [RFC3580]; 202 security issues encountered in roaming are described in [RFC2607]. 204 This document specifies a new attribute that can be included in 205 existing RADIUS packets, which are protected as described in 206 [RFC3579] and [RFC3576]. See those documents for a more detailed 207 description. 209 A NAS-Filter-Rule attribute sent by a RADIUS server may not be 210 understood by the NAS which receives it. A legacy NAS not compliant 211 with this specification may silently discard the NAS-Filter-Rule 212 attribute while permitting the user to access the network. This can 213 lead to users improperly receiving unfiltered access to the network. 214 As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a 215 NAS that is known to support it. 217 7. References 219 7.1. Normative references 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", RFC 2119, March, 1997. 224 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 225 Authentication Dial In User Service (RADIUS)", RFC 2865, June 226 2000. 228 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 229 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 231 [RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 3629, 232 November 2003. 234 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 235 Network Access Server Application", RFC 4005, August 2005. 237 7.2. Informative references 239 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 240 Implementation in Roaming", RFC 2607, June 1999. 242 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 243 "Dynamic Authorization Extensions to Remote Authentication 244 Dial In User Service (RADIUS)", RFC 3576, July 2003. 246 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 247 Authentication Protocol (EAP)", RFC 3579, September 2003. 249 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 250 802.1X Remote Authentication Dial In User Service (RADIUS) 251 Usage Guidelines", RFC3580, September 2003. 253 [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, 254 "Filter Attributes", Internet draft (work in progress), draft- 255 ietf-radext-filter-rules-00.txt, February 2006. 257 Acknowledgments 259 The authors would like to acknowledge Greg Weber of Cisco, and David 260 Nelson of Enterasys. 262 Authors' Addresses 264 Paul Congdon 265 Hewlett Packard Company 266 HP ProCurve Networking 267 8000 Foothills Blvd, M/S 5662 268 Roseville, CA 95747 270 EMail: paul.congdon@hp.com 271 Phone: +1 916 785 5753 272 Fax: +1 916 785 8478 274 Mauricio Sanchez 275 Hewlett Packard Company 276 HP ProCurve Networking 277 8000 Foothills Blvd, M/S 5559 278 Roseville, CA 95747 280 EMail: mauricio.sanchez@hp.com 281 Phone: +1 916 785 1910 282 Fax: +1 916 785 1815 284 Bernard Aboba 285 Microsoft Corporation 286 One Microsoft Way 287 Redmond, WA 98052 289 EMail: bernarda@microsoft.com 290 Phone: +1 425 706 6605 291 Fax: +1 425 936 7329 293 Intellectual Property Statement 295 The IETF takes no position regarding the validity or scope of any 296 Intellectual Property Rights or other rights that might be claimed to 297 pertain to the implementation or use of the technology described in 298 this document or the extent to which any license under such rights 299 might or might not be available; nor does it represent that it has 300 made any independent effort to identify any such rights. Information 301 on the procedures with respect to rights in RFC documents can be 302 found in BCP 78 and BCP 79. 304 Copies of IPR disclosures made to the IETF Secretariat and any 305 assurances of licenses to be made available, or the result of an 306 attempt made to obtain a general license or permission for the use of 307 such proprietary rights by implementers or users of this 308 specification can be obtained from the IETF on-line IPR repository at 309 http://www.ietf.org/ipr. 311 The IETF invites any interested party to bring to its attention any 312 copyrights, patents or patent applications, or other proprietary 313 rights that may cover technology that may be required to implement 314 this standard. Please address the information to the IETF at ietf- 315 ipr@ietf.org. 317 Disclaimer of Validity 319 This document and the information contained herein are provided on an 320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 322 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 323 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 324 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 327 Copyright Statement 329 Copyright (C) The Internet Society (2006). This document is subject 330 to the rights, licenses and restrictions contained in BCP 78, and 331 except as set forth therein, the authors retain all their rights. 333 Acknowledgment 335 Funding for the RFC Editor function is currently provided by the 336 Internet Society. 338 Open issues 340 Open issues relating to this specification are tracked on the 341 following web site: 343 http://www.drizzle.com/~aboba/RADEXT/