248 M.Z. Hasanenhance security and effective functioning of an enterprise. For example, when auser attempts access to her enterprise intranet (via a laptop), the IEEE 802.1x -based NRAC may control the access. Once the access to the network is granted,accesses to, for example, a sensitive server may be controlled via an ARAC, whichis separate from the NRAC. Without proper integration of ARAC and NRAC(A/NRAC), it will be difﬁcult to enforce certain policies that enhance security. Forexample, a policy may dictate that if the user is accessing from a particular networksegment (remote or wireless), then certain actions on the sensitive server will not beauthorized. The integration will also be useful in a Cloud computing (Cloud) envi-ronment. Integrated or interoperable A/NRAC and Cloud RAC will be covered. Accesses to resources are typically controlled via policies managed by relevantpolicy management frameworks or systems. The policies are speciﬁed in a policyspeciﬁcation language (PSL). There is no single widely accepted industry standardPSL. The OASIS XACML (eXtensible Access Control Markup Language)  is anexample of an ARAC (authorization) PSL. The Cisco Common Classiﬁcation PolicyLanguage (C3PL)  is an example of an NRAC PSL. The policy model used inthese PSLs differs substantially. But it is possible to deﬁne a generic policyspeciﬁcation model and its elements (subject, resource, etc.). We will discuss amodel, where the PSL elements will have extended scope so that both ARAC andNRAC policies can be speciﬁed via a common PSL. The PSL elements are based onthat of XACML. Note that we do not propose any speciﬁc language, rather a genericdeﬁnition of PSL elements. A policy management framework may have multiple (execution or functional)components. Two of the major components are a policy decision point (PDP) and apolicy enforcement point (PEP). The access control decision is made by the PDP byexecuting multiple policies conﬁgured by a policy administrator. The PEP thenenforces the decision. The PDP and PEP can be distributed. PDP typically residesoutside of the resource access to which is being controlled, whereas the PEP residesembedded within the resource, such as an application or server or a network, whichincludes router, switch, network appliance, or network OS (control, data, andembedded management planes). In certain cases, PDP can be embedded within theresource concerned. An application or ARAC PEP usually resides in the applicationresource being access controlled. But it may be possible to embed an ARAC PEP inthe network. We will discuss aspects of network-embedded NRAC PEP (such asPEPs for enforcing network QoS within a network device) and network-based ornetwork-embedded ARAC PEP (such as ﬁrewall ALG: application level gateway).The above concepts will be discussed employing detail use cases and with the aid ofsequence diagrams showing interactions between PDP, PEP, and other componentsor entities. The rest of the chapter is organized as follows: RAC policy management frame-work, including deﬁnition of PSL elements, is discussed in Sect. 12.2. ARAC anduse cases are discussed in Sect. 12.3. In Sect. 12.4, we discuss NRAC, whichincludes NRAC related to controlling user or (mobile) device access to network andNRAC applied on packets as they traverse through network resources. ARAC andNRAC joint operation is covered in Sect. 12.5, which includes interoperable or
12 Application and Network Resource Access Control 249integrated ARAC and NRAC and network-based or network-embedded ARAC.The aspects of RAC in Cloud are covered in Sect. 12.6. We conclude in Sect. 18.104.22.168 RAC FrameworkA framework to support A/NRAC consists of the following core components:• A/NRAC policy management framework, which includes the following: ○ Policy speciﬁcation language (PSL) ○ Policy execution components consisting of the following (distributed) com- ponents (we focus on aspects of PDP and PEP only): – Policy Decision Point (PDP): A PDP is a policy execution component that interprets or executes policies speciﬁed in a PSL to make decisions. A PDP typically resides outside the resource, access to which is being controlled. – Policy Enforcement Point (PEP): A PEP is the policy execution compo- nent that enforces policy decisions. A PEP is embedded in the resource, access to which is being controlled. – Policy Information Point (PIP): A PIP stores various information about entities and resources (such as an enterprise directory). – Policy Administration Point (PAP): A PAP is used by policy administra- tors to manage RAC policies.• Protocols or messaging used to convey access control information, including policy information between various components of A/NRAC, such as 802.1x  and RADIUS  for NRAC The policy speciﬁcation elements are as follows, which are based on that of theXACML, but deﬁnitions are extended to cover both ARAC and NRAC:• Subject: A subject is a human or nonhuman entity that attempts to access and manipulate resources. The subject may include other (nonhuman) logical enti- ties, such as automated systems, software programs, applications, IP packets or resources, etc. A few examples of extended deﬁnition of a (logical) subject is provided below: – A resource: Consider a web server (WS) or an application executing on the WS (in the DMZ: demilitarized zone of an enterprise). A RAC policy may dictate that the WS is not allowed direct access to a DB server located in a data center. In this case, the WS is a subject with respect to the DB server. In other words, a resource assumes the role of a subject. A policy speciﬁcation will explicitly identify it as a subject (as will be shown below). In the same way, a human user is identiﬁed by a name or ID or credentials; a logical subject can be identiﬁed accordingly, for example, by an IP address or an IP address and port combination or a URI (Universal Resource Identiﬁer). – A logical entity: An IP packet or Ethernet frame (discussed further below).
250 M.Z. HasanFig. 12.1 Generic RAC ﬂow• Resource: A resource is an entity access to which is controlled. A resource does not necessarily have to be a single or tangible entity. It can be a logical and aggre- gated entity. For example, an enterprise intranet or network segment can be a resource. A resource can have subresources (hierarchical or containment rela- tionship with parent resource) to which RAC policies may be applied. For exam- ple, Router/Switch → Link → Queue → Priority Queue or DB Server → DB instance → A Table.• Action: Actions, such as create/read/write/update/delete/access that a subject is attempting to perform on the resources.• Policy Rule Condition: Conditions on subjects and resources that should be checked by PDP or PEP before performing speciﬁed actions.• Effect: If policy condition is satisﬁed, then the policy may dictate that the requested action is allowed, denied, or indeterminate.• Obligation (PEP Policy): If the action is allowed or denied, what other actions are performed on the resources at the enforcement point (enforced by the PEP). <this is ﬁne > For example, if a subject is allowed (effect) the requested write action on a resource, then the (PEP) policy may dictate that further action (obli- gation) is performed by the PEP, such as log the action in a ﬁle with associated data or email a message that the action has been performed. Another example, if a subject is allowed access to a network, then the PEP is obligated (via PEP policy) to place the subject (packets or frames originating from subject’s device) on a particular VLAN. A generic RAC execution ﬂow is shown in Fig. 12.1. As we show later, the PDP and PEP components can be distributed over thenetwork. A PEP is embedded within the resource, access to which is being con-trolled, whereas a PDP may or may not be embedded. As shown in Fig. 12.1 andFig. 12.2 a PDP has to manage access control policies for multitude of resources
12 Application and Network Resource Access Control 251Fig. 12.2 Network examplethat include different types of resources (many different types of application andnetwork resources). Hence instead of having a PDP for each type of resource, suchas one for web servers and another for DB servers, it is better to support a RACdeployment architecture where the PDP is centralized2 and consolidated for manyresource types in an enterprise.12.3 Application RACThe application resource access control deals with application, server, and storageor L7 resource access control. An example of an ARAC policy is as follows:• Subject: A DB user, such as a physician.• Resources: A DB server and medical record tables.• Action: Write on a table.• Policy Rule Condition: If the subject ID/group = “physician” && Computer_ IP_address = “192.168.10.*”.• Effect: Permit.• Obligation: Encrypt data before writing and log the action. When a subject accesses a resource (over the network), an application-speciﬁcprotocol may be used, such as the example shown in Fig. 12.3, where the protocolis the MySQL protocol . When a subject attempts access (a DB in this example)and perform action on the resource (DB table), the PEP embedded within the DBserver will interpret the message (e.g., COM_QUERY “sql stmnt” ) carried in theprotocol, extract content, and send it to the PDP for policy decision.2 Note that “centralized” does not preclude use of distributed or clustered architecture.
252 M.Z. HasanFig. 12.3 ARAC ﬂow Each application type (as shown in Fig. 12.2) may have its own native and uniquefeatures, such as data structure or model, protocol, or messaging format supported.Hence there is a need for application-speciﬁc PEP. The PDP can be separated intoan application feature agnostic component if standard-based framework (such as theXACML for authorization function of RAC or other standard) is supported.12.4 Network RACIn this section, two aspects of NRAC are discussed: controlling human or end device(such as a mobile device) access to network and access control applied on networktrafﬁc (IP packets, Ethernet frames, etc.). Controlling user or end device access toan enterprise network is known as the network access control or NAC. We general-ize NAC as NRAC to cover any network resource access control, in addition tohuman user or end device access control to network.12.4.1 User Access Control to NetworkWhen a subject (a human user via a computer) attempts access to a network (enterpriseintranet or any network segment), the PEP in a network access device3 (NAD), to whichthe subject’s device is connected to, enforces network access control policies with theaid of an NRAC PDP. We provide a few use cases and relevant policies below.3 A NAD is an access switch or a wireless access point.
12 Application and Network Resource Access Control 253 Consider the network shown in Fig. 12.2 and the following policy speciﬁcations:1. Policy 1: (a) Subject: Employee 1. (b) Resources: Networks (network segments): Intranet, Internet, and Cloud; Servers: All. (c) Action: The subject attempts access to speciﬁed resources anytime. (d) Policy Rule Condition: If subject belongs to a group authorized to the speciﬁed resources, then apply effect. (e) Effect: Permit access request. (f ) Obligation (network PEP policy): Allow the subject on VLAN 10 (allows access to all the resources above, assuming that all the network segments are on or reachable via the VLAN 10). The subject is assigned Gold priority in the network, that is, any packet or frame originating from the subject’s device is marked by the PEP with proper QoS marking , and they are queued on a network interface queue allocated for Gold priority.2. Policy 2: (a) Subject: Employee 2. (b) Resources: Networks (network segments): enterprise intranet only; Servers: HR servers. (c) Action: The subject attempts access to speciﬁed resources anytime. (d) Policy Rule Condition: If subject belongs to a group authorized to the speciﬁed resources, then apply effect. (e) Effect: Permit access request. (f ) Obligation (network PEP policy): Allow subject on VLAN 30 and apply Silver QoS.3. Policy 3: (a) Subject: Partner. (b) Resources: Networks (network segments): Server 1 only and public Internet. (c) Action: The subject attempts access to speciﬁed resources anytime. (d) Policy Rule Condition: If subject device IP address = “10.10.20.*”, then apply effect (assuming the IP address is from a preassigned partner pool). (e) Effect: Permit access request. (f ) Obligation (network PEP policy): Allow subject on VLAN 50 and apply Bronze QoS. Above policy and user information has to be conﬁgured into relevant PDP andPIP and network PEP policies (possibly as conﬁguration or conﬁguration templates)into NADs. Assume that Employee 1 attempts access to his enterprise network.
254 M.Z. HasanFig. 12.4 802.1x-based NRACIf his computer supports 802.1x  supplicant4 and his network supports802.1x-based access, then the policy execution sequence will be as shown inFig. 12.4 (details of the protocols involved is outside the scope). A few notes based on the discussion above:• The policy execution framework is distributed with multiple components distrib- uted over the network, where the NRAC PEPs are embedded within the network devices and the PDP is centralized. In the later section, we will show that certain NRAC PDP can be embedded in a network device (network OS control, data, or management plane).• A policy speciﬁcation may have multiple components, the main policy compo- nent is executed in PDP and the local enforcement policies are executed in PEP. The obligation is the local PEP policy.• Policies are conﬁgured statically but applied dynamically. PEP or obligation policies may also be instantiated dynamically from a conﬁguration template and then applied. For example, in the above examples, a subject-speciﬁc VLAN or QoS is conﬁgured dynamically when the subject is granted access into the network. Subject-related parameters (such as IP or MAC address) might be4 A supplicant is a component of IEEE 802.1x that resides in an end device that attempts access toan enterprise network. An authenticator (a PEP) of IEEE 802.1x resides in an NAD that interceptsframes from the supplicant (subject) and forwards it to a PDP (a RADIUS sever) using the RADIUSprotocol . The authenticator then enforces PEP policies based on the decision from the PDP.This is a simpliﬁed description; details are outside the scope.
12 Application and Network Resource Access Control 255 identiﬁed and conﬁguration template instantiated dynamically. For example, consider the policy 3 above. If Server 1 IP address is 10.10.20.2 and partner’s computer IP address has been identiﬁed as 10.10.30.5, then an ACL (access con- trol list) “permit ip host 10.10.30.5 10.10.20.2” will be instantiated and applied dynamically at the NAD port connecting the subject’s computer. Once the sub- ject logs out or stays inactive (for speciﬁed duration), the instantiation may be removed dynamically.12.4.2 Access Control Applied to PacketFrom the perspective of policy application on IP packets or Ethernet or other frames,a packet or frame can be considered a (logical) subject. A packet or frame may“belong” to a subject, human, or end device, where the context about the subject isset as a VLAN, source MAC, or IP address in packets or frames originating from thesubject’s device. The packet or frame (in what follows, we will refer to packet only)with the context set then becomes a subject. As a packet traverses through a net-work, policies such as QoS or ACL may be applied on the packet based on thecontext in the packet. Through the course of packet’s traversal through various net-work segments (L2, L3, MPLS, Optical, NAT, etc.), the original context may bemapped to some other context, such as a VLAN mapped to MPLS VPN VRF  orcertain IP header packet information, for example, DSCP or ToS QoS markinginformation  copied to the outer header of an IPSEC tunnel packet. The map-pings preserve the context of the subject so that subject (or subject group)-speciﬁcnetwork policies (QoS, ACL, Firewall, etc.) can be applied at various segments ofthe network. The context of a packet does not necessarily have to be a user or an enddevice speciﬁc, rather application or service speciﬁc. For example, all VoIP (Voiceover IP) packets are policies controlled on network links (proper bandwidth andQoS policies applied). In order to provide a consistent model of policy manage-ment, we can consider a packet identiﬁed by its context(s) as a subject attempting toaccess network resources (such as links, queues, or network segments). We provide a few use cases below:1. Policy 1: Apply QoS policy on packets. (a) Subject: Any packet. (b) Resource: A router/switch interface (link). (c) Action: Access to interface. The subject is attempting access to an interface. (d) Policy Rule Condition: If packet is marked (context) with (DiffServ ) DSCP = EF (Expedited Forwarding) or ﬁve tuple (source address, destination address, source port, destination port, protocol number) in the subject matches with speciﬁed rule (ACL), then apply effect. (e) Effect: Permit packet into the interface. (f) Obligation: Place subject onto the priority Q on the interface (as shown in Fig. 12.5).
256 M.Z. HasanFig. 12.5 Queue servicingFig. 12.6 Network QoS policy example2. Policy 2: Apply ﬁrewall policy on packets. (a) Subject: Any packet. (b) Resource: Firewall interface (“inside” or protected side). (c) Action: Access to resource. The subject is attempting access to the resource (cross the “inside” interface of a ﬁrewall). (d) Policy Rule Condition: If URL in the HTTP packets contains exe/com/bat. (e) Effect: Deny the subject through the interface. (f) Obligation: Reset connection and log action (ﬁrewall PEP performs this action).
12 Application and Network Resource Access Control 257Fig. 12.7 Firewall policy exampleFig. 12.8 Network-embedded PDP Examples of policy speciﬁcations for Policy 1 and 2 above using Cisco C3PL are shown in Fig. 12.6 and Fig. 12.7, respectively. Note that the speciﬁcations do notconform to the PSL model described above. The PEP enforcing network policies (QoS, ACL, etc.) obviously is embedded ina network device. The PDP for network policy control may also be embedded in anetwork device or network OS. For example, as shown in Fig. 12.8, the NRAC PEPs
258 M.Z. Hasanare embedded within the network device interfaces (interface cards), whereas thePDP that controls policies on multiple interfaces is embedded in the control or man-agement plane of a network OS.12.5 ARAC and NRAC Joint OperationNRAC and ARAC frameworks are typically separate. But it is possible to integratethem in two ways:1. Integrate or interoperate frameworks and operations of ARAC and NRAC.2. Network-based or network-embedded ARAC capabilities.12.5.1 Integrated or Interoperable ARAC and NRACWe describe the above two options via use cases. The use case in Fig. 12.9 showsthat once the application resource authorization decision is made, the PDP cancommunicate network policy (conﬁguration) decision as obligation to relevantFig. 12.9 Integration of ARAC and NRAC
12 Application and Network Resource Access Control 259network devices. For example, in the use case, if the subject is about to insert alarge amount of data in a DB, then the network policy may guarantee, limit, orshape bandwidth at relevant locations of network. Another example, when securityincidence is detected by an application PEP, an obligation policy may dictate thatrelevant network ports are blocked for the subject (IP address or IP addresspreﬁx).12.6 Network-Based or Network-Embedded ARACA use case involving network-based or embedded ARAC PEP is shown inFig. 12.10. As we have described above, application-speciﬁc PEPs typically reside withinthe application resource being access controlled. But it is possible to embed ARACPEPs in appropriate locations of a network. Existing ﬁrewalls already support theso-called ALG (application level gateway), such as SQL*Net, FTP, H.323, SIP, etc.But these (state-based) ﬁrewalls usually check ﬁve ﬁelds of TCP/UDP trafﬁc (sourceIP, destination IP, source port, destination port, protocol). The ALGs can also keeptrack of incoming dynamic ports (e.g., for data channels of the protocols mentionedFig. 12.10 Network-based ARAC
260 M.Z. Hasanabove). The ALGs do not usually inspect deep into the packets as an applicationPEP will do. There are the challenges in embedding ARAC PEPs inside the net-work, which includes the following:• Deep packet inspection (DPI) is a technically challenging task.• States (such as TCP states) should be managed in intermediate points in network where network-based ARAC PEPs are deployed.• There are too many applications and relevant protocols and messaging formats, including the ones that are proprietary and vendor speciﬁc.• Trafﬁc may be encrypted (unless connections are terminated and decrypted at the points where ARAC PEPs are embedded).12.7 RAC in CloudWe provide a brief overview of how the ARAC and NRAC concepts discussedabove can be applied in a Cloud environment. The A/NRAC concepts discussed will mostly apply in the case of an enterpriseIT-owned and IT-operated private Cloud . In the case of a hybrid Cloud [8–10],where an enterprise consumes resources from a public Cloud , there can be anumber of options:1. An enterprise can use its ARAC/NRAC systems to authorize a subject to the Cloud, including what kind of action the subject can perform in the Cloud. For example, a subject can be authorized into a public Cloud when the subject logs onto the network using the NRAC framework described in Sect. 12.4.1, where the PEP policy (obligation) authorizes the subject onto a speciﬁc VLAN, trafﬁc in which is allowed into a public Cloud (as shown in Fig. 12.2) used by the sub- ject’s enterprise. Once in the Cloud, further authorization may be necessary, such as whether the subject is authorized to create a VM in the Cloud or not. The latter capability requires integration of enterprise NRAC/ARAC with that of the Cloud (the details of how to achieve this effectively is beyond the scope and a topic of further investigation or research).2. A public Cloud provider can offer ARAC/NRAC services for the resources that enterprise subjects use. An enterprise ARAC/NRAC can then be interfaced with this service. Note that typical solutions support a single sign-on (SSO) mechanism. But thatis not enough. Looking at the concepts and use cases discussed above, it should beobvious that ARAC and NRAC are not just about human user’s identity and creden-tial management (as in SSO frameworks) but also about resource (in the extendeddeﬁnition we provided above) management, network contexts, and policies (VLAN,ACL, QoS, etc.).
12 Application and Network Resource Access Control 26112.8 ConclusionApplication and network resource access control is very important for effective andsecure functioning of an enterprise. We have discussed policy management frame-works used to support A/NRAC in an enterprise, focusing on policy execution com-ponents PDP and PEP and policy speciﬁcation elements. The frameworks for ARACand NRAC evolve separately (especially as a consequence of separation of enter-prise administration domains, such as compute, storage, network, security, WAN,etc.). We have shown that integrated or interoperated ARAC and NRAC will facili-tate advanced RAC, including advance security for resource access. Employingdetail use cases, we have shown why and how ARAC and NRAC should have com-mon policy management model and how they can be integrated or interfaced witheach other to support a common framework for L1 to L7 integrated resource accesscontrol. Note that integration or interoperation does not preclude existence of sepa-rate administration domains. A PEP (ARAC or NRAC) by nature is embeddedwithin the resource being access controlled. We have shown how embedded andnon-embedded RAC components interact with each other for managing and enforc-ing RAC. Typically, an application ARAC PEP is embedded within the applicationresource being access controlled. In certain cases, it may be beneﬁcial to embedARAC PEPs in proper locations of a network, such as a ﬁrewall or any networklocation away from network segments with sensitive resources. We have shown usecases for network-embedded ARAC PEP. We have also discussed brieﬂy how theA/NRAC concepts described can be applied in a Cloud environment. Further R&D is needed for advanced integration of ARAC and NRAC, whichamong other issues should include a standard and common model for policyspeciﬁcation and language. The XACML could be a starting point to look into. Asshown above, there are wide varieties of protocols and message formats that areused for interactions between subject and PEP, and PEP and PDP. A common andstandard wrapper protocol and messaging standard will be desirable. It should beobvious that conﬁgurability and programmability are two different features. A usercan conﬁgure a PDP or PEP with policies speciﬁed in a policy speciﬁcation lan-guage. But users can conﬁgure policies related to existing features only. With pro-grammability, support for new features can be programmed, a capability usuallymissing from network devices. A programmable network or network device willfacilitate programmable PEPs to be deployed in a network on demand and any time(postdeployment of the network device). Programmable ARAC PEP is especiallydesirable, for example, consider ﬁrewall ALG (which is an ARAC PEP) discussedabove. An enterprise that has deployed a ﬁrewall with limited set of ALG supportmay want to inspect a new application it has deployed. If the ﬁrewall was program-mable, the enterprise could program an ARAC PEP (ALG) and deploy on theﬁrewall.
262 M.Z. HasanReferences 1. IEEE 802.1x. http://www.ieee802.org/1/pages/802.1x.html 2. XACML (eXtensible access control markup language). http://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=xacml 3. Cisco common classiﬁcation policy language. http://www.cisco.com/en/US/docs/routers/ access/cisco_router_and_security_device_manager/24/software/user/guide/C3PL.html 4. Remote Authentication Dial In User Service (RADIUS), RFC 2865. http://tools.ietf.org/html/ rfc2865 5. MySQL protocol. http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol 6. Conﬁguration guidelines for DiffServ service classes, RFC 4594. http://tools.ietf.org/html/ rfc4594 7. MPLS VPN VRF. http://en.wikipedia.org/wiki/VRF 8. NIST deﬁnition of cloud. http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf 9. Hasan MZ et al (2011) Seamless cloud abstraction, models and interfaces. In: Proceedings of the ITU/IEEE Kaleidoscope conference, Cape Town10. Hasan MZ et al (2011) Network abstraction for enterprise and SP class cloud: seamless cloud abstraction and interfaces, IETF draft. http://trac.tools.ietf.org/area/app/trac/attachment/wiki/ Clouds/draft-rfc-seamless-Cloud-masum-01.txt