Secure modification of manufacturer usage description files based on device applications

TECHNICAL FIELD

This disclosure relates to using manufacturer usage descriptions to control network access of devices in a network.

BACKGROUND

An enterprise network connects computers and other devices within the network. Access to other networks, computers, or devices outside of the enterprise network is typically limited and controlled. Authorization for access outside of the enterprise network can be managed by access points, firewalls, or similar authorization devices that allow or deny access to/from devices on the network. Authorization may be implemented by using a policy that defines rules for specifying devices, types of access, and/or destinations that are permitted and/or prohibited for access outside of the enterprise network.

Some network devices can have predetermined usage descriptions that specify the description of the role of the device and various policies governing the behavior and permissions of the device. Predetermined usage descriptions can be referred to as being “manufacturer-driven” or “manufacturer-based” usage descriptions (MUDs) because they may indicate the manufacturer's operational requirements and/or intent for the corresponding network device.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a system for implementing secure modification of manufacturer usage description (MUD) files based on device applications, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 2</figref> is a functional diagram illustrating a device requesting applications from a manufacturer application service, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 3</figref> is a functional diagram illustrating a concatenated MUD file being provided based on device applications, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 4A</figref> is a diagram illustrating a concatenated MUD file based on aggregated MUD file portions, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 4B</figref> is a diagram illustrating a concatenated MUD file based on dynamically generated MUD file portions, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> is a ladder diagram illustrating operations performed by elements of the system for implementing secure modification of MUD files based on device applications, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart illustrating a method of secure modification of MUD files based on device applications, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram of a manufacturer application service apparatus for implementing secure modification of MUD files based on device applications, according to an example embodiment.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Presented herein are techniques for providing secure modification of MUD files based on device applications. In an example embodiment, a method for secure modification of MUD files may include obtaining (receiving) a request for one or more applications from a device. The method also includes providing (transmitting) to the device the one or more applications and a certification that includes an updated MUD identifier determined based on the one or more applications requested. The updated MUD identifier is associated with a concatenated MUD file that comprises individual MUD file portions for each of the one or more applications requested. The device is configured to request an updated device identifier using the certification. The updated device identifier includes the updated MUD identifier that is associated with the concatenated MUD file.

Example Embodiments

Manufacturer usage descriptions (MUD) provide a mechanism for a device manufacturer to embed a Uniform Resource Identifier (URI) in the device at the time the device is manufactured. During the device installation or onboarding in a network, the URI is emitted by the device to the appropriate entity in the network. The URI resolves or links to the device manufacturer's MUD file server to retrieve an associated MUD file for the device. The MUD file contains policies about the device that are defined by the device manufacturer. Typically, these policies include an access control policy that the network can use to create access control lists that restrict access (i.e., communication to and/or from) for the device to traffic that has been approved by the device manufacturer.

One way that the URI may be embedded with the device during manufacturing is within an X.509 certificate. An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. The standard is defined in Section 10 of The Internet Engineering Task Force (IETF) publication draft-ietf-opsawg-mud-11, which publication is hereby incorporated by reference in its entirety. When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network. This process ensures that all of the data packet traffic to and/or from the device will be subject to the access control policy.

However, one constraint on using manufacturer-embedded certificates (e.g., X.509 certificates) is that the certificate is not designed to change. Devices that are intended to be very constrained may not need any changes to their manufacturer-defined policies identified by the MUD URI from their embedded certificates. Multi-purpose devices, however, may have their intended behavior change based on the installation of new applications that provide new, different, and/or additional features to a device. Additionally, some Internet-of-Things (IoT) devices may be authorized by the IoT device manufacturer to download or install new applications from third parties after the IoT device has been onboarded or installed on the network. Accordingly, in these situations, the functionality associated with the newly installed applications on the device may not be permitted by the original policy identified by the MUD URI in the device's embedded certificate.

According to the principles of the example embodiments described herein, techniques for secure modification of a device's MUD file based on the applications that are installed on the device are provided. With these techniques, when applications are downloaded or installed at a device, a new MUD file and a new or substitute certificate for the device may be provided. In the example embodiments, rather than relying upon the network infrastructure to actively manage the installed applications and/or certificates, a trusted application provider or service may be configured to securely provide both the applications and a new embedded certificate that contains a new MUD URI that identifies a policy for the device that allows the appropriate access control to enable the functionality provided by the newly installed applications.

With reference made first to <figref idref="DRAWINGS">FIG. 1</figref>, <figref idref="DRAWINGS">FIG. 1</figref> is a diagram showing an example of a system <b>100</b> in which techniques for providing secure modification of MUD files based on device applications may be implemented. In this embodiment, system <b>100</b> includes an enterprise network <b>110</b> that may communicate over a communication network <b>130</b> with remote devices, including at least a manufacturer application service <b>140</b> and a MUD file server <b>150</b>. The enterprise network <b>110</b> includes at least one network device <b>112</b> (also referred to as device <b>112</b>), an access control device <b>114</b>, a MUD controller <b>116</b>, an authentication entity <b>118</b>, and an authentication, authorization, and accounting (AAA) server <b>120</b>. In this embodiment, enterprise network <b>110</b> is shown including a single network device <b>112</b>. In other embodiments, however, enterprise network <b>110</b> may include various additional network devices.

The term “network device” is meant to be interpreted broadly. For example, network devices may include various client devices employed by users within enterprise network <b>110</b>. Some examples of network devices may include cameras, interactive whiteboards, conference phones, smartphones, light bulbs and fixtures, outlets, televisions, media players, hubs or gateways, IoT devices, any device with network connectivity that may include sensors and/or actuators, or any other device with network connectivity and which performs a sensing, actuating or other function, and may also include instances of virtual machines or applications. However, one of ordinary skill in the art would readily recognize that the network device may be any type of device now known or hereinafter developed. Additionally, one of ordinary skill in the art would readily recognize that other network-capable devices may also be in enterprise network <b>110</b>.

Device <b>112</b> may be connected to an access control device <b>114</b>. Access control device <b>114</b> can be configured to permit or prohibit device <b>112</b> from communicating with other devices within enterprise network <b>110</b> and/or other devices outside of enterprise network <b>110</b>, for example, over communication network <b>130</b>. Some examples of access control device <b>114</b> may include an access point, switch, router, firewall, or other network security or authorization device that allows or denies access to/from devices on enterprise network <b>110</b>.

