Introduction

Authentication and authorisation

Authentication is the process of a user proving who they are. The user claims to be the rightful owner of a distinguished name (see below), and provides some set of credentials which attest that this claim is true. This is just a more general version of the well-known "username and password" routine.

Authorisation is about whether a user (whose identity has been previously authenticated) is allowed to do / see / access stuff.

It's common for the distinction between these two to be rather blurred. However, Checkpoint 6 keeps them well separated. In particular, Checkpoint 6 runs a communal authentication database, which is used by every Checkpoint Application running on the machine, whereas every application instance has its own application-specific authorisation database.

[Checkpoint 5 does not provide this level of integration; Checkpoint 5 applications have to manage their own authentication databases as well.]

"You're not comin' in 'ere." (Bouncer; authorisation denied)
"Do yew knaw who I am?" (Patron; authentication credentials sent)
"Yessir. And you're still not comin' in 'ere." (Bouncer; authentication succeeded, authorisation denied)

DNs and subjects

The Checkpoint 6 Architecture is intended to support distributed, global-scale systems. It therefore requires a rather more rigorous approach to authentication ("who are you?" / "...and prove it") than, say, Checkpoint 5 does, or some other systems do.

Checkpoint 6 subjects are, simply, the entities which use the architecture. It currently supports three different kinds of subject:

Person

Yourself (we assume :-)

Service

Applications which run on the machine, and which can be accessed by multiple users. Desktop-replacement applications, which are only used by one user at a time, typically run in the name of that user. However, an application which supports multiple end-users, will usually need to interact with CPAC in its own right; it makes sense to consider these applications as being more like users in their own rights than as fronts for single humans.

Host

Another computer. This designation is currently not much used, but this is likely to change in the future.

Conventional access-control systems do not distinguish in this way: they generally treat services as pseudo-users, and don't bring other machines within the same system (these are treated differently if recognised at all). Checkpoint 5 does similarly. Indeed, the subject type makes little difference even in Checkpoint 6. However, you should make an effort to assign the correct type to subjects; it makes management easier, and it does matter when generating X.509 certificates. There may be greater differences in future.

A distinguished name or DN is a name, of some form, which uniquely identifies a subject: a DN refers to exactly one subject. A subject has at least one DN, and usually has many. Checkpoint 6 currently supports three kinds of DN.

User ID

These are familiar: they are the only kind of DN supported in Checkpoint 5, and most computer systems recognise the same concept. Although familiar, they have the disadvantage that they are only unique within a given computer; this makes them contra-indicated for distributed systems. For the sake of backward compatibility, Checkpoint 6 subjects are currently required to have exactly one User ID. This restriction may be relaxed in future.

Email address

These are also familiar, and have the advantage of being globally unique, although they are not always useful identifiers: you@yourcompany.com is probably useful, but a throwaway address such as h4X0r666@hotmail.com probably isn't. Increasingly, websites are using email addresses in this way, although they may not have gone into the level of theory we consider here.

X.509 DN

X.509 is the (horribly complicated!) Public Key Infrastructure standard used, inter alia, to allow secure communication across the Internet. (This is the community which invented the term "distinguished name" as we use it.) The X.509 DN is a structured, geographical "name": it's effectively a name-and-address, considered as a single whole.

Conventional access-control systems usually assume a one-to-one relationship between subject and DN, and conflate the two concepts.

A given Checkpoint session features exactly one subject, and a subset of all the DNs which attach to the subject. This works as follows:

• One DN is (necessarily) used to log in.
• The login DN is the only DN of its kind which goes into the session. Eg. if you login using one email address, any other email addresses won't be part of the session.
• All DNs of other kinds will go in.

All of this matters because privileges attach to DNs, not to subjects. This means that, by judiciously attaching privileges to the correct DN, the administration can enforce more subtle policies. For example, one person (subject) may wear many different "hats" within an organisation: if I say something as a corporate officer, the implications are very different than if I say the same thing in a purely personal capacity. Similarly, if a privilege is attached to an X.509 DN, then that privilege is only available when logged in using X.509 certificate-based authentication. This represents stronger authentication than a conventional password.

If in doubt, attach privileges to the User ID DN. The rules given above mean that this DN is always present in the session.

Tasks and CDBs

CPAC controls access to two kinds of object. The first is the task. A task is a unit of functionality. Tasks can range from small, single-function programs, through to full-featured office or accounting suites.

The second kind is the Checkpoint persistent object store or CDB. (Originally, "CDB" stood for Checkpoint DataBase, but this was something of a misnomer: in particular, a CDB isn't an "Object-Oriented Database", as the term is now generally understood. Instead, "CDB" is now defined not to stand for anything, in the same manner as "DVD".)

CDB's are generally strongly encrypted, which is how Checkpoint enforces access-control - if you aren't cleared, Checkpoint won't give you the decrypt key. (We still call this key a "password", even though it isn't even close to being a word; this is to distinguish it from a database "key", which is different.)

