< 上一个 | 内容 | 下一个 >

‌6.2 Security attributes‌

6.2.1 Introduction

In this subclause, we define some abstract data structures for managing registration (see 6.9) and access control. How this functionality is accomplished is left to the implementer. No access to these data structures is defined in this standard.

6.2.2 Local registration attributes

Local registration attributes represent the data which would be used to hold information passed out-of- band as part of the registration process prior to resources being established.

Table 2 —Local registration attributes

Table 3 —Local registration descriptor entry

‌6.2.3 Access control list (ACL) attributes

6.2.3.1 Introduction

Access control list (ACL) attributes represent the data that would be used to hold information to determine whether access to a particular resource by a particular client is allowed or denied. An ACL can enforce more granular access control based on various criteria (e.g., client identity). Conceptually, an ACL exists for every single accessible resource, however in practice it is likely only certain resources with more complex access policies would require a representation of all the data specified in this subclause.

Table 4 —ACL attributes

‌Table 5 —AccessDescriptorEntry

‌Table 6 —SpecificIDDescriptor entry

Access control list (ACL) attributes provide a mechanism for granting and revoking privileges to use specified methods with a particular resource, applicable to all resources described in this standard. Access control that is more granular than a resource is out of scope for this standard. The mechanisms for authentication and the binding of that authentication to a specified identity (such as an IP address) are specified in 6.5 and 6.6.

ACLs are used to set default privileges and grant additional privileges, not to deny privileges. Thus, if a given client’s request does not explicitly meet the required privilege in the associated ACL, then that client does not have that privilege. The default configuration of an ACL for a given resource means that resource

is not accessible to clients. In practice, this state only exists ephemerally and all ACLs will be initialized appropriately at startup according to the security policy and will be subsequently modified according to registration and authentication.

Subordinate resources created dynamically will initially inherit their ACL from their parent resource.

ACLs may be statically fixed with a default operation for some resources and may be dynamic and extensible for others. If a resource does not have an ACL, access is granted to the resource unconditionally.

Initialization of ACLs, beyond minimal requirements, is out of scope for this standard and is governed by overall security policy. Default settings for ACLs for particular function sets are described in 6.8.

6.2.3.2 aclDefaultAccess

aclDefaultAccess in the ACL is used for settings irrespective of the client identity of an incoming request and is used initially to authorize an incoming HTTP request.

6.2.3.3 aclSpecificIDList

A SpecificIDDescriptor entry in the aclSpecificIDList part of the ACL is an additional entry used to allow specific additional checks to be done to authorize based on client identity (IP address and port).

6.2.3.4 Access authorization

6.2.3.4.1 Introduction

These are controls that are independent of the source identity (IP address and port) and thus can be configured in both aclDefaultAccess and a SpecificIDDescriptor entry in aclSpecificIDList as shown in Table 5 and Table 6.

In the following, corresponding ACL entry means:

 The first SpecificIDDescriptor entry in aclSpecificIDList which matches the incoming client HTTP request’s source IP address and port

 aclDefaultAccess otherwise

6.2.3.4.2 Method attribute

The Method attribute is used to control which HTTP request method is allowed for client access.

 GET

 PUT

 POST

 DELETE

 HEAD

The HTTP method of an incoming HTTP request is checked and Method authorization will be TRUE if the method is allowed in the corresponding ACL entry.

‌6.2.3.4.3 AuthType attribute

The AuthType attribute is used to control the required authentication types the client can use in its incoming HTTP/HTTPS request.

 0x1: No authentication

 0x2: User authentication

 0x4: Self-signed certificate

 0x8: Device certificate

If an incoming HTTP request is destined for the port associated with HTTPS (typically port 443), the incoming authentication type will be set to the corresponding TLS session authentication type. If an incoming HTTP request is destined for the port associated with HTTP (typically port 80), the authentication type will be set to 0x1 (no authentication). The user authentication AuthType (0x02) can be used if additional user authentication outside of the scope of this standard takes place.

The incoming authentication type is compared with the bitmap in AuthType in the corresponding ACL entry and AuthType authorization will be TRUE if the corresponding authentication type is set in AuthType in the corresponding ACL entry. Representing this logically:

if (authentication type & AuthType) != 0: AuthType authorization = TRUE

else

AuthType authorization = FALSE

‌6.2.3.4.4 DeviceType attribute

The DeviceType attribute is used to control the device type required of the client’s incoming HTTP request. It is based on the deviceType OID in the certificate (see 6.11.7.2).

If an incoming HTTP request is destined for the port associated with HTTPS, the incoming device type will be set to the corresponding TLS session device type based on the deviceType OID in the certificate. If an incoming HTTP request is destined for the port associated with HTTP, the device type will be set to 0 (any device type).

If the DeviceType in the ACL is set to 0, device type authorization will be TRUE unconditionally. Otherwise the incoming device type is compared with the DeviceType in the corresponding ACL entry and DeviceType authorization will be TRUE if the device type is equal to the DeviceType in the corresponding ACL entry.

6.2.3.5 Authorization logic

Authorization is granted if Method authorization, AuthType authorization, and DeviceType authorization are all TRUE. Access to the resource can then take place.

If Method authorization is not granted, the server MAY respond with either:

HTTP/1.1 400 Bad Request

or

HTTP/1.1 405 Method Not Allowed

If AuthType or DeviceType authorization is not granted, the server SHOULD immediately respond:

HTTP/1.1 404 Not Found

The server MAY respond:

HTTP/1.1 401 Unauthorized

Otherwise, processing will continue.

6.2.3.6 ACL examples

6.2.3.6.1 Introduction

This subclause contains two informative examples to illustrate the use of ACLs, using EndDeviceList and EndDevice.

6.2.3.6.2 EndDeviceList

The EndDeviceList resource is usually accessible by any client to find its own entry in the list. Therefore, the ACL will be as follows:

Table 7 —Example ACL for EndDeviceList

In this example, there will never be any SpecificIDDescriptors required, as this resource needs to be accessible to any device.

6.2.3.6.3 EndDevice

In this example, an EndDevice resource for a client does not exist prior to registration.

The earliest point it can be created is at the point of registration and the ACL would be set as shown in Table 8.

‌Table 8 —Example ACL entry for EndDevice at point of registration

In this example, there is no default access as only the client device associated with the EndDevice is able to access the EndDevice. Also, at this point, there has been no client communication, therefore there would be no SpecificIDDescriptor entry in aclSpecificIDList.

There would also be an entry placed in the local registration list corresponding to the client, as shown in Table 9.

‌Table 9 —Example local registration entry for registering device

In this state, it is primed to be populated with a SpecificIDDescriptor when the device actually accesses the EndDeviceList resource.

When the client attempts access to any resource on a function set server using TLS, it will start performing the TLS handshake, which involves transferring the client’s certificate. At the point of access, if there is a pending registration, it will be checked against the client’s device. If there is a match, and the validated certificate’s SFDI matches, the ACL for the EndDevice will be populated with an additional SpecificIDDescriptor as shown in Table 10 and Table 11.

‌Table 10 —Example ACL entry for EndDevice at point of client access

‌Table 11 —Example SpecificIDDescriptor for EndDevice at point of client access

< 上一个 | 内容 | 下一个 >