In an example embodiment, access control device <b>114</b> may be in communication with a MUD controller <b>116</b>. MUD controller <b>116</b> may be configured to implement various network security policies to devices on enterprise network <b>110</b>, including establishing a policy to access control device <b>114</b> for one or more network devices, including device <b>112</b>. A policy for device <b>112</b> may be based on predefined usage descriptions, such as those included in a MUD file, as described in more detail below. In some cases, MUD controller <b>116</b> may receive instructions, or request approval, from a network administrator for enterprise network <b>110</b>. For example, in some embodiments, AAA server <b>120</b> may provide authentication and authorization functions for enterprise network <b>110</b>.

Enterprise network <b>110</b> can be configured to communicate with one or more remote computers and/or devices over communication network <b>130</b>. Communication network <b>130</b> may be, for example, a local access network (LAN) or wide area network (WAN). Also, communication network <b>130</b> may be either wired, wireless, or a combination of wired and wireless. In an example embodiment, communication network <b>130</b> may be the Internet.

MUD controller <b>116</b> may be configured to implement one or more policies that provide rules regarding communication over communication network <b>130</b> by computers and/or devices on enterprise network <b>110</b>. For example, a policy implemented by MUD controller <b>116</b> may provide rules that restrict access to or from device <b>112</b> outside of enterprise network <b>110</b>. In some cases, access may also be restricted between various network devices within enterprise network <b>110</b>. The MUD controller <b>116</b> is in communication with a MUD file server <b>150</b>, via communication network <b>130</b>. According to the principles of the example embodiments, MUD file server <b>150</b> may store a plurality of MUD files associated with devices (e.g., a MUD file <b>152</b> associated with device <b>112</b>) as well as a plurality of MUD file portions (e.g., MUD file portions <b>154</b>, <b>156</b>, <b>158</b>, <b>160</b>) associated with different applications that may be installed on devices. For example, a device manufacturer application service <b>140</b> or another trusted third-party application service provider may be configured to provide applications for a device (e.g., applications <b>142</b>, <b>144</b>, <b>146</b>, <b>148</b>). The interactions between MUD controller <b>116</b>, manufacturer application service <b>140</b>, and MUD file server <b>150</b> are described in further detail below.

Manufacturer application service <b>140</b> includes a plurality of applications that may be downloaded or installed by a device to enable new, different, and/or different functionality for the device. In some embodiments, manufacturer application service <b>140</b> may be provided by a device manufacturer. In other embodiments, manufacturer application service <b>140</b> may be provided by a trusted third-party application service provider. In this embodiment, the plurality of applications that may be provided by manufacturer application service <b>140</b> include a first application <b>142</b> (App₁), a second application <b>144</b> (App₂), a third application <b>146</b> (App₃), and continuing for any additional number up to an nth application <b>148</b> (App_N). In an example embodiment, manufacturer application service <b>140</b> may be a server or other apparatus configured to provide applications for various devices, for example, as shown in reference to <figref idref="DRAWINGS">FIG. 7</figref> described below.

Additionally, in some embodiments, applications for a device may be provided through a private network, for example, via an enterprise application service. In such situations, a MUD file server for the private network may also be available to the enterprise application service for storing MUD files and MUD file portions for the devices and/or applications associated with the enterprise application service, according to the principles of the embodiments described herein.

As described in the example embodiments, MUD controller <b>116</b> may implement rules based on predefined usage descriptions for network devices. Predetermined usage descriptions can specify a description of the role of a device and various policies governing the behavior and network access permissions of the device. Such predetermined usage descriptions may be provided by the device's manufacturer in a MUD file. In a MUD file, the device's manufacturer explicitly describes the device and network access rules associated with the device (i.e., what its expected behavior is), such as in a standard eXtensible Markup Language (XML) or JavaScript Object Notation (JSON) Data Interchange Format file format. MUD controller <b>116</b> may create a security policy for the device described in the manufacturer's MUD file. For example, the MUD file may indicate that certain approved communications are allowed and all other communications are denied. MUD controller <b>116</b>, upon approval from the network administrator and/or AAA server <b>120</b>, may then merge the rules obtained from the MUD file into the existing network policies for enterprise network <b>110</b>.

In some embodiments, AAA server <b>120</b> may be optional. In addition, in other embodiments, functions of MUD controller <b>116</b> and AAA server <b>120</b> may be combined in a single apparatus or device.

The MUD controller <b>116</b> can retrieve MUD files from the MUD file server <b>150</b>. For example, device <b>112</b> can provide MUD controller <b>116</b> with a MUD identifier, such as a Uniform Resource Identifier (URI), that links to the device manufacturer's MUD file server <b>150</b> to retrieve the associated MUD file (e.g., MUD file <b>152</b> for device <b>112</b>). Accordingly, MUD controller <b>116</b> may retrieve one or more MUD files from MUD file server <b>150</b>. Each MUD file or MUD file portion may have usage descriptions for specific network devices or specific applications that are to be installed on devices. For example, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, MUD file server <b>150</b> includes device MUD file <b>152</b> containing predefined usage descriptions for device <b>112</b>, as well as a plurality of MUD file portions, including a first MUD file portion <b>154</b> containing predefined usage descriptions for first application <b>142</b> (App₁), a second MUD file portion <b>156</b> containing predefined usage descriptions for second application <b>144</b> (App₂), a third MUD file portion <b>158</b> containing predefined usage descriptions for third application <b>146</b> (App₃), and continuing for any additional number up to an nth MUD file portion <b>160</b> containing predefined usage descriptions for nth application <b>148</b> (App_N).

Additionally, enterprise network <b>110</b> may also include authentication entity <b>118</b>. Authentication entity <b>118</b> may be a server or other device that is configured to issue certificates to devices on enterprise network <b>110</b>. For example, in one embodiment, authentication entity <b>118</b> may be a Bootstrapping Remote Secure Key Infrastructures (BRSKI) registrar that is configured to issue X.509 certificates or provide other identity certification. In this example embodiment, authentication entity <b>118</b> may be part of enterprise network <b>110</b>. However, in other embodiments, authentication entity <b>118</b> may be a remote server or remote device that communicates with enterprise network <b>110</b> over communication network <b>130</b>. For example, functions of authentication entity <b>118</b> may also be provided by a device manufacturer service or another trusted third party application service provider that has been trusted to issue certificates or other identity certification.

