http://www.seanconvery.com/weblog/2006/12/20/a-de-jure-acl-format/ Ruminations on Identity Management for Networks Mon, 13 Oct 2008 11:41:30 +0000 http://wordpress.org/?v=2.6 http://www.seanconvery.com/weblog/2006/12/20/a-de-jure-acl-format/#comment-13297 Sean Convery » Blog Archive » ACLs for Everyone! Tue, 12 Jun 2007 20:42:21 +0000 http://www.seanconvery.com/weblog/2006/12/20/a-de-jure-acl-format/#comment-13297 [...] The IETF draft I’ve been tracking that defines a common format to communicate IP ACLs via RADIUS is now an official RFC. 4849 has a nice ring to it, hopefully it will become part of the networking and security vernacular like 1918 or 2827. Remember the RFC doesn’t mean anything until the industry builds support into its products. If you are a customer of Cisco, Juniper, Nortel or any other networking vendor I encourage you to ask for RFC 4849 support as soon as possible. Supporting it makes sense in almost all access devices: firewalls, wired switches, WLAN APs, and VPN gateways. Enabling role-based access control throughout your network is becoming less of a dream each day; RFC 4849 gets us one big step closer by defining a mechanism to support ACLs in heterogeneous network infrastructure. Here’s the abstract, scary that I get excited by this stuff: While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [...] [...] The IETF draft I’ve been tracking that defines a common format to communicate IP ACLs via RADIUS is now an official RFC. 4849 has a nice ring to it, hopefully it will become part of the networking and security vernacular like 1918 or 2827. Remember the RFC doesn’t mean anything until the industry builds support into its products. If you are a customer of Cisco, Juniper, Nortel or any other networking vendor I encourage you to ask for RFC 4849 support as soon as possible. Supporting it makes sense in almost all access devices: firewalls, wired switches, WLAN APs, and VPN gateways. Enabling role-based access control throughout your network is becoming less of a dream each day; RFC 4849 gets us one big step closer by defining a mechanism to support ACLs in heterogeneous network infrastructure. Here’s the abstract, scary that I get excited by this stuff: While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [...]

]]>