CDBs are encrypted using the 256-bit CBC (Cipher Block Chaining) AES algorithm [109], with HMAC-SHA1 [105], [110] to ensure that data has not been tampered with. There are no known weaknesses in these algorithms.

[NOTE] Recent cryptanalytic work has found collisions in "raw" SHA-1; this is a concern. However, SHA-1 is still considered to be secure when used in the HMAC construction, and its successor hashes are a lot slower. We continue to monitor the situation, but this remains the best tradeoff today.

We would like to record the historical contribution made by the Blowfish cipher algorithm [103], and the RIPEMD-160 hash function [106]. These were used during the development of Checkpoint 4 and Checkpoint 5: without them, it's highly unlikely that Checkpoint would exist today in its present form.

CDBs over networks: Beware!

Many systems support some kind of "network" file system. With these, you can access storage on another host, over the network, as though it was storage on your local host. For example, Windows has the "Map network drive" function in Windows Explorer; Windows (SMB) networking shares appear as though they were local drive letters.

If you have a CDB archive which is shared in this way - whether it's in local shared space on your host, or you're accessing it over a share from some other host - it is vital that only one application has the CDB open at any given time. Failure to observe this may cause CDB corruption and data loss. This is because our locking mechanism (which allows multiple programs to access an archive safely at the same time) does not work over a network.

You should also be aware of the security issues present with this type of working - network traffic is not encrypted, and can be intercepted and copied by anybody on your LAN. Wireless LANs are even worse: if the WLAN is not secured properly, a cracker in a car in the street outside your office can do the same. The most commonly deployed WLAN confidentiality system is WEP, which is insecure. The newer WPA system is a lot better, however.

All that said, we do have to admit that this method of working can be extremely convenient. Therefore, while this is not recommended, it can be used safely if appropriate precautions are taken. If you indulge in this mode of operation, you accept responsibility for the consequences.

[NOTE] Our separate product, Catcher, will provide a fully secure, safe alternative to this mode of operation. Coming soon.

Subsystems

Tasks and CDBs are installed into a set of subsystems which you define. Every subsystem has a single user who is the owner of the subsystem - only the owner of a subsystem can dictate who is allowed to do and / or access what within the subsystem - there's no all-powerful "super-user" or "system administrator" in Checkpoint. To access the tasks and CDBs in a subsystem, you must log into that subsystem (if you're allowed to - see below.)

Our use of subsystems in this way is an example of multilateral access control.

[NOTE] We generally talk about the "ID" of a given object (task, CDB etc.) rather than its "name". This is intended to avoid confusion - is a "name" a distinguished name, ie. an identifier which is properly unique and obeys some set of rules which are needed for the system to work, or is it just some extra, human-friendly tag you made up on the spur of the moment, or decided to leave blank instead? Since the word can have either meaning, we decided not to use it without qualification.

The global subsystem

As well as normal subsystems which work as above, there is a special global subsystem, which has the subsystem ID $$$$, and some special properties, as follows.

• Tasks and CDBs in the global subsystem are accessible (subject to other access-control restrictions; see below) from any subsystem - you don't have to be logged into the global subsystem.
• Many users can act as its owner, rather than just one.
• No task or CDB in any other subsystem can have the same ID as a task or CDB in the global subsystem.
• The global subsystem is created automatically when CPCC is installed, and cannot be destroyed.

Access control

Tasks, CDBs and subsystems - CPAC objects - are either open or secure. By default, anybody can access a CPAC object which is open, whereas in the case of a secure object, only the subsystem owner can access the object. "Access" here means slightly different things depending on which type of object you're referring to: it means to execute a task, to read or write a CDB, or to log into a subsystem.

These defaults can be overridden by Access Control List (ACL) entries: these allow the default to be reversed for specified cases. ACL entries assert a definite state, not just "invert the default": thus you can have a "deny" ACL entry for an open task (which denies a specified user access to that task), but you can also have a "permit" ACL entry for the same task (which has no effect).

A common approach

One way to configure your installation is to have open tasks and CDBs, within secure subsystems. In order to access any tasks or CDBs within a normal subsystem (i.e. any subsystem except the global subsystem) users must log into it, regardless of the access-control configuration. However, since the subsystem is secure, then only designated users (apart from the subsystem owner) can do this. But once inside, users can (by default) access all tasks and CDBs in the subsystem, since they're open. This "crunchy outside, chewy inside" configuration provides a good tradeoff between reasonable security and ease of maintenance: only one ACL entry per user per subsystem is required (to grant access to the subsystem itself). The high-security alternative - secure tasks and CDBs within a secure subsystem - also requires one ACL entry per task or CDB per user per subsystem, which is much more difficult to maintain.

Logging in

To launch CPCC, just launch the cpcc executable, which is located in the bin subfolder of the folder into which you installed Checkpoint. On Windows, this will normally be called cpcc.exe; on unix, just cpcc . Your browser will be launched, and thereafter you interact with CPCC just as though you were navigating around a web site. Clearly the browser "furniture" round the ouside will vary depending on what browser you use, and how you have configured it.