Referring now to <figref idref="DRAWINGS">FIG. 2</figref>, a functional diagram illustrating device <b>112</b> requesting one or more applications from manufacturer application service <b>140</b> is shown according to an example embodiment. In some embodiments, device <b>112</b> may request to download or install one or more applications from manufacturer application service <b>140</b>. In this embodiment, device <b>112</b> may request to download or install first application <b>142</b> (App₁) and second application <b>144</b> (App₂) from manufacturer application service <b>140</b>. For example, IoT devices based on a particular operating system may request to download or install applications from the corresponding application store for that operating system. In another example, an IoT gateway device may install applications to assist in managing sensors or other devices attached to the gateway that are provided from the manufacturer and/or from third parties through a manufacturer or manufacturer-approved application service provider.

According to the principles of the example embodiments, manufacturer application service <b>140</b> or other trusted third party application service provider has information about the current state of devices that it supports and the applications that are installed on those devices. For example, when device <b>112</b> requests to download or install first application <b>142</b> (App₁) and second application <b>144</b> (App₂), manufacturer application service <b>140</b> has information about the applications installed on device <b>112</b> and the associated access requirements for those applications. Records related to the installed applications on a device may be maintained by manufacturer application service <b>140</b> or other trusted third party application service provider and/or may be maintained locally within the device's network, for example, enterprise network <b>110</b> of device <b>112</b>.

Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, a functional diagram illustrating a concatenated MUD file <b>300</b> being provided to MUD controller <b>116</b> based on the applications installed on device <b>112</b> is shown according to an example embodiment. As previously described, manufacturer application service <b>140</b> has information about the applications installed on device <b>112</b> (e.g., first application <b>142</b> (App₁) and second application <b>144</b> (App₂)) and the associated access requirements for those applications. As will be described in more detail below, manufacturer application service <b>140</b> generates a concatenated MUD file that includes all of the access control permissions that device <b>112</b> requires in order to enable the functionality of the applications installed on device <b>112</b>. For example, concatenated MUD file <b>300</b> includes the access control permissions that enable first application <b>142</b> (App₁) and second application <b>144</b> (App₂) to function on device <b>112</b> within enterprise network <b>110</b>. In some embodiments, manufacturer application service <b>140</b> may generate a concatenated MUD file based on the aggregation of a MUD file associated with a device and the additional MUD file portions for each of the installed applications on the device. Manufacturer application service <b>140</b> can provide the concatenated MUD file for storage at MUD file server <b>150</b>, where it may be retrieved by request of the appropriate MUD identifier (e.g., MUD URI). In other embodiments, a concatenated MUD file may be dynamically generated at MUD file server <b>150</b> based on information contained in a request for a MUD identifier (e.g., MUD URI).

In this embodiment, manufacturer application service <b>140</b> generates concatenated MUD file <b>300</b> that includes the combined access control permissions for device <b>112</b>, first application <b>142</b> (App₁), and second application <b>144</b> (App₂) and provides concatenated MUD file <b>300</b> to MUD file server <b>150</b> for storage. Upon obtaining (receiving) a request for concatenated MUD file <b>300</b> based on a corresponding MUD identifier (e.g., a MUD URI), MUD file server <b>150</b> may provide concatenated MUD file <b>300</b> to MUD controller <b>116</b>. MUD controller <b>116</b> may then implement the access control policy of concatenated MUD file <b>300</b> by establishing appropriate access control permissions at access control device <b>114</b> for device <b>112</b> with first application <b>142</b> (App₁), and second application <b>144</b> (App₂) installed.

According to the principles of the example embodiments, a concatenated MUD file, for example, concatenated MUD file <b>300</b>, may combine all of the access control permissions for the device and each application installed on that device. Accordingly, concatenated MUD files may be comprised of one or more MUD files and/or one or more MUD file portions. A MUD file may be a device MUD file, for example, MUD file <b>152</b> for device <b>112</b>, and MUD file portions may be new, different, and/or additional access control permissions that are needed by a specific application to enable that application's functionality on a given device, for example, MUD file portions <b>154</b>, <b>156</b>, <b>158</b>, <b>160</b> for applications <b>142</b>, <b>144</b>, <b>146</b>, <b>148</b>.

For example, a concatenated MUD file (e.g. concatenated MUD file <b>300</b>) may include access control lists that are combined based on the device MUD file and each MUD file portion for each installed application. In this example, each access control entity listed from the access control list of each MUD file and MUD file portion is combined into a new access control list for the concatenated MUD file. Additionally, no MUD file portions from an application may contain deny actions and any duplicate access control entities in the new access control list of the concatenated MUD file are removed.

In some embodiments, concatenated MUD files may be aggregated from a plurality of pre-existing MUD files and/or MUD file portions. In other embodiments, concatenated MUD files may be dynamically generated based on the particular combination of device and installed applications. <figref idref="DRAWINGS">FIG. 4A</figref> shows concatenated MUD file <b>300</b> that is based on aggregated MUD files and MUD file portions, according to an example embodiment. In this embodiment, concatenated MUD file <b>300</b> comprises MUD file <b>152</b> associated with device <b>112</b> and first MUD file portion <b>154</b> associated with first application <b>142</b> (App₁) and second MUD file portion <b>156</b> associated with second application <b>144</b> (App₂). That is, concatenated MUD file <b>300</b> includes the predefined usage descriptions for device <b>112</b>, as well as the new, additional, and/or different predefined usage descriptions for each application that is installed on device <b>112</b> (e.g., first application <b>142</b> (App₁) and second application <b>144</b> (App₂)). With this arrangement, concatenated MUD file <b>300</b> is configured to enable the functionality of the applications that have been installed on the device <b>112</b>.

