8 PKT specific client/server application

1. This section is relevant to those building / customising their own applications, and for specifying user requirements for off-the-shelf software.

2 Authentication

1. The following discussion is based around the use of secure sockets layer/transport layer security (SSL/TLS) or protocols using SSL/TLS (e.g. HTTPS) for communication between the client and server, e.g. a browser and a web server.

2. When the initial connection is made to the server, the server must provide the client with its certificate.

3. The client should drop the connection if the certificate has been revoked (by checking the CRL or OCSP services specified in the certificate), the certificate is expired or not yet valid, or if a current CRL or OCSP response is unavailable, the signature is not good, or if the certificate has not been issued by a trusted CA.

4. The client must warn the user, and should drop the connection, if the certificate has been revoked, the certificate is expired or not yet valid, or if a current CRL or OCSP response is unavailable.

5. Note that Netscape Navigator 4 and Internet Explorer 5 can be configured to warn the user but not to drop the connection, if the server certificate is not valid. Also note that by default these products do not check server certificates for revocation.

6. The server must challenge the user for a digital certificate and deny access if a digital certificate is not provided.

7. The server must check the client certificate against the CRL or OCSP service specified in the certificate to confirm that the certificate has not been revoked.

8. The server must drop the connection if the certificate has been revoked, the certificate is expired or not yet valid, or if a current CRL or OCSP response is unavailable, the signature is not good, or if the certificate has not been issued by a trusted CA.

9. The server must be able to be configured to specify which CAs are trusted.

10. Once the user has now been authenticated to the server (i.e. the users certificate details should now be accessible at the server and the server can be confident that the other end of the connection is the individual specified by the certificate), the application must now be able to make use of this information to authorise access.

3 Authorisation

1. The S.E.E. Project Team has no firm guidelines for authorisation but instead discusses options the implementer may wish to consider.

2. The use of PKT for authentication can be reasonably simple if the operating system implements TLS/SSL or related standards, but application specific authorisation can be very complex.

3. The authorisation process must be able to make use of the strong authentication process above. If the application can see certificate details, it can use the DN or the email address from the certificate and store the same in its authorisation tables. If the application is able to use some built-in login information, e.g. operating system or database login, a mechanism may be used to map the certificate to the login in some way, either one-to-one, or many-to-one based on fields in the certificate, e.g. all users from a particular agency mapped to one login.

4. The use of specialised extensions in certificates to store login information is highly discouraged as it will be difficult to add new users who already have a certificate issued for a different purpose, and is likely to cause problems for interoperability among domains and products. Creative use of organisation units (OUs) is similarly discouraged.

5. Authorisation may be as coarse as whether an agency's users can access the system and in this case the application can get the agency from the O field from the DN of the user certificate, check this against a list of acceptable agencies, and grant or deny access on this basis.

6. However authorisation is often more complex and is often described in terms of an individual, their roles over a certain scope, and the actions that can be performed by those roles (for example Les is an editor of the water usage forum and an author in the water safety forum; editors are allowed to create / edit / delete work, authors are allowed to create and edit their work).

7. A centrally provided authorisation service, probably leveraging a directory, has been considered to aid software development and customisation. However at least for complex applications authorisation information would be accessed continually and so needs to be stored with the application to perform well. It also seems unlikely that a centralised authorisation service could provide a user interface to authorisation that would appear consistent with the application, and it seems unlikely that existing applications could be readily extended to use such a service.

8. So for complex applications, they should probably implement authorisation as they would without PKT, but they need to be able to identify the user by the certificate details or by some other means of mapping the certificate to login details.

9. Attribute certificates are another possibility for aiding authorisation. The S.E.E. Project Team has not had any experience with attribute certificates however from discussions with overseas counterparts there is currently very little product support. If you are experimenting with attribute certificates, please tell the S.E.E. Project Team so we can track your progress.

4 Offline / out-of-band certificate validity checking

1. When a user is working offline, e.g. reading and creating email while disconnected from a network, the user will often not have access to current CRLs or OCSP responses. Clearly the user still needs to be able to perform useful work.

2. In this case, the user should have some visual warning that the certificate cannot be checked. A system should check CRLs/OCSP when they are available - as the messages are retrieved, and again when they are actually sent. Current mail packages do not yet work in this way.

5 Algorithms, protocols and confidentiality

1. The application / operating system must be able to be configured to require specific algorithms, key lengths and protocols.

2. Traffic should be encrypted using Two or Three Key Triple DES (112/168 bit). The protection provided by RC4 of any key length is an unknown, and so should be discouraged. The Advanced Encryption Standard (AES) has now been agreed by the US NIST-led group, and will provide a suitable and faster replacement for Triple DES within the next year or two.

3. Traffic encryption keys should be renewed for each session or message.

4. SHA1 should be preferred over MD5 for hashing.

5. SSL 2 must not be used, and will not work with client certificates. SSL 3 or TLS should be required. TLS is essentially the same as SSL 3 but with improved key generation, is apparently backward compatible with SSL 3 clients, and is an IETF standard, and so should be used in preference to SSL.

6 Cracker proofing

1. Industry best practice must be followed to secure the entire system. The operating system and application software must be configured for high security, and there must be good physical security, personnel vetting, and change management controls.

2. This will be considerably different for different systems, but is also likely to require very high investment, as well as high ongoing maintenance. Third party audit is recommended to maintain standards, keep abreast of developments, and to maintain confidence - see section 11.