| Internet-Draft | Policy-based Access Control | October 2022 |
| Ma, et al. | Expires 26 April 2023 | [Page] |
This document defines two YANG modules for policy-based network access control, which provide consistent and efficient enforcement of network access control policies based on user-group identity. In addition, this document defines a mechanism to ease the maintenance of the mapping between a user-group ID and a set of IP/MAC addresses to enforce policy-based network access control. Finally, the document defines a RADIUS attribute that is used to communicate the user group identifier as part of identification and authorization information.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months 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."¶
This Internet-Draft will expire on 26 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
With the increased adoption of remote access technologies (e.g., Virtual Private Networks (VPNs)), Small- and Medium-size Businesses (SMBs) are increasingly adopting cloud-based security services to replace or complement on-premises security tools. Such tools are meant to facilitate access to Enterprise resources for authorized users from anywhere. However, from a technical standpoint, enabling large-scale employee mobility across many access locations induces a set of challenges compared to conventional network access management approaches, e.g.:¶
This document defines two YANG modules for policy-based Network Access Control [NIST-ABAC]. These modules are meant to ensure consistent enforcement of access control policies based on user-group identity. In addition, this document defines a mechanism to establish mapping between the user-group ID and IP/MAC addresses to execute the policy-based access control.¶
Also, the document defines a RADIUS attribute that used to communicate the user group identifier as part of identification and authorization information (Section 6).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The meanings of the symbols in tree diagrams are defined in [RFC8340].¶
The document uses the terms defined in [RFC8519].¶
In the current version of the draft, the term "user" refers also to the host that actually connect to a network. Also, The term "user" refers to any user of the network. As such, servers, terminals, and other devices are also classified and assigned to their respective user-groups. Future versions of the document will call out specifically whether a user or a user's host are concerned.¶
The network needs to recognize the users' identities regardless of the change of the IP addresses of the device they use to connected to the network. Then, the network maps the users to their access authorization rights. As discussed in the introduction, because there is a large number of users and the IP addresses of the same user are in different network segments, deploying a network access control policy for each IP address or network segment is heavy workload. An alternative approach is to configure user groups to classify users (and their devices) and associate ACLs with user groups so that users in each group can share a group of ACL rules. This approach greatly reduces the workload of the administrator and optimizes the ACL resources on the device that behaves as a PEP (Policy Enforcement Point) [RFC3198]. The Network ACLs (NACLs) can be provisioned on devices using specific mechanisms, such as [RFC8519] or [I-D.dbb-netmod-acl].¶
Network access control policies may need to vary over time. For example, companies may restrict/grant employees access to specific resources (internal and/or external resources) during work hours, while another policy is adopted during off-hours and weekends. A network administrator may also require to enforce traffic shaping (Section 2.3.3.3 of [RFC2475]) and policing (Section 2.3.3.4 of [RFC2475]) during peak hours in order not to affect other data services.¶
To provide real-time and consistent enforcement of access control policies, the following functional entities and interfaces are involved:¶
The Security Controller is responsible for implementing the YANG module defined in Section 5.1 and maintains the user-to-"user-group" mapping with attributes information. If necessary, the Security Controller retrieves the access permissions from the PDP and pushes the required user-group access control policies to relevant PEPs that need them.¶
The Security Controller exposes a RESTCONF [RFC8040] or NETCONF [RFC6241] interface to the PDP.¶
The PEP is the central entity which is responsible for implementing the YANG module defined in Section 5.2 and maintaining Access Control Lists, and enforcing appropriate policies. A PEP maps incoming packets to their associated user-group IDs, and acts on the user-group IDs. The policies are expressed as user-group (not IP or MAC address) IDs so as to decouple the user identity from the network addresses of the user's device. If the PEP also co-locates with the user authentication device, it maintains the mapping between the user-group IDs and the IP or MAC address.¶
Multiple PEPs can be involved in a network.¶
A PEP exposes a NETCONF interface to the Security Controller.¶
A PEP may be collocated with a UAD.¶
Figure 1 provides the overall architecture and procedure for policy-based access control management.¶
+-----------------+
| Orchestrator |
+-+-------------+-+
Service | |
======================|=============|==============
Network +----+---+ ++---------+
| PDP +--------+Security |
(Step 1)| | +----+Controller|
+----+---+ | +-+---+----+
| | | |
+----+-------+-+ | |
| AAA | | |
| Server | | |
+--------------+ | |
| | (Step 2)
| |
(Step 4) +------+-+ |
----------------
(Step 3) ///// | | | \\\\\
+-------+ /// | | | \\\
|User #1+---------------------+ | | | \\
+-------+ || +--+-+ +--+-+ +-+-----+ |
Site 1 || | | | User | ||
|| |PEP | |Authentication| ||
|| | | | Device (UAD) | ||
+--------+ || +----+ +--------------+ |
|User #2 +--------------------+ (Step 5) //
+--------+ \\\ ///
\\\\\ /////
----------------
In reference to Figure 1, the following typical flow is experienced:¶
The user-group ID is an identifier that represents the collective identity of a group of users. It is determined by a set of pre-defined policy criteria (e.g., source IP address, geolocation data, time of day, or device certificate). Users may be moved to different user-groups if their composite attributes, environment, and/or local enterprise policy change.¶
A user is authenticated, and classified at the network ingress, and assigned to a user-group. A user's group membership may change as aspects of the user change. For example, if the user-group membership is determined solely by the source IP address, then a given user's user-group ID will change when the user moves to a new IP address that falls outside of the range of addresses of the previous user-group.¶
This document does not make an assumption how groups are defined. Such considerations are deployment specific and are out of scope. However, and for illustration purposes, Table 1 shows an example of how user-group definitions may be characterized. User-groups may share several common criteria. That is, user-group criteria are not mutually exclusive. For example, the policy criteria of user-groups R&D Regular and R&D BYOD may share the same set of users that belong to the R&D organization, and differ only in the type of clients (firm-issued clients vs. users' personal clients). Likewise, the same user may be assigned to different user-groups depending on the time of day or the type of day (e.g., weekdays versus weekends), etc.¶
+--------------+------------+--------------------------------+
| Group Name | Group ID | Group Definition |
+--------------+------------+--------------------------------+
| R&D | 10 | R&D employees |
+--------------+------------+--------------------------------+
| R&D BYOD | 11 | Personal devices of R&D |
| | | employees |
+--------------+------------+--------------------------------+
| Sales | 20 | Sales employees |
+--------------+------------+--------------------------------+
| VIP | 30 | VIP employees |
+--------------+------------+--------------------------------+
| Workflow | 40 | IP addresses of Workflow |
| | | resource servers |
+--------------+------------+--------------------------------+
| R&D Resource | 50 | IP addresses of R&D resource |
| | | servers |
+--------------+------------+--------------------------------+
|Sales Resource| 54 | IP addresses of Sales resource |
| | | servers |
+--------------+------------+--------------------------------+
Figure 3 provide an overview of the tree structure of the "ietf-ucl-group" module.¶
module: ietf-ucl-group
+--rw ucl-groups
+--rw user-group* [group-id]
+--rw group-id uint32
+--rw role? identityref
+--rw user* [user-name]
+--rw user-name string
+--rw address-grouping-mapping
| +--rw address* [address-id]
| +--rw address-id uint32
| +--rw ipv4-address? inet:ipv4-prefix
| +--rw ipv6-address? inet:ipv6-prefix
| +--rw mac-address? yang:mac-address
+--rw access-locations
| +--rw location* [location-id]
| +--rw location-id string
| +--rw address? string
| +--rw postal-code? string
+--rw accessed-devices? identityref
+--rw start-time? yang:date-and-time
+--rw end-time? yang:date-and-time
This module is defined as a standalone module and used to establish on the Security Controller the mapping between group-id and associated attributes such as role, location, IP address, MAC address, accessed resources, access period. Attributes are assigned to specific users, and then determine access based on those attributes. These attributes could include a user's position or role, but may also include their location, the time of day, and other factors.¶
This module imports [RFC6991].¶
<CODE BEGINS> file="ietf-ucl-group@2022-10-14.yang"
module ietf-ucl-group {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ucl-group";
prefix uclg;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types, Section 3";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>";
description
"This YANG module defines XXX.
Copyright (c) 2022 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.";
revision 2022-10-14 {
description
"Initial revision.";
reference
"RFC XXXX: A Policy-based Network Access Control";
}
identity device-type {
description
"Base identity for device type.";
}
identity role-type {
description
"Identity for role group type.";
}
identity smartphone {
base device-type;
description
"Identity for the smartphone terminal device.";
}
identity tablet {
base device-type;
description
"Identity for the tablet accessed device.";
}
identity laptop {
base device-type;
description
"Identity for the laptop accessed device.";
}
identity pc {
base device-type;
description
"Identity for the PC accessed device.";
}
identity finance {
base role-type;
description
"Identity for the finance role.";
}
identity sales {
base role-type;
description
"Identity for the sales role.";
}
identity research {
base role-type;
description
"Identity for the research role.";
}
identity developer {
base role-type;
description
"Identity for the developer role.";
}
identity vip {
base role-type;
description
"Identity for the VIP role.";
}
identity visitor {
base role-type;
description
"Identity for the guest role.";
}
container ucl-groups {
description
"Defines the UCL groups";
list user-group {
key "group-id";
description
"The user group with which the traffic flow is
associated can be identified by a user-group id.";
leaf group-id {
type uint32;
description
"The ID of the group which is used to
identified a user group. This identifier is
unique within the scope of a network.";
}
leaf role {
type identityref {
base role-type;
}
description
"The common role of this user-group.";
}
list user {
key "user-name";
description
"List of users indexed by their user-name.";
leaf user-name {
type string {
length "1..max";
}
description
"A special name given to a user to uniquely identify them.";
}
container address-grouping-mapping {
description
"Defines lists of IP and MAC addresses.";
list address {
key "address-id";
description
"The possible accessed address of the user, identified
by the address-id.";
leaf address-id {
type uint32;
description
"A unique address-id that identifies a user's accessed
address.";
}
leaf ipv4-address {
type inet:ipv4-prefix;
description
"The IPv4 address prefix of the user's accessed IP.";
}
leaf ipv6-address {
type inet:ipv6-prefix;
description
"The IPv6 address prefix of the user's accessed IP.";
}
leaf mac-address {
type yang:mac-address;
description
"The mac address of the user's accessed device.";
}
}
}
container access-locations {
description
"Defines lists of locations.";
list location {
key "location-id";
description
"List of locations.";
leaf location-id {
type string {
length "1..max";
}
description
"Location id information.";
}
leaf address {
type string;
description
"User detailed address information.";
}
leaf postal-code {
type string;
description
"Postal code information of the user's
accessed location.";
}
}
}
leaf accessed-devices {
type identityref {
base device-type;
}
description
"The user's accessed device type.";
}
leaf start-time {
type yang:date-and-time;
description
"The start time that the user belongs to
this group ID.";
}
leaf end-time {
type yang:date-and-time;
description
"The end time that the user belongs to
this group ID.";
}
}
}
}
}
<CODE ENDS>¶
Figure 4 provides the tree strcuture of the "ietf-ucl-acl" module.¶
module: ietf-ucl-acl
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw (user-control-groups)? {match-on-user-group}?
+--:(source-match)
| +--rw source-match
| +--rw (match)?
| +--:(user-group)
| | +--rw user-group-id? uint32
| +--:(IP-address)
| +--rw ipv4-network? inet:ipv4-prefix
| +--rw ipv6-network? inet:ipv6-prefix
+--:(destination-match)
+--rw destination-match
+--rw (match)?
+--:(user-group)
| +--rw user-group-id? uint32
+--:(IP-address)
+--rw ipv4-network? inet:ipv4-prefix
+--rw ipv6-network? inet:ipv6-prefix
augment /acl:acls/acl:acl/acl:aces/acl:ace:
+--rw time-range {match-on-user-group}?
+--rw (time-range-type)?
+--:(periodic-range)
| +--rw month* lmap:month-or-all
| +--rw day-of-month* lmap:day-of-months-or-all
| +--rw day-of-week* lmap:weekday-or-all
| +--rw hour* lmap:hour-or-all
+--:(absolute-range)
+--rw start-time? yang:date-and-time
+--rw end-time? yang:date-and-time
This module specifies an extension to the IETF-ACL model [RFC8519] such that the UCL group index may be referenced by augmenting the "matches" node. Four types of UCL group are supported:¶
This module imports [RFC6991], [RFC8194] and [RFC8519].¶
<CODE BEGINS> file="ietf-ucl-acl@2022-10-14.yang"
module ietf-ucl-acl {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ucl-acl";
prefix uacl;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types, Section 3";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
import ietf-lmap-common {
prefix lmap;
reference
"RFC 8194: A YANG Data Model for LMAP Measurement Agents";
}
import ietf-access-control-list {
prefix acl;
reference
"RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)";
}
organization
"IETF OPSWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>";
description
"This YANG module defines XXX.
Copyright (c) 2022 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.";
revision 2022-10-14 {
description
"Initial revision.";
reference
"RFC XXXX: A Policy-based Network Access Control";
}
feature match-on-user-group {
description
"The device can support matching on user groups.";
}
grouping match-range-source-destination {
description
"A grouping used for source/desttination macthes.";
choice match {
description
"Add a new match choice for the user group.";
case user-group {
leaf user-group-id {
type uint32;
description
"The matched user group ID that uniquely identifies
a user group.";
}
}
case IP-address {
leaf ipv4-network {
type inet:ipv4-prefix;
description
"The matched IPv4 address prefix.";
}
leaf ipv6-network {
type inet:ipv6-prefix;
description
"The matched IPv6 address prefix.";
}
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
if-feature "match-on-user-group";
description
"Add new match types.";
choice user-control-groups {
description
"Add new source and destination matches based on the
user group.";
container source-match {
description
"The source matched information.";
uses match-range-source-destination;
}
container destination-match {
description
"The destination matched information.";
uses match-range-source-destination;
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace" {
if-feature "match-on-user-group";
description
"Add a new parameter to the Access Control Entry (ACE).";
container time-range {
description
"This container defines when the access control
entry rules are in effect.
If it is not configured, the access control entry
is immediately and always in effect.";
choice time-range-type {
description
"Choice based on the type of the time range.";
case periodic-range {
leaf-list month {
type lmap:month-or-all;
description
"A set of months at which ace will trigger.
The wildcard means all months.";
}
leaf-list day-of-month {
type lmap:day-of-months-or-all;
description
"A set of days of the month at which ace will
trigger. The wildcard means all days of a month.";
}
leaf-list day-of-week {
type lmap:weekday-or-all;
description
"A set of weekdays at which ace will trigger.
The wildcard means all weekdays.";
}
leaf-list hour {
type lmap:hour-or-all;
description
"A set of hours at which ace will trigger. The
wildcard means all hours of a day.";
}
}
case absolute-range {
leaf start-time {
type yang:date-and-time;
description
"The time when the ace starts to take effect.";
}
leaf end-time {
type yang:date-and-time;
description
"The time when the ace ends to take effect.";
}
}
}
}
}
}
<CODE ENDS>¶
The User-Access-Group-ID RADIUS attribute and its embedded TLVs are defined with globally unique names. The definition of the attribute follows the guidelines in Section 2.7.1 of [RFC6929]. This attribute is used to indicate the user-group ID to be used by the UAD. When the User-Access-Group-ID RADIUS attribute is present in the RADIUS Access-Accept, the system applies the related access control to the users after it authenticates.¶
The value fields of the Attribute are encoded in clear and not encrypted as, for example, Tunnel- Password Attribute [RFC2868].¶
The User-Access-Group-ID Attribute is of type "string" as defined in Section 3.5 of [RFC8044].¶
The User-Access-Group-ID Attribute MAY appear in a RADIUS Access-Accept packet. It MAY also appear in a RADIUS Access-Request packet as a hint to the RADIUS server to indicate a preference. However, the server is not required to honor such a preference.¶
The User-Access-Group-ID Attribute MAY appear in a RADIUS CoA-Request packet.¶
The User-Access-Group-ID Attribute MAY appear in a RADIUS Accounting-Request packet.¶
The User-Access-Group-ID Attribute MUST NOT appear in any other RADIUS packet.¶
The User-Access-Group-ID Attribute is structured as follows:¶
Type
241
Length
This field indicates the total length, in octets, of all fields of
this attribute, including the Type, Length, Extended-Type, and the
"Value".
Extended-Type
TBA1
Value
This field contains the user group ID.¶
The User-Access-Group-ID Attribute is associated with the following identifier: 241.TBA1.¶
The following table provides a guide as what type of RADIUS packets that may contain User-Access-Group-ID Attribute, and in what quantity.¶
Access- Access- Access- Challenge Acct. # Attribute Request Accept Reject Request 0+ 0+ 0 0 0+ 241.TBA1 User-Access-Group-ID CoA-Request CoA-ACK CoA-NACK # Attribute 0+ 0 0 241.TBA2 User-Access-Group-ID¶
The following table defines the meaning of the above table entries:¶
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet.¶
The YANG modules specified in this document defines schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in this YANG module that are writable, creatable, and deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations to these data nodes could have a negative effect on network and security operations.¶
<<add-more-about privacy considerations as the modules manipulate PII data.>>¶
RADIUS-related security considerations are discussed in [RFC2865].¶
This document targets deployments where a trusted relationship is in place between the RADIUS client and server with communication optionally secured by IPsec or Transport Layer Security (TLS) [RFC6614].¶
This document registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following registration has been made.¶
URI: urn:ietf:params:xml:ns:yang:ietf-ucl-group
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.¶
URI: urn:ietf:params:xml:ns:yang:ietf-ucl-acl
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.¶
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].¶
name: ietf-ucl-group
namespace: urn:ietf:params:xml:ns:yang:ietf-ucl-group
prefix: uclg
maintained by IANA: N
reference: RFC XXXX¶
name: ietf-ucl-acl
namespace: urn:ietf:params:xml:ns:yang:ietf-ucl-acl
prefix: uacl
maintained by IANA: N
reference: RFC XXXX¶
IANA is requested to assign a new RADIUS attribute typs from the IANA registry "Radius Attribute Types" [RADIUS-Types]:¶
| Value | Description | Data Type | Reference |
|---|---|---|---|
| 241.TBA1 | User-Access-Group-ID | string | This-Document |
This work has benefited from the discussions of User-group-based Security Policy over the years. In particular, [I-D.you-i2nsf-user-group-based-policy] and [I-D.yizhou-anima-ip-to-access-control-groups] provide mechanisms to establish the mapping between the IP address/prefix of user and access control group ID.¶
Jianjie You, Myo Zarny, Christian Jacquenet, Mohamed Boucadair, and Yizhou Li contributed to an earlier version of [I-D.you-i2nsf-user-group-based-policy]. We would like to thank the authors of that draft on modern network access control mechanisms for material that assisted in thinking about this document.¶