In this embodiment, two applications (e.g., first application <b>142</b> (App₁) and second application <b>144</b> (App₂)) are installed on device <b>112</b>. However, the principles of the example embodiments apply to any number of applications that may be installed on a network device. In some embodiments, concatenated MUD file <b>300</b> may be generated based on a hash that identifies the particular combination of applications that have been installed on a device. For example, in an example embodiment, manufacturer application service <b>140</b> or other trusted third party application service provider may generate a hash for all combinations of applications that may be installed on a device and store a mapping of each hash to a corresponding concatenated MUD file that is comprised of the aggregated MUD file portions for each application in the combination. Each such concatenated MUD file may be stored at MUD file server <b>150</b> with a corresponding name or indicator for the file that includes the associated hash for that combination of applications that may be identified in the MUD URI. With this arrangement, when a device has a particular combination of applications installed or downloaded, the manufacturer application service <b>140</b> or other trusted third party application service provider may provide the MUD URI that contains the hash relevant for the combination of applications on the device so that the appropriate concatenated MUD file may be retrieved from MUD file server <b>150</b>.

In other embodiments, rather than generating all possible concatenated MUD files in advance, a concatenated MUD file may be dynamically generated upon request. <figref idref="DRAWINGS">FIG. 4B</figref> shows an example of concatenated MUD file <b>300</b> that has been dynamically generated. In this embodiment, a MUD URI may include a hash or other information to permit identification of the device and its installed applications. As shown in the embodiment of <figref idref="DRAWINGS">FIG. 4B</figref>, concatenated MUD file <b>300</b> is dynamically generated using a table or other stored data as a function of the identification of the device and installed applications. For example, a table or stored data may include only a plurality of hashes representing different combinations of applications installed on one or more devices, as explained above with reference to <figref idref="DRAWINGS">FIG. 4A</figref>. With this arrangement, access control permissions <b>400</b> for concatenated MUD file <b>300</b> are determined dynamically as a function of the requirements of the combination of device <b>112</b>, first application <b>142</b> (App₁), and second application <b>144</b> (App₂).

In some embodiments, a device may include one or more applications that are pre-loaded or pre-installed on the device by the manufacturer or a third party. In such circumstances, the device, for example, device <b>112</b>, may include a certificate or other device identifier that includes a MUD identifier (e.g., a MUD URI) associated with a modified initial MUD file for the device that includes one or more MUD file portions associated with each pre-loaded or pre-installed application on the device before it is on-boarded to the network. Subsequent installations or downloads of additional applications to the device are treated in the same manner as described herein, with the device's initial MUD file being replaced with the modified initial MUD file for the purposed of generating concatenated MUD files for the additionally installed or downloaded applications.

Referring now to <figref idref="DRAWINGS">FIG. 5</figref>, a sequence diagram illustrating a process <b>500</b> involving the transactional flow between elements of system <b>100</b> for implementing secure modification of MUD files based on device applications is shown according to an example embodiment. In this embodiment, process <b>500</b> begins with a network device (e.g., device <b>112</b>) being installed or onboarded onto network <b>110</b>. In some embodiments, device <b>112</b> may be manufactured with an initial device identifier. For example, the Institute of Electrical and Electronics Engineers (IEEE) has defined an 802.1AR standard that specifies Secure Device Identifiers (DeviDs) designed to be used as interoperable secure device authentication credentials with Extensible Authentication Protocol (EAP) and other industry standard authentication and provisioning protocols. A standardized device identity facilitates interoperable secure device authentication and simplifies secure device deployment and management.

A device with DevID capability incorporates a globally unique manufacturer provided Initial Device Identifier (IDevID), stored in a way that protects it from modification. The device may also support the creation of Locally Significant Device Identifiers (LDevIDs) by a network administrator. Each LDevID is bound to the device in a way that makes it infeasible for it to be forged or transferred to a device with a different IDevID without knowledge of the private key used to effect the cryptographic binding. LDevIDs can incorporate, and fully protect, additional information specified by the network administrator to support local authorization conventions.

In this embodiment, device <b>112</b> may use its initial device identifier (e.g., IDevID or LDevID) with a security authentication protocol, such as Transport Layer Security (TLS), IEEE 802.1X/EAP-TLS, Internet Key Exchange (IKEv2), or other acceptable security protocol, to authenticate itself to network <b>110</b> during installation or onboarding. For example, at an operation <b>502</b>, device <b>112</b> may provide its certificate or other initial device identifier to access control device <b>114</b>. The initial certification for device <b>112</b>, such as the initial device identifier or certificate (e.g., IDevID or LDevID), may include a MUD identifier. The MUD identifier (e.g., MUD URI) identifies the appropriate MUD file for device <b>112</b>. At an operation <b>503</b>, access control device <b>114</b> provides the MUD identifier (e.g., MUD URI) associated with the MUD file for the device (e.g., MUD file <b>152</b>) to MUD controller <b>116</b>.

At an operation <b>504</b>, MUD controller <b>116</b> may use the MUD identifier (e.g., MUD URI) provided by device <b>112</b> to request the associated MUD file (e.g., MUD file <b>152</b>) from MUD file server <b>150</b>. At an operation <b>506</b>, MUD file server <b>150</b> provides the appropriate MUD file for device <b>112</b> (e.g., MUD file <b>152</b>) to MUD controller <b>116</b>. At an operation <b>508</b>, MUD controller <b>116</b> provides the relevant access control permissions contained in MUD file <b>152</b> to access control device <b>114</b>. With this arrangement, device <b>112</b> is attached to network <b>110</b> via access control device <b>114</b> with the appropriate initial access control permissions on its ports to only permit communication that has been approved by MUD file <b>152</b>.

In some embodiments, a network device, such as device <b>112</b>, may be configured to download or install one or more applications to enable new, different, or additional functionalities for the device. For example, applications may be provided by manufacturer application service <b>140</b> or other trusted third party application service provider. In this embodiment, at an operation <b>510</b>, device <b>112</b> requests to download or install first application <b>142</b> (App₁) and second application <b>144</b> (App₂) from manufacturer application service <b>140</b>. In some embodiments, the request from device <b>112</b> may be a signed request that is accompanied by its initial device identifier (e.g., IDevID or LDevID) and/or an inventory of all applications that are installed on device <b>112</b>.