The first page you will come to is the login page.

CPCC login page

To start with, use the user ID, password and token (if any) which you created during the configuration process. You can create new subject accounts from inside CPCC, either for other people who use the computer, or for services which run on it. For a subsystem, you can either log into the global subsystem $$$$ or create a new subsystem to experiment with (recommended). In the latter case, just enter the subsystem ID and click the "create" box.

If you think you might have difficulty remembering subsystem IDs, one approach is to create a subsystem whose ID is the same as your user ID, and use that for miscellaneous or experimental stuff. You can then create other subsystems for specific activities or work areas. Once you've logged into a subsystem, you can start new sessions (see below) in other subsystems, and you're given a list of all available (to you) subsystems to help you choose.

Agents and Daemons

Brief technical interlude: Although you may think that you have just logged into CPCC, actually you haven't. Instead, you have really logged into the Checkpoint Daemon. The Checkpoint Daemon is a separate program which is shared between all users, and all user agent applications, of which CPCC is one example.

Practical upshot:

• On platforms which support this, the Daemon runs as some special user, whereas user agents run as the user which launched them.
• You may see two "console" windows - one for CPCC, one for the Daemon. Don't kill them!
• If you crack CPCC, this won't allow you to defeat CPAC, because CPCC doesn't make any of the decisions; it's just the messenger.
• Subject accounts, and the DNs and authentication credentials which go with them, are automatically available to, and are the same for, all Checkpoint services on the machine. NB. This does not imply that you'll necessarily be able to log into all of them - that is a privilege, which is granted (or not) completely separately. ("You're not coming in 'ere." "Do you know who I am?" "Yessir. And you're still not coming in 'ere.")

Sessions

When you log in, you create a new session with the Daemon. The session defines the subject and DNs you're logged in as, and the subsystem you are logged into; these in turn define the set of tasks, CDBs and privileges available to you in this session.

When you launch a task from inside CPCC, the session ID will be passed on to the task. That task can use this session ID to gain access to CPAC objects (usually CDBs) from the Daemon, without you having to log in again.

Web page GUI format

Once you're past the login page, all pages (screens, if you prefer) in CPCC have the same basic layout. They look a bit like the example below:

CPCC Front Desk

The key features of the CPCC GUI page:

• The sidebar is the yellow area on the left hand side. This contains links to other areas of functionality. Which links you see depends upon what you're allowed to do (in this subsystem).
• The navbar is the horizontal grey bar under the blue heading. The general idea is that the sidebar contains links "downwards" to more detailed pages, whereas the navbar contains links "upward" to higher-level pages. The page shown is the "front desk" for the subsystem, which is the top of the tree; as such it's on the navbar, but the link is disabled since we're already there.
• The main panel is the large white area to the right of the sidebar. On this front page, the main panel contains the list of available tasks; you can launch these by clicking the yellow-chevrons-on-black 'launch' button to the right of the task description. In this shot, a number of tasks are available. Clearly your installation will have a different list of tasks; this shot is for illustrative purposes. As you can see, the task list is in two parts. The first list is for tasks which are specific to this subsystem. The second is for tasks from the global subsystem, which are available in any subsystem (subject to access control in the usual way). If you're actually in the global subsystem, this second list is always empty.

Sidebar links

The links at the top of the sidebar take you to various other CPCC pages:

• 'Your account': allows you to update your basic user details: your "Common Name" (a longer, human-friendly description of yourself, not your user ID) and your DNs. It also shows the privileges which those DNs have. All users get this link.
• 'Your secrets': this is covered in the advanced manual. All users get this link.
• 'Your X.509': this is also covered in the advanced manual. All users get this link.
• 'This subsystem': this link takes the subsystem owner (only) to a set of pages which allow them to administer the subsystem: change its description, login task, security state and ACL, list and edit its collection of available tasks and CDBs, view the log of all access-control violations which have taken place within this subsystem, and install new modules .
• 'Global Error Log': this shows the log of all access-control violations which have not taken place within any subsystem. These are all login failures. Only users with the appropriate privilege can access this.
• 'Subjects': this takes you to a page where you can edit the privileges, passwords and other details of all users, including yourself. Only users with the appropriate privilege can access this.
• 'Host config': this takes you to a page where you can hack various elements of the host configuration. Only users with the appropriate privilege can access this.

The buttons in the two bottom sections of the sidebar execute various other CPCC functions:

Help

launches the help system by opening a browser window to display the index page of the Checkpoint documentation

Impressum

Opens a browser window to display the impressum page of the Checkpoint documentation. This contains all the relevant publication information such as acknowledgements, copyright statements, trademark claims and so forth.

Logout

Ends this session, but does not close down CPCC (so any other sessions will remain active).

Shutdown

Stops CPCC altogether, and ends all sessions.