Security Policies and Access Control

on the host to ask for specific settings regarding these properties on an individual basis. Clearly, the order in which services start cannot be known beforehand. A connection may start without any security switched on; then, at some point in time, a new service is initiated that asks for encryption. As this requires some LMP signaling over the link, some stack support is needed in order to effectuate the switch to encrypted mode. The goal of an access control mechanism is to provide means for the applications to request the type of connection they want. This is referred to as service level–enforced security. In particular, what is described below pertains to devices operating in security mode 2 (see Section 2.5.1 for a general discussion on different security modes).

6.1.1Trust relations

In this context, a trusted device refers to a device to which a security relation has been established that is to last for more than the duration of the current session. Typically, personal devices that one would like to be able to hook up to more than once fall into this category, such as a headset and a mobile phone, a PDA that synchronizes to the desktop computer, or a mobile phone that is used for dial-up networking by a laptop computer. A trusted device is given unconditional access to all services running on the host after its identity has been confirmed through the authentication protocol.

For other user scenarios, the connection is of a more temporary nature. It is of interest to encrypt the link to have privacy, but a permanent bonding between the involved devices is not necessary, as this connection is not likely to be restored at a later time. It could also be the case that a fixed security relationship does exist, but the far-end device is not granted unrestricted access to services running on the near-end device. Such devices are referred to as untrusted.

A possible refinement of the trusted and untrusted relationships is to have these properties defined not per device but rather per service or group of services.

6.1.2Security levels

A service can freely set its requirements on authorization, authentication, and encryption as long as the settings obey the basic rules of link level security. For instance, one cannot request encryption without authentication. From the possible access requirements, services fall within three security levels:

1.Authorization and authentication;

2.Authentication only;

3.Services open to all devices.

In case authorization is desired, the user must actively approve access to a service unless the connecting client runs on a trusted device (which automatically has access to all services running on a host). There are also authenticationonly services, for which no authorization is necessary. Finally, the open services need neither authorization nor authentication. Obviously, the latter implies that the link level cannot be encrypted, as the protocol requires at least one authentication before the encrypted mode is possible.

6.1.3Flexibility

In order to be usable, the security architecture must provide for individual settings of the access policies of different services. Opening up for one application shall not automatically also open for others. For instance, a cellular phone may have an open policy for accessing service discovery records and business card exchange but a restrictive policy for headset access and dial-up networking. In the same manner, for a service that has to deal with changing remote devices (such as file transfer and business card exchange), access granted to that service does not open for access to other services on the device, neither does it grant automatic future access to the service on the device.

In order to increase usability, the amount of user intervention to access a service should be kept at a minimum. Basically, it is needed when setting up a trusted relationship with a device or when allowing a limited access to a service.

6.1.4Implementation considerations

In Bluetooth, protocol multiplexing can take place at and above the L2CAP layer. The higher layer multiplexing protocols (i.e., above L2CAP) are in some cases Bluetooth specific (e.g., RFCOMM) and in other cases nonunique for Bluetooth (e.g., OBEX). Some protocols even have their own security features. The security architecture must account for this in that different protocols may enforce the security policies for different services. For instance, L2CAP enforces security for cordless telephony, RFCOMM enforces security for dial-up networking, and OBEX enforces its security policy for file transfer and synchronization.

Lower layers need not know about security settings and policies at higher layers. Furthermore, security policies may differ for the client and server role of a particular service. That implies that peers may enforce different security policies for the same service due to their different roles. This also must be handled by the security manager.