--- 1/draft-ietf-radext-filter-07.txt 2007-01-17 22:12:49.000000000 +0100 +++ 2/draft-ietf-radext-filter-08.txt 2007-01-17 22:12:49.000000000 +0100 @@ -1,16 +1,16 @@ Network Working Group Paul Congdon INTERNET-DRAFT Mauricio Sanchez Category: Proposed Standard Hewlett-Packard Company - Bernard Aboba -10 January 2007 Microsoft Corporation + Bernard Aboba +13 January 2007 Microsoft Corporation RADIUS Filter Rule Attribute By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -21,21 +21,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 10, 2007. + This Internet-Draft will expire on July 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). All rights reserved. Abstract While RFC 2865 defines the Filter-Id attribute, this requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not @@ -252,27 +252,38 @@ This specification describes the use of RADIUS for purposes of authentication, authorization and accounting. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]. This document specifies a new attribute that can be included in existing RADIUS packets, which are protected as described in [RFC3579] and [RFC3576]. See those documents for a more detailed description. - A NAS-Filter-Rule attribute sent by a RADIUS server may not be - understood by the NAS which receives it. A legacy NAS not compliant - with this specification may silently discard the NAS-Filter-Rule - attribute while permitting the user to access the network. This can - lead to users improperly receiving unfiltered access to the network. - As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a - NAS that is known to support it. + The security mechanisms supported in RADIUS and Diameter are focused + on preventing an attacker from spoofing packets or modifying packets + in transit. They do not prevent an authorized RADIUS/Diameter server + or proxy from modifying, inserting or removing attributes with + malicious intent. Filter attributes modified or removed by a + RADIUS/Diameter proxy may enable a user to obtain network access + without the appropriate filters; if the proxy were also to modify + accounting packets, then the modification would not be reflected in + the accounting server logs. + + Since the RADIUS protocol currently does not support capability + negotiation, a RADIUS server cannot automatically discover whether a + NAS supports the NAS-Filter-Rule attribute. A legacy NAS not + compliant with this specification may silently discard the NAS- + Filter-Rule attribute while permitting the user to access the + network. This can lead to users improperly receiving unfiltered + access to the network. As a result, the NAS-Filter-Rule attribute + SHOULD only be sent to a NAS that is known to support it. 7. References 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June