4 Essential requirements

4.1.1 These requirements are based on points from the S.E.E. Key Certificate Policy, and from the discussion in Appendix C - The SSL/TLS handshake.

4.2 The list of CAs to trust

4.2.1 The server must be configured as to what certificates it will trust, i.e. the certificates of the CAs that we trust for authentication.

4.2.2 Servers do not just permit access to all trusted certificates - we trust these certificates for authentication, but we authorise access based on the content of these certificates. See authorisation below.

4.2.3 Servers must be configured to trust all S.E.E. Accredited CAs, and the e-government unit will keep application owners informed of changes to the list of accredited CAs.

4.2.4 Servers may be configured to trust non-S.E.E. Accredited CAs, for example where they do not require the level of security offered by S.E.E., for example the Health sector may trust S.E.E. certificates and HealthCert certificates.

4.3 Certificate status checking

4.3.1 The application must be configured to check CRLs and/or OCSP servers, and deny access if the certificate has been revoked or suspended.

4.3.2 Note that OCSP is currently optional for CAs, but this is likely to be a required service in late 2002.

4.3.3 For SENSITIVE systems, access to the server must be denied if certificate status services are unavailable, e.g. if the current CRL is unavailable or the OCSP server is down or inaccessible.

4.4 Server and network security

4.4.1 PKI doesn't secure a server.

4.4.2 The server must be secured according to general best practice. For example on a Windows 2000 server, unnecessary services should be disabled, file and registry permissions should be set for only that access that is required to allow the system to run, the latest applicable service packs and security hotfixes applied.

4.4.3 The system the needs to be further secured as per manufacturer instructions, e.g. http://www.sun.com/blueprints/1100/minimize-updt1.pdf for Solaris systems, and http://www.microsoft.com/technet/security/tools/iis5cl.html for Microsoft IIS.

4.4.4 Over time these settings must be maintained and reviewed, and appropriate change control procedures followed. Administrators must subscribe to the security alert notification services appropriate for their application and/or general alert services like AusCert.

4.4.5 The system must be protected by a firewall, ideally on its own DMZ, and consideration should be given to the potential for intrusion detection systems.

4.4.6 An independent auditor should audit the server and network security from time to time.

4.5 Internal application security

4.5.1 The application must have appropriate internal security controls and this must not be able to be bypassed.

4.5.2 For example a shared workspace system may let an author grant users read access, read/write access, or deny access to a document: we need to be confident that a user that is authorised only to read a document cannot in some way gain read/write access, or someone who has been denied access, gain read access.

4.5.3 An application may use both username/password and digital certificate authentication, for example username/password may be acceptable for general use, but a "financial approval", or administration functions may be configured to require digital certificate authentication. Note that username/password authentication is inappropriate for SENSITIVE information on a public network.

4.6 Authentication / Audit / Authorisation configuration

4.6.1 The system needs to be able to use the certificates for authentication, and use this authentication for audit and authorisation of access to the system. See sections 5 and 6 below.

4.6.2 For SENSITIVE systems, there should be no way to use alternative authentication mechanisms like username/password.

4.7 Crypto stuff

4.7.1 SENSITIVE systems must support the 3DES algorithm, and may also accept AES. SENSITIVE systems must be configured not to accept any other symmetric encryption algorithms.

4.7.2 IN CONFIDENCE systems must support DES, 3DES or 128 bit RC4 encryption algorithms, and may also accept AES. SENSITIVE systems must be configured not to accept any other symmetric encryption algorithms. In some circumstances other symmetric algorithms may also be suitable, but advice should be sought from GCSB.

4.7.3 The crypto libraries should be FIPS evaluated.

4.7.4 Random key generation methods should be known to be good.

4.7.5 For SENSITIVE systems, individuals' private keys must be stored in hardware modules, and should be stored in hardware modules for IN CONFIDENCE systems.

4.8 Time synchronisation

4.8.1 It is critical that the time is synchronised on application servers and the CA's CRL producing servers and OCSP servers, otherwise an application server that is a few minutes fast or slow may deny a user access for a few minutes, because it can't find a current CRL.

4.8.2 Time synchronisation is also important among routers, firewalls and servers to make audit logs useful.

4.8.3 Time synchronisation can be achieved through manually checking time on a daily basis, or better, through a service like Network Time Protocol (NTP), especially if synchronised against multiple servers.

4.8.4 Time synchronisation over the Internet results in potential for a denial of service attack, or the use of a recently revoked certificate to gain access, and so the development of Secure Network Time Protocol (STIME) http://www.ietf.org/html.charters/stime-charter.html is important. S.E.E. Key enabled applications should take advantage of STIME once it is available and reliable.

4.8.5 In the absence of good external synchronisation mechanisms, systems could use a highly reliable internal time source such as a crystal time source, or perhaps GPS.