An example of the signed request from device <b>112</b> to manufacturer application service <b>140</b> may be as follows:

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;<entry>GET /new-mud-url-from-mfgr</entry></row><row>&lt;entry /&gt;<entry>Content-type: application/json</entry></row><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry> “signed-vendor-request” : {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“my app list” : [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry> “AppID1”,</entry></row><row>&lt;entry /&gt;<entry> “AppID2”,</entry></row><row>&lt;entry /&gt;<entry> ...</entry></row><row>&lt;entry /&gt;<entry> “AppIDn”</entry></row><row>&lt;entry /&gt;<entry> ],</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“myIDevID” : “based64encodedCert here”,</entry></row><row>&lt;entry /&gt;<entry>“nonce” : “base64encodednonce here”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

However, as described above, device <b>112</b> has been attached to network <b>110</b> via access control device <b>114</b> with the appropriate initial access control permissions on its ports to only permit communication that has been approved by MUD file <b>152</b>. That is, the only approved communications for device <b>112</b> are those that were defined by the device's initial MUD file (e.g., MUD file <b>152</b>) identified by the device's initial device identifier. As a result, first application <b>142</b> (App₁) and second application <b>144</b> (App₂) may not be able to initiate any communications or other functionality that was not approved by the initial access control permissions for device <b>112</b>.

According to the principles of the example embodiments, therefore, the manufacturer or trusted third party application service provider provides a network device with a new or substitute certificate containing an updated MUD identifier (e.g., an updated MUD URI) that identifies the access control permissions for the device and the exact combination of applications installed on the device. The new or substitute certificate is treated by network <b>110</b> as a functional equivalent of a device identifier (e.g., IDevID) when device <b>112</b> re-authorizes itself on network <b>110</b> after downloading or installing the requested applications. With this arrangement, updated access control permissions may be provided to enable the functionality of the applications that have been installed on the device <b>112</b>.

In an example embodiment, updated access control permissions for a device and its installed applications may be included in a concatenated MUD file, for example, concatenated MUD file <b>300</b>, discussed above. Manufacturer application service <b>140</b> generates concatenated MUD file <b>300</b> for device <b>112</b> with first application <b>142</b> (App₁), and second application <b>144</b> (App₂) installed and, at an operation <b>512</b>, provides concatenated MUD file <b>300</b> to MUD file server <b>150</b>.

Next, at an operation <b>514</b>, manufacturer application service <b>140</b> provides first application <b>142</b> (App₁) and second application <b>144</b> (App₂) to the requesting device, device <b>112</b>. Also provided at operation <b>514</b> is a certification from manufacturer application service <b>140</b> that includes an updated MUD identifier (e.g., updated MUD URI) that is associated with concatenated MUD file <b>300</b> that includes the updated access control permissions for the combination of device <b>112</b>, first application <b>142</b> (App₁), and second application <b>144</b> (App₂).

An example of the certification provided from manufacturer application service <b>140</b> to device <b>112</b> may be as follows:

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;<entry>Content-type: application/json</entry></row><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“signed-manufacturer-voucher”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“new-mud-url” : “https://{somenewURLhere}”,</entry></row><row>&lt;entry /&gt;<entry>“your-nonce” : “{return value from above}”,</entry></row><row>&lt;entry /&gt;<entry>“my-nonce” : “based64encodednonce here”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As described above, because the device's initial MUD file (e.g., MUD file <b>152</b>) identified by the device's initial device identifier granted only specific access control permissions to the device, first application <b>142</b> (App₁) and second application <b>144</b> (App₂) may not be able to initiate any communications or enable other functionality. At an operation <b>516</b>, device <b>112</b> requests an updated device identifier (e.g., an updated DevID) from a trusted entity, for example, authentication entity <b>118</b>, that includes the updated MUD identifier (e.g., updated MUD URI) that is associated with concatenated MUD file <b>300</b> that includes the updated access control permissions for the combination of device <b>112</b>, first application <b>142</b> (App₁), and second application <b>144</b> (App₂).

For example, at operation <b>516</b>, device <b>112</b> may include its initial device identifier (e.g., IDevID or LDevID) and the certification from manufacturer application service <b>140</b> that includes an updated MUD identifier (e.g., updated MUD URI), which was provided to device <b>112</b> at operation <b>514</b>, above. Authentication entity <b>118</b>, for example, a BRSKI registrar, may use the initial device identifier from device <b>112</b> along with the certification from manufacturer application service <b>140</b> that has a pre-established trust relationship with authentication entity <b>118</b>, to provide an updated device identifier (e.g., updated DevID) to device <b>112</b> at an operation <b>518</b>. In this embodiment, the updated device identifier (e.g., updated DevID) includes the updated MUD identifier (e.g., updated MUD URI) that is associated with concatenated MUD file <b>300</b>.

An example of a request from device <b>112</b> for an updated device identifier from authentication entity <b>118</b> may be as follows:

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /new-ldevid-mudurl</entry></row><row><entry>Content-type: application/json</entry></row><row><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“signed-vendor-request” : {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“signed-manufacturer-voucher” : “base64encoded signed-</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>manufacturer-voucher”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“myIDevID” : “based64encodedCert here”,</entry></row><row>&lt;entry /&gt;<entry>“myLDevID” : “based64encodedCert here”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“newcert” : “base64encoded csr as described in RFC 7020 reenroll”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“nonce” : “base64encodednonce here”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Upon receiving its updated device identifier (e.g., updated DevID) with the updated MUD identifier (e.g., updated MUD URI), at an operation <b>520</b>, device <b>112</b> may re-authenticate itself on network <b>110</b>. Accordingly, at operation <b>520</b>, device <b>112</b> provides its updated device identifier (e.g., updated DevID) to access control device <b>114</b>. At an operation <b>521</b>, access control device <b>114</b> provides the updated MUD identifier (e.g., updated MUD URI) to MUD controller <b>116</b>. At an operation <b>522</b>, MUD controller <b>116</b> uses the updated MUD identifier (e.g., updated MUD URI) included with the updated device identifier (e.g., updated DevID) to request concatenated MUD file <b>300</b> from MUD file server <b>150</b>.

At an operation <b>524</b>, MUD file server <b>150</b> provides the appropriate concatenated MUD file for the combination of device <b>112</b>, first application <b>142</b> (App₁), and second application <b>144</b> (App₂) (e.g., concatenated MUD file <b>300</b>) to MUD controller <b>116</b>. At an operation <b>526</b>, MUD controller <b>116</b> provides the updated access control permissions contained in concatenated MUD file <b>300</b> to access control device <b>114</b>. With this arrangement, device <b>112</b> with first application <b>142</b> (App₁) and second application <b>144</b> (App₂) installed is attached to network <b>110</b> via access control device <b>114</b> with the appropriate updated access control permissions on its ports to enable communications or other functionality for the combination of device <b>112</b>, first application <b>142</b> (App₁), and second application <b>144</b> (App₂).

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart illustrating a method <b>600</b> of secure modification of MUD files based on device applications, according to an example embodiment. In some embodiments, method <b>600</b> may be implemented by an apparatus providing a manufacturer application service or trusted third party application service provider, which may be a server or other device configured to provide applications for various devices, for example, manufacturer application service <b>140</b>. Method <b>600</b> may be described in reference to <figref idref="DRAWINGS">FIGS. 1-5</figref>, detailed above. In this embodiment, method <b>600</b> includes an operation <b>602</b> where a request for one or more applications is received from a device. For example, as described above, device <b>112</b> may request to download or install first application <b>142</b> (App₁) and second application <b>144</b> (App₂) from manufacturer application service <b>140</b>.

Next, at an operation <b>604</b>, a concatenated MUD file is determined for the device based on the applications installed on the device. For example, manufacturer application service <b>140</b> may generate concatenated MUD file <b>300</b> for device <b>112</b> based on the combination of first application <b>142</b> (App₁) and second application <b>144</b> (App₂) installed on device <b>112</b>. As described above in reference to <figref idref="DRAWINGS">FIGS. 4A and 4B</figref>, concatenated MUD files may be generated at an operation <b>606</b> by aggregating a MUD file associated with a device and one or more MUD files portions associated with applications installed on the device (described in reference to <figref idref="DRAWINGS">FIG. 4A</figref>), or may be dynamically generated at an operation <b>608</b> as a function of the device and the combination of applications installed on the device (described in reference to <figref idref="DRAWINGS">FIG. 4B</figref>). In some cases, where there are a large number of installed applications or potential applications, it may be more efficient to dynamically generate concatenated MUD files upon receiving a request (e.g., operation <b>608</b>) rather than generating concatenated MUD files by aggregating the various MUD file portions with device MUD files (e.g., operation <b>606</b>).

Next, at an operation <b>610</b>, the concatenated MUD file is provided to the MUD file server so as to be available upon request by identification of the MUD identifier (e.g., MUD URI) for that specific concatenated MUD file. For example, manufacturer application service <b>140</b> may provide concatenated MUD file <b>300</b> to MUD file server <b>150</b>.

At an operation <b>612</b>, the manufacturer application service may generate a certification or an assertion for the requesting device that includes the updated MUD identifier (e.g., updated MUD URI) for that the concatenated MUD file. For example, the certification provided by manufacturer application service <b>140</b> to device <b>112</b> at operation <b>514</b> of <figref idref="DRAWINGS">FIG. 5</figref> above.

Next, at an operation <b>614</b>, the applications requested by the device at operation <b>602</b> are provided along with the certification that includes the updated MUD identifier (e.g., updated MUD URI) for that the concatenated MUD file that includes the access control permissions for the combination of the device and the installed applications (e.g., device <b>112</b> with first application <b>142</b> (App₁) and second application <b>144</b> (App₂) installed).

Method <b>600</b> may end upon transmitting the requested applications and certification to the requesting device. In some embodiments, method <b>600</b> may begin again upon the receipt of a new request for one or more applications at operation <b>602</b>. The new request may be from the same device requesting additional applications or may be from a new device.

It should be understood that MUD files may contain additional information not explicitly described herein. For example, a concatenated MUD file for a network device in the may appear as follows:

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="259pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-mud:mud”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“mud-url”: “https://merged.app.example.com/.well-known/mud/v1/app-</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273pt" align="left" /><tbody valign="top"><row><entry>merged”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“last-update”: “2017-09-18T12:29:31+02:00”,</entry></row><row>&lt;entry /&gt;<entry>“systeminfo”: “https://merged.app.example.com/docs/app-merged”,</entry></row><row>&lt;entry /&gt;<entry>“cache-validity”: 48,</entry></row><row>&lt;entry /&gt;<entry>“from-device-policy”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“access-lists”: {</entry></row><row>&lt;entry /&gt;<entry>“access-list”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“acl-name”: “mud-23957-v4fr”,</entry></row><row>&lt;entry /&gt;<entry>“acl-type”: “ietf-access-control-list:ipv4-acl”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="259pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“to-device-policy”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“access-lists”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“access-list”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“acl-name”: “mud-23957-v4to”,</entry></row><row>&lt;entry /&gt;<entry>“acl-type”: “ietf-access-control-list:ipv4-acl”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="259pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273pt" align="left" /><tbody valign="top"><row><entry>},</entry></row><row><entry>“ietf-access-control-list:access-lists”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="259pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“acl”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“acl-name”: “mud-23957-v4to”,</entry></row><row>&lt;entry /&gt;<entry>“acl-type”: “ipv4-acl”,</entry></row><row>&lt;entry /&gt;<entry>“aces”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ace”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“rule-name”: “cl0-todev”,</entry></row><row>&lt;entry /&gt;<entry>“matches”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ipv4-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-acldns:src-dnsname”: “app2.cloud.example.com”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“protocol”: 6,</entry></row><row>&lt;entry /&gt;<entry>“source-port-range”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“lower-port”: 443,</entry></row><row>&lt;entry /&gt;<entry>“upper-port”: 443</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“tcp-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-mud:direction-initiated”: “from-device”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“actions”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“permit”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>null</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“rule-name”: “cl1-todev”,</entry></row><row>&lt;entry /&gt;<entry>“matches”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ipv4-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-acldns:src-dnsname”: “app1.example.com”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“protocol”: 6,</entry></row><row>&lt;entry /&gt;<entry>“tcp-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-mud:direction-initiated”: “from-device”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“actions”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“permit”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>null</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“acl-name”: “mud-23957-v4fr”,</entry></row><row>&lt;entry /&gt;<entry>“acl-type”: “ipv4-acl”,</entry></row><row>&lt;entry /&gt;<entry>“aces”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ace”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“rule-name”: “cl0-frdev”,</entry></row><row>&lt;entry /&gt;<entry>“matches”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ipv4-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-acldns:dst-dnsname”: “app2.cloud.example.com”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“protocol”: 6,</entry></row><row>&lt;entry /&gt;<entry>“destination-port-range”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“lower-port”: 443,</entry></row><row>&lt;entry /&gt;<entry>“upper-port”: 443</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“tcp-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-mud:direction-initiated”: “from-device”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“actions”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“permit”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>null</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“rule-name”: “cl1-frdev”,</entry></row><row>&lt;entry /&gt;<entry>“matches”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ipv4-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-acldns:dst-dnsname”: “app1.example.com”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“protocol”: 6,</entry></row><row>&lt;entry /&gt;<entry>“tcp-acl”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“ietf-mud:direction-initiated”: “from-device”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>},</entry></row><row>&lt;entry /&gt;<entry>“actions”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>“permit”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>null</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="217pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="231pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="245pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="259pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The principles of the example embodiments described above may also be applied to secure modification of MUD files based on installation of accessory devices to a device. For example, in some embodiments, a device may install or add an accessory device that includes additional or different functionality to the device. As described above, device <b>112</b> has been attached to network <b>110</b> via access control device <b>114</b> with the appropriate initial access control permissions on its ports to only permit communication that has been approved by MUD file <b>152</b>. That is, the only approved communications for device <b>112</b> are those that were defined by the device's initial MUD file (e.g., MUD file <b>152</b>) identified by the device's initial device identifier. As a result, accessory devices added or installed to device <b>112</b> may not be able to initiate any communications or other functionality that was not approved by the initial access control permissions for device <b>112</b>.

In such embodiments, the newly added or installed accessory devices may be treated in a similar manner as described above with regard to adding new applications to device <b>112</b> and securely modifying a MUD file in accordance with the accessory devices. In one embodiment, an accessory device may include an associated application. For example, an accessory device may include an application specific to that accessory device that may be obtained from a manufacturer application service (e.g., manufacturer application service <b>140</b>) or other trusted third party application service provider. In this embodiment, the new, different, and/or additional functionality provided to the device by the accessory device may be enabled by generating a concatenated MUD file, as described above, that combines the device's initial MUD file with a MUD file portion that is associated with the accessory device application. With this arrangement, updated access control permissions may be provided to enable the functionality of the accessory device that has been installed on device <b>112</b>.

In another embodiment, an accessory device may not have an associated application. In such embodiments, installing or adding the accessory device to the device may cause the device to install or download a device driver for the accessory device. For example, device <b>112</b> may install an accessory device, which triggers device <b>112</b> to install an associated driver for the accessory device that is either already included on device <b>112</b> or that is retrieved from an outside source, such as from a manufacturer application service (e.g., manufacturer application service <b>140</b>) or other trusted third party application service provider.

In this embodiment, the driver for the accessory device includes a MUD identifier (e.g., MUD URI) that is associated with an applicable MUD file portion associated with the accessory device. In this situation, the MUD file portion associated with the accessory device may be treated in a similar manner as the MUD file portions for the one or more applications, as described above. Accordingly, a concatenated MUD file may be generated based on the device's MUD file and the MUD file portion associated with the accessory device. With this arrangement, updated access control permissions may be provided to enable the functionality of the accessory device that has been installed on device <b>112</b>.

<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example embodiment of an apparatus of manufacturer application service <b>140</b> upon which the embodiments presented herein for secure modification of MUD files based on device applications may be implemented. This manufacturer application service <b>140</b> may reside in a remote server or network located apart from enterprise network <b>110</b>, and perform the operations described above with respect to <figref idref="DRAWINGS">FIGS. 1-6</figref>.

As shown in <figref idref="DRAWINGS">FIG. 7</figref>, manufacturer application service <b>140</b> includes a network interface <b>700</b>, a processor <b>710</b> for processing information and may further include a bus (not shown) or other communication mechanism coupled with processor <b>710</b> for communicating the information. The network interface <b>700</b> may be, for example, one or more network interface cards configured to enable network communications. While the figure shows a single block <b>710</b> for a processor, it should be understood that the processor <b>710</b> may represent a plurality of processing cores, each of which can perform separate processing.

Manufacturer application service <b>140</b> includes an application storage device or server <b>720</b> that stores applications and other programs that may be requested by devices for downloading and/or installation to enable new, different, and/or additional functionality to the device. Manufacturer application service <b>140</b> also includes a main memory <b>730</b>, such as a random access memory (RAM) or other dynamic storage device (e.g., dynamic RAM (DRAM), static RAM (SRAM), and synchronous DRAM (SD RAM)), coupled to the bus for storing information and instructions to be executed by processor <b>710</b>. For example, application service logic <b>732</b>, certification providing logic <b>734</b>, and/or concatenated MUD file logic <b>736</b> is stored in memory <b>730</b> for providing one or more of the functions of manufacturer application service <b>140</b> described herein. In addition, main memory <b>730</b> may be used for storing temporary variables or other intermediate information during the execution of instructions by processor <b>710</b>.

Manufacturer application service <b>140</b> may further include other components not explicitly shown or described in the example embodiments. For example, manufacturer application service <b>140</b> may include a read only memory (ROM) or other static storage device (e.g., programmable ROM (PROM), erasable PROM (EPROM), and electrically erasable PROM (EEPROM)) coupled to the bus for storing static information and instructions for processor <b>710</b>. Manufacturer application service <b>140</b> may also include a disk controller coupled to the bus to control one or more storage devices for storing information and instructions, such as a magnetic hard disk, and a removable media drive (e.g., floppy disk drive, read-only compact disc drive, read/write compact disc drive, compact disc jukebox, tape drive, and removable magneto-optical drive). The storage devices may be added to the manufacturer application service <b>140</b> using an appropriate device interface (e.g., small computer system interface (SCSI), integrated device electronics (IDE), enhanced-IDE (E-IDE), direct memory access (DMA), or ultra-DMA).

Manufacturer application service <b>140</b> may also include special purpose logic devices (e.g., application specific integrated circuits (ASICs)) or configurable logic devices (e.g., simple programmable logic devices (SPLDs), complex programmable logic devices (CPLDs), and field programmable gate arrays (FPGAs)), that, in addition to microprocessors and digital signal processors may individually, or collectively, are types of processing circuitry. The processing circuitry may be located in one device or distributed across multiple devices.

Manufacturer application service <b>140</b> performs a portion or all of the processing steps of the process in response to processor <b>710</b> executing one or more sequences of one or more instructions contained in a memory, such as main memory <b>730</b>. Such instructions may be read into main memory <b>730</b> from another computer readable medium, such as a hard disk or a removable media drive. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory <b>730</b>. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

As stated above, manufacturer application service <b>140</b> includes at least one computer readable medium or memory for holding instructions programmed according to the embodiments presented, for containing data structures, tables, records, or other data described herein. Examples of computer readable media are compact discs, hard disks, floppy disks, tape, magneto-optical disks, PROMs (EPROM, EEPROM, flash EPROM), DRAM, SRAM, SD RAM, or any other magnetic medium, compact discs (e.g., CD-ROM), or any other optical medium, punch cards, paper tape, or other physical medium with patterns of holes, or any other medium from which a computer can read.

Stored on any one or on a combination of non-transitory computer readable storage media, embodiments presented herein include software for controlling manufacturer application service <b>140</b>, for driving a device or devices for implementing the process, and for enabling manufacturer application service <b>140</b> to interact with a human user (e.g., print production personnel). Such software may include, but is not limited to, device drivers, operating systems, development tools, and applications software. Such computer readable storage media further includes a computer program product for performing all or a portion (if processing is distributed) of the processing presented herein.

The computer code devices may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs. Moreover, parts of the processing may be distributed for better performance, reliability, and/or cost.

The principles of the example embodiments described herein provide a mechanism for a manufacturer or trusted application provider to certify network behaviors based on the applications installed on a device by having the device communicate with the manufacturer or trusted application provider. The manufacturer or trusted application provider can determine what applications are installed on the device and what kind of access the device requires to enable the functionality of the installed applications. The manufacturer can then aggregate appropriate rule in a new MUD file (e.g. a concatenated MUD file) that it hands back to the device. The device can then re-register itself on the network to establish the change in authorization reflected by the new MUD file.

In summary, a method is provided comprising: obtaining (receiving) a manufacturer usage description (MUD) identifier from a first device; retrieving a MUD file associated with the MUD identifier; registering a device identifier associated with the first device with a delegated controller determined based on the MUD file, wherein the delegated controller is configured to generate a dynamic policy for the first device; obtaining (receiving) a dynamic policy from the delegated controller for the first device, the dynamic policy configured to permit a communication session between the first device and at least one second device; and providing (forwarding) the dynamic policy to an access control device in communication with the first device to enable the access control device to permit the communication session between the first device and the at least one second device.

In another form, a non-transitory computer readable storage media is provided that is encoded with instructions which, when executed by a processor, cause the processor to perform operations including: obtaining (receiving) a manufacturer usage description (MUD) identifier from a first device; retrieving a MUD file associated with the MUD identifier; registering a device identifier associated with the first device with a delegated controller determined based on the MUD file, wherein the delegated controller is configured to generate a dynamic policy for the first device; obtaining (receiving) a dynamic policy from the delegated controller for the first device, the dynamic policy configured to permit a communication session between the first device and a second device; and providing (forwarding) the dynamic policy to an access control device in communication with the first device to enable the access control device to permit the communication session between the first device and the second device.

In addition, a method is provided comprising: obtaining (receiving) a request for one or more applications from a device; providing (transmitting) to the device the one or more applications and a certification that includes an updated manufacturer usage description (MUD) identifier determined based on the one or more applications requested; wherein the updated MUD identifier is associated with a concatenated MUD file that comprises individual MUD file portions for each of the one or more applications requested; and wherein the device is configured to request an updated device identifier using the certification, and wherein the updated device identifier includes the updated MUD identifier that is associated with the concatenated MUD file.

Furthermore, an apparatus is provided comprising: a communication interface configured to enable network communications; and a processor coupled with the communication interface, and configured to: obtain (receive) a request for one or more applications from a device; provide (transmit) to the device the one or more applications and a certification that includes an updated manufacturer usage description (MUD) identifier determined based on the one or more applications requested; wherein the updated MUD identifier is associated with a concatenated MUD file that comprises individual MUD file portions for each of the one or more applications requested; and wherein the device is configured to request an updated device identifier using the certification, and wherein the updated device identifier includes the updated MUD identifier that is associated with the concatenated MUD file.

Further still, a system is provided comprising: at least one device; an access control device in communication with the at least one device, the access control device being configured to enforce access control permissions on a communication network for the at least one device; an authenticator entity in communication with the at least one device, the authenticator entity configured to provide device identifiers; a manufacturer application service apparatus in communication with the at least one device, the manufacturer application service apparatus comprising a communication interface configured to enable network communications on the communication network, and a processor coupled with the communication interface, and configured to: obtain (receive) a request for one or more applications from the at least one device; provide (transmit) to the at least one device the one or more applications and a certification that includes an updated manufacturer usage description (MUD) identifier determined based on the one or more applications requested; wherein the updated MUD identifier is associated with a concatenated MUD file that comprises individual MUD file portions for each of the one or more applications requested; and wherein the at least one device is configured to request an updated device identifier from the authenticator entity using the certification, and wherein the updated device identifier includes the updated MUD identifier that is associated with the concatenated MUD file.

Moreover, in another form, a non-transitory computer readable storage media is provided that is encoded with instructions which, when executed by a processor, cause the processor to perform operations including: obtaining (receiving) a request for one or more applications from a device; providing (transmitting) to the device the one or more applications and a certification that includes an updated manufacturer usage description (MUD) identifier determined based on the one or more applications requested; wherein the updated MUD identifier is associated with a concatenated MUD file that comprises individual MUD file portions for each of the one or more applications requested; and wherein the device is configured to request an updated device identifier using the certification, and wherein the updated device identifier includes the updated MUD identifier that is associated with the concatenated MUD file.

The above description is intended by way of example only. Although the techniques are illustrated and described herein as embodied in one or more specific examples, it is nevertheless not intended to be limited to the details shown, since various modifications and structural changes may be made within the scope and range of equivalents of the claims.