JISC

This report is intended to describe practical details of the implementation of security services required to operate across JANET. It attempts to provide a technical perspective to the paper by Bell/Wiseman, which describes the overall requirements of the UK academic community and outlines a solution based on authentication servers; and it aims to guide the detailed design of a project implementing the services described. This report is not a detailed design document and aims to show what is implementable rather than precisely how it might be implemented.

At this stage of the project plan, the following services are to be considered:

• authenticated access to JISC services, with a single unified authentication mechanism for all services and with confidentiality of the subsequent communication
• secure email, with authentication, integrity and confidentiality
• secure telnet and ftp, with authentication of user and/or server and with confidentiality of the subsequent communication

Any project to implement authentication and encryption services across JANET will have relatively short timescales and a limited budget. Therefore, it is very important that the following implementation requirements are realised:

• Maximum reuse of technology across services. It is important that generic authentication mechanisms are derived and that any infrastructure that needs to be deployed is applicable to all services, otherwise the project would break down into a number of parallel but similar activities
• Minimum need for re-engineering if dependent protocols or applications change. The environment in which the project operates is one in which security protocols are frequently updated and users' applications are subject to regular new releases. It is important that the project makes itself as independent of this as possible, to ensure that it does not waste resources endlessly re-implementing in order to catch up with the latest developments elsewhere

="TofC2">

Information Management

The usefulness of authentication services depend on the participating organisations making availability the required authentication information, and some sort of infrastructure is required to support this. Successful deployment of the infrastructure depends on scalability (the effort required to make the information available is appropriate to the benefit obtained, regardless of the size or complexity of the organisation). Scalability depends on re-using existing working practices and distributing the workload so that information is input to the system at the point where it is available and does not need to be re-keyed.

Authentication server

Therefore, it is proposed that each institution operates an authentication server to make available information about it's own staff, students and members. This will be operated from a single dedicated computer securely located within the administrative section, connected to JANET (with a DNS name of auth-server.institution.ac.uk) and will be accessible via the http protocol only.

The use of the http protocol to access the authentication server allows each institution to devise it's own methods of storing it's information (whether using X.500, WHOIS++, Oracle etc.). Standard CGI scripts can be used to present a standard API to the rest of the community, translating well-defined http queries into the format for the local database and translating the results into a well-defined format.

All results returned by the authentication server will be digitally signed and will include the time at which they were sent. This allows the authenticity, integrity and freshness of the results to be checked. (The results could be signed using a standard mechanism such as PGP. However, all that is really needed is a digital signature and common agreement over exactly what is signed, so a more lightweight protocol can be invented)

The authentication server needs to provide services supporting authentication using a variety of authentication techniques:

• simple authentication; where passwords will be stored on the authentication server, and external queries will be able to compare the password but not read and write. Passwords will expire after a specified period, and the account will expire if the password is not changed within a specified period after expiry. The server will also store information counting unsuccessful password comparisons, so that repeated failed attempts may be spotted and dealt with
• protected authentication using hardware one-time passwords (challenge-response cards); again passwords are stored on the authentication server, and comparison operations are performed in terms of predefined mathematical operations involving the password and a shared random number. Passwords held on the server are the same as those held in credit-card sized password cards carried by users, and will need to be updated when the user acquires a new card (and revoked if the user loses a card). The server can again store information counting unsuccessful challenge/response operations, so that repeated failed attempts can be spotted and dealt with
• protected authentication using software one-time passwords (S/Key); S/Key requires that the result of the previous successful S/Key login be stored on the authentication server as it is used in the next authentication check. Again, the server can store information counting unsuccessful S/Key operations, so that repeated failed attempts can be spotted and dealt with.
• strong authentication; where public key certificates are stored on the server and may be read but not written. Certificates in a variety of formats may be stored on the server simultaneously (e.g. X.509 and PGP). Other than serving information, the authentication server has no part in the strong authentication process, and therefore it is not generally possible to store information relating to unsuccessful login attempts

Note it is perfectly possible for an institution to partition it's data and locally store different partitions in different places (for example, X.509 certificates can be stored in X.500 directories and PGP keys and user passwords can be stored in a local database). The authentication server will make this distribution of data invisible to the external user.

The authentication server will comprise a dedicated machine (the recommended specification is to be determined, though a fast Pentium PC with lots of memory running Windows NT would certainly be acceptable and affordable). The server will run a very limited software suite, comprising:

• a customised http server (listening on TCP port 80) that translates well-defined http queries into the format for the local database and translates the results back into a well-defined format. No HTML pages will be served by the server.
• a customised telnet daemon (listening on TCP port 23) that will only allow a user whose simple authentication password is stored on the server to change this password (see password.demon.co.uk for an example of this facility). The telnet daemon shall not permit any other access (in particular no-one shall remotely log in to the authentication server).
• if the local database is implemented using a directory such as X.500, then the server shall be allowed to run directory software allowing the information on the authentication server to be part of a global directory (subject to the directory configuration assuring that the access controls reinforce the security requirements of the data held in the server)
• no other network services shall run on the authentication server (this includes both LAN and Internet services)="TofC4">

  Certification authority

  As well as operating an authentication server, each institution needs to operate a certification authority (CA). A CA is a special user who is responsible for certifying the public keys of the staff, students and members of the institution. A CA will have it's own private and public keys and will use these to sign statements asserting the identity of the users at the institution. A CA also has a "certification policy", which is a formal statement of the way it operates.

  The operation of the CA is as follows:

  1. A user at an institution will generate their own RSA key pair (or the CA will generate it on their behalf).
  2. The user will take the RSA public key to their institutional CA. The CA will check the identity of the user to ensure they are who they claim to be.
  3. The CA will use it's private key to sign an X.509 certificate containing the user's public key.
  4. The CA will use it's private key to generate a signed PGP key containing the user's public key.
  5. The CA will give the X.509 certificate and the signed PGP key to the user, and will also give them to the operator of the authentication server so they can be made publicly available.
  6. Optionally, the CA will also take a copy of the user's private key and store a copy of this in secure encrypted form (this is called Key Escrow). This is to protect the user against loss of their private key, which will render encrypted data unreadable. The user should be free to decline to make their private key available for this purpose; but should be made aware, in this case, that they are solely responsible for the private key and for any consequences arising from its loss.

By doing this, the CA is effectively declaring "I, the CA for such-and-such institute, assert that such-and-such user is associated with this institution and is the owner of the public key stored in this certificate". Anyone who knows the public key of the institutional CA can verify the integrity of the statement, and anyone who trusts the CA to do it's job competently can therefore know that the user does indeed own the public key (and, by implication, the corresponding private key).

The name that is placed in the certificates issued by a CA is required to be unique within the academic community and to identify the user's institution, so that applications know which authentication server to contact to verify any authentication information given. The best choice of name to use in users' certificates is therefore their email address, which automatically meets these criteria.

A CA will also be responsible for revoking the certificate of user's who are no longer entitles to be certified by an institution (or those whose private key has been compromised in some way). We assume here that a user's certificate will be revoked if the certificate is removed from the authentication server (since the protocols we shall design will assume the use of on-line validation of certificates).

The effort required for the operation of a CA is significant, especially in a large university where one third of the user population changes every year. However, building the certification process into the admissions process (or, even better, the process of allocating computer accounts and email addresses) is likely to allow for significant streamlining. It is also worth examining the SESAME 'Local Registration Authority' architecture described in the Young/Kirstein/Ibbetson paper as this allows most operations to be delegated to individual departments.

The above discussion assumed that users needed to know the public key of an institution's CA in order to verify the certificates generated by that CA. It is impractical for a user to know the key of the CAs from every academic institution. A better solution is for some higher level body to operate a small amount of central infrastructure:

• a distinguished CA which will certify the public keys of the CAs from each organisation. It will take the public key of the organisation's CA and will use it's own private key to issue an X.509 certificate and a signed PGP key.
• an authentication server to store the certificates and signed keys for each institution. This server will simply respond to requests for either the X.509 certificate or the PGP key of an institution and will return a signed message containing the requested item and the current time (this is so that the freshness of the information can be demonstrated). This allows users to check that an organisation's certificate is still valid. It is suggested that the DNS name of this authentication server is root-auth-server.ukerna.ac.uk, in order to differentiate it's slightly different role.

In this paper, I have assumed that this will be operated by UKERNA, but it could just as well be anyone else who is seen by the UK academic community as 'trustworthy' (this may be seen as 'trust by association', but political credibility is an important consideration). One alternative candidate that should be considered is the "UK Academic CA" currently being operated by UCL under the auspices of the ICE-TEL project.

All that is now required is for the public key of the UKERNA CA to be well known to all users and programs that need to communicate with the authentication servers. Using this key, the public key of any institution's CA can be verified; and using that key the public key of any user at any institution can be verified.

The effort required for the operation of this central infrastructure is small - just two signing operations per higher education institute and placing the results in the authentication server. The information will (hopefully) change infrequently, making the ongoing management effort also small.

Information stored on the authentication server

An organisation's authentication server holds information both for individuals and for the organisation itself. As an example, consider the Salford University authentication server. For users, information held includes:

• Name
• Email address
• Textual description of role within organisation
• Service enablers indicating which JISC services the user is permitted to use
• Service enablers indicating whether telnet or ftp from external sites is allowed.
• Simple password for access to JISC services
  • Date last changed and date last used (to aid in password aging)
• Simple password for telnet/ftp access
  • Date last changed and date last used (to aid in password aging)
• Password for challenge-response one-time-password card
• The parameters required for S/Key, including result of the last successful login.
• PGP public key for user, signed by Salford CA
• X.509 certificate for user, signed by Salford CA

For the university itself, information held includes:

• PGP public key of Salford CA, signed by UKERNA CA
• X.509 certificate for Salford CA, signed by UKERNA CA="TofC6">

  Personal security environment

  While the authentication server is intended to facilitate the dissemination of publicly available information, each user will also need to be able to handle two sorts of personal information:

  1. private information to be known only to the user. This comprises the user's passwords for simple authentication and the user's private key for strong authentication. The integrity and confidentiality of this information must be assured to prevent security attacks.
  2. trusted public information, on which the operation of the strong authentication mechanisms depend. This comprises the public key of the UKERNA CA, which must be known to all users of the infrastructure in order to validate any information retrieved from the authentication servers. The integrity of this key must be assured to prevent security attacks.

In currently deployed Internet applications (that depend solely on simple authentication using passwords) the only information of this sort that exists is the user's password, and the user is expected to store this securely in their own brain and type it into their computer at the relevant point in the authentication process. In practice, it is this requirement for 'human secure storage' that is the main weakness in password based authentication, as users will either use memorable passwords such as names (thereby being vulnerable to dictionary based password-guessing attacks) or will write down unmemorable passwords (thereby subverting the whole 'shared secret' principle on which passwords depend).

The improved authentication services that are being described here make the use of human memory impractical for a number of reasons:

• It is unfeasible to expect users to remember and type in their private or public keys as this is beyond human capability, as the following example shows:
  • Banks work on the basis that a 4 digit PIN number is the most that a typical user can remember. This contains around 213 combinations
  • A computer password is typically 8 alphanumeric character long. In theory, this contains 2⁴⁸ combinations, although the fact that passwords must be pronounceable to be memorable means that the actual number of combinations actually used is probably nearer 2²⁴.
  • a public and private key will typically be 1024 bits in size, therefore there are 2¹⁰²⁴ combinations.
  A public key is therefore like a perfectly random 170 character password or a 308 digit PIN number, both well beyond human memory capacity.

  We therefore introduce the idea of a Personal Security Environment (PSE) in which each user stores the information they need to use the authentication services. This comprises:

  private information

  • user's password for simple authentication to JISC services
  • user's password for telnet/ftp access
  • user's password for S/Key
  • user's private key for strong authentication

  public information

  • user's public key for strong authentication (this will typically be stored as a signed PGP key and/or an X.509 certificate, signed by the user's organisation's CA)
  • the public key of user's organisation's CA (this will typically be stored as a signed PGP key and/or an X.509 certificate, signed by the UKERNA CA)
  • the public key of the UKERNA CA

  There are a number of possibilities for how this PSE may be implemented:

  1. It can be stored as an encrypted file stored on the user's hard disk. At the time the PSE is created, the user will supply a "pass phrase" which will be used to encrypt the PSE (using a symmetric algorithm such as DES). Any application that needs to access or modify the information must request the pass phrase from the user. While applications must be trusted not to misuse the pass-phrase, even the most trustworthy program must store the pass-phrase in memory for a short time (during which it is vulnerable to passive observation). However, an attacker simply gaining access to the PSE file is unable to decode the file or substitute a replacement unless the pass-phrase is known.
  2. As above, but store the file on a floppy disc. This provides a "portable PSE" which the user can carry round with them and can use to authenticate themselves at whatever computer happens to be available. The drawback, of course, is that the user will need to enter their pass-phrase into a computer that they do not know if they can trust, running software that they do not know if they can trust.
  3. It can be stored on a smart card (new style BT phonecards and the SIM cards used in digital mobile phones are examples of these). A computer would need to be equipped with a smart card reader, and the user would typically need to type a PIN number into the card reader to allow the computer read access to the card (and often a different PIN number to allow write access). Smart cards will automatically lock themselves if a predefined number of incorrect guesses of the PIN number are made. This is another example of a "mobile PSE" which the user can carry around and use wherever they happen to be (as long as the computer has a smart card reader attached, of course). The PIN number does not need to be typed into a computer, and so it cannot be intercepted. However, the computer still needs to be trusted not to misuse the PSE's information once the PIN number has been entered.

     Advanced smart cards exist (for example, the US military's Fortezza card) where authentication and encryption is performed on the card itself and therefore private key information never leaves the card. This mean that trusted computers and applications are not needed, but this military level of security is not yet within the reach (or probably the need) of the UK academic community. (Note that these cards are PCMCIA cards rather than resembling the new BT phonecard).

  There are many different brands of smart card and reader on the market. It is not known (by the author of this document) if a card written by one brand of reader is guaranteed to be readable by a different brand of reader, but it is certain that each card reader requires proprietary software to access it and therefore that "smart card aware software" will need to be re-written many times if different brands of smart card reader are in common use. There is, therefore, an urgent need for JISC to commission a survey of the current state of the smart card market in Europe and gain an accurate picture of availability, cost, capabilities etc. On this basis, an "approved card reader" for use within the UK academic community can be selected. By acting at this immature stage in the smart card market, JISC can hopefully minimise any future proliferation of incompatible hardware within the academic community.

  The unit cost of a smart card reader is relatively high (believed to be of the order of hundreds of pounds) and the cost of the cards is lower (believed to be of the order of tens of pounds, less for large quantities) and, by selecting an approved model, the UK academic community should be able to negotiate significant bulk discounts on these prices. It is also worth noting that the smart card could easily be re-used as an institutional ID card, building access card, library card etc., therefore allowing some of the cost to be recouped.

  For the purposes of the project envisaged, it is recommended that any software developed supports a floppy disc based PSE as the lowest common denominator, and supports an approved smartcard where available. This allows low cost entry into the authentication infrastructure and gradual adoption of improved facilities as they become available. ="TofC7">

  Other authentication infrastructures

  It is worth briefly describing the relationship of the work described by this report and other authentication infrastructures that exist

  The PGP key-servers

  PGP currently provides a number of replicated key-servers providing a similar service to the authentication server described here. These key servers respond to requests by email or http for the public key of a user, and the recipient can then examine the signatures attached to the key to determine if they key is to be trusted. However, the key-servers suffer from appalling performance problems and are currently running out of steam holding of the order of 30000 public keys. This performance problem means that keys are not placed on the key-servers and therefore that the servers are not useful. A recent project by UKERNA intended to write and deploy a new high-performance key-server (still with a centralised architecture) capable of holding 1 million keys. This project has now been shelved.

  It is not clear that there is any benefit to be gained in re-using the PGP key-servers in the authentication infrastructure described in this document. The currently deployed servers are not capable of holding even a fraction of the keys that the UK academic community could generate. One alternative is to operate one PGP key-server per institution. However, the whole idea of the key-servers is that they are replicated, so therefore this does not offer a service to the wider PGP community (which is presumably the reason for considering re-using the key-server technology anyway). Another alternative is to implement the million key server planned by UKERNA and upgrade the whole key-server infrastructure (at least until the problem recurs after the millionth key is generated). However, this centralised solution does not offer the scaleable management required. Given that the PGP community does not make significant use of the key-servers, there seems little point in expending effort maintaining compatibility. It is much better to store the PGP keys directly on the authentication server.

  X.509 based infrastructures - PKIX and ICE-TEL

  There are a number of cooperating projects in existence (PKIX within the Internet Engineering Task Force, and ICE-TEL within the EC 4th Framework programme) that are defining and deploying infrastructures for authentication using X.509v3 certificates. These are proposing a variety of models for certificate distribution using X.500 directories, LDAP directories and World Wide Web. All these models will be designed to consider scalability of deployment and local management of local data. As such, they are ideal mechanisms for the authentication servers described here to use as the physical repository of X.509 public key information, and so this information will be available both to the UK academic community and to the wider X.509 community. This project is compatible with the aims and intentions of both ICE-TEL and PKIX (the author of this document is involved in both projects, so this is not surprising!)

  ="TofC8">

  Electronic mail

  It is convenient to start with secure electronic mail, as this is the application with the least stability and the most reliance on external applications and therefore the most complex solution (note that the World Wide Web also has these characteristics in abundance, but is not considered by this report). There are a wide variety of user agents in common use (see the report of the UKERNA secure email project for details of those in use within the UK academic community) and users tend to be very attached to the systems to which they are accustomed. If users are to be given the capability to send and receive secure electronic mail then this must be done in such a way as to minimise the impact on the users' working routine.

  Current use of secure email is based almost entirely around the PGP program, since there is no serious rival available. If the variety of mail user agents available adds some complexity to the problem then the variety of versions of PGP (and the certain knowledge that there will be new versions available in the near future) adds yet further complexity. Much work has been done integrating mail user agents with PGP, and this is done entirely by adding hooks in the mail program where the current version of the PGP program can be added in as a back end. So, when the user clicks the 'send' button on their mail program, the mail program will invisibly invoke PGP in the background. PGP will add the security services to the body of the email message, and the mail program will incorporate the results into the email message to be sent. This separation of the user agent from the implementation of security allows the mail program to be independent of specifics regarding the version of the PGP program, and also allows vendors to sell mail programs which can be exported anywhere in the world by avoiding US export restrictions on encryption.

  

  Figure 1 - standard integration of PGP with a mail user agent

  Modifying this arrangement to make use of the authentication servers could in theory be done either by modification of the mail user agent or by modification of the PGP program. However both of these are undesirable:

  • there are too many mail user agents in common use, and it would be impractical to modify all of them (many of them are not sufficiently configurable to modify without access to the source code, which is rarely available). Additionally, any modifications may have to be re-implemented whenever new software releases are made for the mail user agent (users like to use the latest versions, and computer service departments often do not like to support old versions), and this breaks our requirement for minimum re-engineering.
  • there are several different versions of PGP in common use, some of which are not available in source code form. Additionally, new versions are expected to be released regularly (though infrequently) in the future and it is possible that source code for these future versions could be completely unavailable (even if source code availability could be guaranteed, this would break our requirement for minimum re-engineering). Therefore, if PGP was to be modified to use the authentication servers, this would only be possible if a single version of PGP was selected and mandated for sole use, and this would impact people's ability to communicate with other users from other user communities.

  Therefore, an intermediate solution is needed which does not rely on the modification of external programs that are not under the control of anyone involved in the project.

  The PGP proxy

  The solution is to interpose a proxy between the mail user agent and PGP. This proxy has the same API (command line interface) as PGP, and any mail user agent that has been integrated with PGP can call the proxy instead with no modifications to the mail user agent. The proxy will determine what the user is doing, make the necessary calls to the authentication servers to gather the information required to make this work, construct the public and private keyring files that PGP will require and then invoke PGP. The work that the proxy has done ensures that PGP's operations will succeed.

  

  Figure 2 - integration of PGP with a mail user agent enhanced through use of authentication servers

  The proxy therefore provides a mapping between a mail user agent and PGP, and does not require either to be modified in order to make use of the authentication servers. In the event of new versions of either the mail user agent or PGP being released, the following work needs to be done:

  • in the event of a new release of the mail user agent, the changes to source code or configuration necessary to integrate PGP would have to be re-done (this would need to be done even with a standard integration of PGP)
  • in the event of a new release of PGP that has a different API, the mail user agent would need to be reconfigured to be aware of the new command line interface (this would need to be done even with a standard integration of PGP). Also, the proxy would need to be modified to be aware of the new command line interface and to use that interface when calling PGP.
  • in the event of a new release of PGP that has a new format for the public keyring file, the proxy would need to be modified to know how to construct the new file format.
  • in the event of a new release of PGP that used a new certificate format, the proxy would not need to be altered (except as a result on the changes to the keyring file formats that would necessarily also occur), though the authentication servers would need to update the information they held (this would need to be done for users' keyrings with a standard integration of PGP).

  It is difficult to accurately assess the effort that would need to be invested in tracking new versions of mail programs or of PGP. New versions of PGP are infrequent, well advertised and well documented, and the effort required here is undoubtedly small - the actual amount would obviously depend on the nature of the modification and this can't be predicted (a major change - such as adoption of X.509 certificates - would obviously require major changes to the proxy, however most changes would be expected to be significantly smaller than that).

  Updates to mail programs are, however, rather more frequent (needing to take into account changes in GUI preferences, enhanced functionality, incorporation of new protocols such as MIME or POP3). Combined with the fact that there are a lot of mail programs in use, there is clearly a potentially significant requirement for on-going effort. There is clearly no technical way round this (we have already divorced ourselves from the specifics of mail programs as far as we can), and it is a management issue how to cope with it:

  • by clearly specifying a small number of (the most commonly used) mail programs as "the only ones that are supported", effort can be concentrated in the most useful areas (this will be unpopular with users who are particularly attached to their antiquated system they've used for years)
  • by clearly specifying allowable versions of supported programs that can be used, the risk that some users leap ahead to the latest version and thereby make themselves incompatible with the rest of the user community can be minimised (though controlling what users do is next to impossible in practice)
  • these (and any other) measures clearly need the active cooperation of network managers at UK Higher Education institutes, and the establishment of some sort of "special interest forum in computer security" encompassing this group would seem to be a pre-requisite to deployment of security technology on any serious scale. The political way to achieve this is well beyond the expertise of the author of this document.

  Example

  As a worked example of the operation of the proxy in practice, suppose AJY@iti.salford.ac.uk wants to send a signed and encrypted email to PTK@cs.ucl.ac.uk.

  For AJY, the process of sending the message is as follows:

  1. AJY uses his PGP enabled mail program in the normal way and indicates the required security services.
  2. AJY's mail program calls the proxy.
  3. The proxy determines (from examination of the operation to be performed) that AJY's private key and PTK's public key are needed.
  4. The proxy makes an http connection to auth-server.ucl.ac.uk and retrieves:
     • a PGP key for PTK signed by the UCL CA;
     • a PGP key for the UCL CA signed by the UKERNA CA.

     For PTK, the process of receiving the message is as follows:

     1. PTK uses his PGP enabled mail program in the normal way and indicates that the message should be decoded
     2. PTK's mail program calls the proxy
     3. The proxy determines that PTK's private key and AJY's public key are needed
     4. The proxy makes an http connection to auth-server.salford.ac.uk and retrieves
        • a PGP key for AJY signed by the SALFORD CA
        • a PGP key for the SALFORD CA signed by the UKERNA CA
     5. The proxy optionally makes an http connection to root-auth-server.ukerna.ac.uk and checks that the PGP key for the SALFORD CA signed by the UKERNA CA is still valid.
     6. The proxy uses the public key of the UKERNA CA (from PTK's PSE) to verify the public key of the SALFORD CA is correct, and then uses that key to verify that public key of AJY is correct.
     7. The proxy then constructs a public keyring containing the public key of AJY, labelled as being completely trusted
     8. The proxy retrieves PTK's private key from his PSE and constructs a private keyring containing this key.
     9. The proxy then invokes PGP, requesting the same security services that the mail user agent requested
     10. PGP finds that it has the keys necessary to do the decryption and verify the digital signature
     11. The mail program captures PGP's output and displays this as the decoded mail message.="TofC11">

         Future developments

         In the long term, there are three external developments that need to be considered:

         • libpgp - future versions of PGP are likely to be provided as a library to be linked to the mail program, instead of as a separate application invoked on the command line.
         • S/MIME - support for the S/MIME protocol will grow, offering a serious rival to PGP (note that S/MIME uses X.509 certificates, whereas PGP uses it's own proprietary format)
         • mail user agents could be developed which perform the security operations themselves rather than relying on external backend programs. While these mail user agents would not be exportable from the USA, we have already seen that Netscape are willing to produce both US-only and exportable versions of their software, and so it is not an issue for major product vendors (it is also not an issue for non-American vendors). Once secure email protocols become stable and standardised, this is likely to become the normal method of implementation.

         Libpgp will not be a problem, provided dynamic library linking is used (which is common under both Windows and Unix). In this case, our proxy needs to work at the library call level rather than at the command line level, as currently envisaged.

         S/MIME is not a problem, provided it is integrated into mail user agents in an equivalent way to PGP. We can provide a separate version of the proxy which will sit in-between an S/MIME enabled mail user agent and an S/MIME implementation. As with the PGP case, the proxy needs to present the same API as the S/MIME implementation and it needs to know the file formats of the files used by the implementation so it can ensure that the correct keys are available when it is called.

         It would even be possible to provide a proxy that would interrogate the authentication servers to determine whether the recipient of a secure email message was a PGP user or an S/MIME user, and automatically create the appropriate type of mail message. In this way, a heterogeneous user community using both PGP and S/MIME could securely intercommunicate, at least to a certain degree.

         However, once mail user agents start implementing their own security instead of relying on external applications or libraries then it is very likely that there will no longer be an opportunity to insert an extra step into the certificate management process and insert code to utilise the authentication servers. For S/MIME it is possible that this will start to happen almost immediately since the first widely deployed implementations will be from big vendors (Microsoft and Netscape) with the resources to handle non-exportable versions (or the willingness to export crippled software with 40 bit encryption). However, traditional email programs such as Pegasus are likely to resist the effort involved in incorporating security technology and this will keep the proxy approach to integrating PGP and S/MIME valid probably for at least 5 years.

         ="TofC12">

         JISC services

         This sections refers to JISC services that are accessed via custom user agents and servers (as opposed to those being accessed via telnet or via the World Wide Web). These user agents and servers can be adapted to make use of the authentication servers.

         When a user connects to a JISC service, it is up to the user to decide the method of authentication that will be tried (this obviously depends on the capabilities of the user agent and the computer that it is running on). The user is assumed to know the authentication mechanisms that are accepted by the JISC service to be used (e.g. some may refuse to accept simple passwords, some may only accept strong authentication) and also is assumed to know the authentication mechanisms supported by the user agent running on the local computer (if there is no smart card reader then a smart card based PSE is obviously impossible to use; if there is no floppy disc drive of the correct size then a floppy disc based PSE is impossible; however all 'security enhanced' user agents should be capable of allowing the user to authenticate using challenge-response or S/Key one-time passwords).

         The examples of authenticated binds described in these sections show only authentication of the user by the server. It is also possible for the user to perform server authentication using the same techniques - all that is required is for it to be well-defined which authentication server holds the authentication information for each of the servers so that the users know how to validate it.

         ="TofC13">

         Authentication using simple passwords

         This section examines simple authentication of a user, where the authentication is via the sharing of a password between the user and the authentication server.

         With existing systems, passwords are exchanged as clear text. If user agents can be modified then passwords should be transmitted as X.509 protected passwords to prevent sniffer attacks. Servers should still be able to cope with plain text passwords and unmodified user agents.

         The stages in password based authentication using the authentication servers will be as follows:

         1. The user indicates to the server that simple authentication is required and sends his/her name and password to the server (this is in clear text if an unmodified user agent is used, or using X.509 protected passwords if a modified user agent is available)
            • remember that the user's email address is the best form of naming as it is guaranteed to be unique and readily identifies the institution where their authentication information will be held
         2. The server checks that the organisation is allowed to use simple authentication for this service (this is a coarse check that also filters out organisations that have no right to use the service at all)
         3. The server sends a command compare_simple_password name,password,serviceto the user's authentication server
            • if a clear text password is used in stage 1 then it should have X.509 protection applied to it at this stage.
         4. The authentication server sends a yes/no answer, signed by authentication server
            • YES means the password is correct and the users entry indicates that he/she is a registered user of this service
            • NO indicates either the password is incorrect or the user is not a registered user of the service
            The authentication server also returns the following certificates so that the response can be authenticated as being from the correct organisation's authentication server.
            • the certificate of the authentication server signed by the organisation's CA
            • the certificate of the organisation's CA signed by the UKERNA CA
            The server can optionally connect to root-auth-server.ukerna.ac.uk to verify that the certificate of the organisation's CA is still valid.

            Note that if X.509 protected passwords are used in stage 1 then the server does not know what the actual password is. It just knows the X.509 encoded version and whether it is correct or not.

            ="TofC14">

            Hardware one-time passwords (challenge-response cards)

            This section examines authentication of a user using hardware one-time-passwords implemented through challenge-response cards. In normal operation, the user and server share a password. The server communicates a random number to the user (a challenge). The user combines the challenge and the password using a pre-defined mathematical formula (with a challenge response card, this combining is done by a credit-card sized device that has the password built-in). The user returns the result (a response). The server repeats the combination using the locally held password and compares the result.

            The stages in password based authentication using the authentication servers will be as follows:

            1. The user indicates to the server that a challenge-response authentication is required and sends his/her name to the server.
            2. The server checks that the user's organisation is allowed to use challenge-response authentication for this service (this is a coarse check that also filters out organisations that have no right to use the service at all)
            3. The server invents a random number and communicates this to the user as a challenge.
            4. The user computes the response using their password card and enters the result into the user agent, which then returns it to the server.
            5. The server sends a command compare_challenge_response name,challenge,response,serviceto the user's authentication server
            6. The authentication server sends a yes/no answer, signed by authentication server
               • YES means the response is correct and the users entry indicates that he/she is a registered user of this service
               • NO indicates either the response is incorrect or the user is not a registered user of the service
               The authentication server also returns the following certificates so that the response can be authenticated as being from the correct organisation's authentication server.
               • the certificate of the authentication server signed by the organisation's CA
               • the certificate of the organisation's CA signed by the UKERNA CA
               The server can optionally connect to root-auth-server.ukerna.ac.uk to verify that the certificate of the organisation's CA is still valid.

               Note again that the server does not know what the password is, just whether it is correct or not.

               ="TofC15">

               Software one-time passwords (S/Key)

               This section examines authentication of a user using software one-time-passwords implemented using the S/Key algorithm. S/Key requires that the result of the previous successful S/Key login is stored on the authentication server. Therefore, as a precondition to the S/Key authentication, we assume the following information is held securely on the server:

               • {password,seed}HASH1000
               • the seed
               • the number 1000

               This effectively means that the user has 1000 logins remaining using the current S/Key password.

               The stages in S/Key based authentication using the authentication servers will be as follows:

               1. The user indicates to the server that S/Key authentication is required and sends his/her name to the server.
               2. The server checks that the user's organisation is allowed to use challenge-response authentication for this service (this is a coarse check that also filters out organisations that have no right to use the service at all)
               3. The server sends a message to the user's authentication server asking for the next S/Key challenge for the user
               4. The authentication server returns a challenge "seed,999", signed by the authentication server. The authentication server also returns the following certificates so that the response can be authenticated as being from the correct organisation's authentication server.
                  • the certificate of the authentication server signed by the organisation's CA
                  • the certificate of the organisation's CA signed by the UKERNA CA
                  The server can optionally connect to root-auth-server.ukerna.ac.uk to verify that the certificate of the organisational CA is still valid.
               5. The server sends the challenge to the user
               6. The user enters their S/Key password into the user agent (or it is automatically extracted from their PSE), and the user agent uses this to calculate the appropriate response {password,seed}HASH999, and returns the response to the server.
               7. The server sends a command compare_skey_response name,response,serviceto the user's authentication server
               8. The authentication server hashes the response and compares it to the stored value. If they match then it overwrites the user's S/Key data with {pw,seed}HASH⁹⁹⁹ and the number 999.
               9. The authentication server sends a yes/no answer, signed by authentication server
                  • YES means the response is correct and the users entry indicates that he/she is a registered user of this service
                  • NO indicates either the response is incorrect or the user is not a registered user of the service
                  (the associated certificates needed to verify the message have already been sent earlier in the bind)

                  If there are two simultaneous or overlapping attempts to use S/Key authentication by the same user then both will receive the same challenge and both (if from the correct user) will compute the same response. However, only one of them will succeed (provided that the authentication server is able to correctly lock the information in stage 8) - the login whose compare message arrives at the authentication server later will not match and a NO response will be returned. However, retrying will be successful (as long at there are not further concurrent login attempts). Overlapping requests should be unusual in practice.

                  ="TofC16">

                  Strong authentication

                  This section examines strong authentication of a user by a server. The user agent needs to be able to examine the user's PSE in order to access the private key (needed to create the digital signature) and the supporting certificates (to be sent as part of the bind process in order to allow the server to verify the user's public key).

                  The stages in strong authentication using the authentication servers will be as follows:

                  1. The user indicates to the server that strong authentication is required
                  2. The user creates a bind token containing:
                     • the user's email address
                     • the time (to prove freshness)
                     • a digital signature (hash value encrypted with the user's private key) signing the above information
                     and sends the entire bind token to the server.

                     ="TofC17">Confidentiality

                     Implementation of confidential communications obviously requires both user agent and server to be modified to be aware of the encryption (unless the underlying communications infrastructure takes care of this - this will have to wait of IP-SEC or IPv6). Therefore, there is no need to support backwards compatibility with insecure user agents or servers.

                     Confidentiality also requires the sharing of a secret (the symmetric encryption key that will be used to encrypt packets passed between user and server). For this reason, it is probably advisable to insist that both user and server authentication are performed prior to initiation of encrypted communications.

                     If the user authenticates itself using strong authentication then the server will, at the end of the authentication process, possess a validated copy of the user's public key. The server can then invent a random symmetric encryption key, encrypt this asymmetrically with the user's public key and send this to the user knowing that only they will be able to decrypt it (similarly, if the server authenticates itself with strong authentication then the user can do the same thing). In this way, secure communications can be established.

                     If simple authentication or one-time passwords are used then different mechanisms are needed. The server can use the user's authentication server to fulfill a similar role to the Kerberos key-server described in the Young/Kirstein/Ibbetson paper.

                     The following description outlines possible approaches to key generation to demonstrate the principles. These are not meant to be rigorous specifications of protocols.

                     1 The server sends a message to the user's authentication server requesting a key. The message will say what form of authentication was used and will include the public key of the server and the certificates needed for the authentication server to verify this key.

                     2.1 If the user was authenticated using a password then the authentication server invents a random number that will be used as a symmetric encryption key. The authentication server:

                     • encrypts this key asymmetrically with the public key of the server; and
                     • encrypts this key symmetrically with a hash of the user's password.

                     This information is all signed and passed back to the server. The server passes the second part of this to the user, and each can decrypt the symmetric key.

                     2.2 If the user was authenticated with hardware-based one-time passwords then the server invents a random number to use as a challenge, and calculates the corresponding response. The authentication server encrypts the response asymmetrically with the public key of the server, and then sends a digitally signed message containing the challenge and the encrypted response to the server. The server passes the challenge to the user, who then calculates the response while the server decrypts the same response. Both user and server can then use the response as a symmetric key to encrypt the subsequent communication.

                     2.3 If the user was authenticated with software-based one-time passwords then there is nothing that can be done. All the information stored on the authentication server was transmitted in clear text during the authentication process, and therefore there is nothing that can be used to allow the authentication server to transfer information confidentially to the user. Note that, as currently specified, the server does not hold the S/Key password that is used by the user to calculate the response to the challenge. If this is stored on the server then this will be a suitable mechanism as it is never sent over any network. The overall process then becomes the same as for simple passwords, described above.

                     If the server is authenticated to the user then the user can also take similar steps to initiate the key generation process.

                     With FTP, there is also the added option of encrypting the data rather then the communications connection. PGP can be used to encrypt the files stores on an ftp server, and these will only be readable to authorised people who download them. An intelligent user agent could spot when an encrypted file was being downloaded and act accordingly. This would, of course, not require any modification to the ftp server.

                     ="TofC18">

                     Telnet and FTP

                     These protocols are simple, well defined and stable; and users tend not to demand specific user agents (though graphical FTP user agents are becoming more widespread). Therefore there is no need for the implementation of secure versions to build in flexibility with respect to changes in either the protocol or dependent applications. A single customised user agent and server for each protocol and each platform can be developed and provided to the user community, with the modified user agent and server taking advantage of the authentication servers where appropriate.

                     Development is further eased by the fact that public domain source code implementations of telnet and graphical FTP user agents and servers are available and can be modified. Note, however, that the situation with shareware is not so clear. While some shareware authors may be willing to provide hooks in their product to enable security to be added on by external modules, American authors are prevented from doing this by the US export regulation. Therefore, it is best to enhance a publicly available implementation, and nominate that as "approved for secure use within the UK academic community".

                     The bind process for telnet and ftp with all four sorts of authentication is exactly the same as is described in Section 4 "JISC services" and there is no need to repeat it here. However, security enhanced telnet and ftp user agents and servers are much more likely to find themselves communicating with non-enhanced versions, and so it is worth spending time here to consider the way in which user agent and server interact

                     Modified user agent talking to modified server

                     As with non-modified versions of the program, the user agent is assumed to initiate the interaction, and the server is assumed to lead the user through the authentication process (again, we are only considering user authentication; server authentication can be added by the same mechanisms)

                     The server leads with a prompt saying something like
                     Login:
                     where the user is intended to type in their account name. If the user wishes a conventional interaction then they could do this. However, if the user knows that the server has been security enhanced, then he/she could type something here to indicate they wish to use this enhancement. For example: (bold type indicates typed in by user)

                     For simple authentication:
                     Login: auth=simple
Enter your email address: A.J.Young@iti.salford.ac.uk
Enter your telnet password: (not echoed)
                     Authenticated "Andrew Young, I.T.Institute, Salford University"

                     For hardware-based one-time passwords:
                     Login: auth=onetime
Enter your email address: A.J.Young@iti.salford.ac.uk
Challenge is 0471947235
Enter response: 973645273
Authenticated "Andrew Young, I.T.Institute, Salford University"

                     For software-based one-time passwords:
                     Login: auth=skey
Enter your email address: A.J.Young@iti.salford.ac.uk
Enter your s/key password: (not echoed, or can be retrieved from PSE)
                     Authenticated "Andrew Young, I.T.Institute, Salford University"

                     For strong authentication:
                     Login: auth=strong
                     (user agent locates user's PSE)
                     Authenticated "Andrew Young, I.T.Institute, Salford University"

                     An enhanced user agent called from the command line could also be written to include command line switches:
                     telnet -strong host.institution.ac.uk
                     which will automate the first part of the dialogue between user agent and server.

                     Unmodified user agent talking to modified server

                     The simple authentication example described should still work (though the password will necessarily be sent to the server in clear text). The hardware-based one-time password will also still work. However, S/Key and strong authentication both require some extra intelligence in the user agent, and so these will not work if an unmodified user agent is used.

                     Modified user agent talking to unmodified server

                     If an unmodified server is contacted and the user attempts to access enhanced security services then the server will assume the "auth=strong" request is a user name and will respond with "Password:". The user agent can spot this and can inform the user that enhanced security is not available, followed by degrading to use of normal authentication.

                     Unmodified user agent talking to unmodified server

                     If an unmodified server is contacted and the user attempts to access enhanced security services then the server will assume the "auth=onetime" request is a user name and will respond with "Password:". Here, this will be passed directly to the user and it is up to the user to infer from this that enhanced security is not available.

                     ="TofC19">

                     Other considerations

                     Resilience

                     In the event that there is a hardware failure or network failure that causes an authentication server to be unavailable, it will be impossible for users whose authentication data is stored on that server to be authenticated, and therefore they could be denied access to essential services that could prevent them doing their work:

                     • JISC services would be unable to authenticate the user and unable to determine if the user was authorised to access the service - this is likely to be a critical failure from the user's perspective of their ability to do their job. In this event, there must be some planned fallback to traditional methods of authentication possibly based on institutional passwords. This would be explicitly enabled after suitable authorisation (such as a telephone call to or from the network manager of the affected site to confirm that there is a problem) and could be automatically disabled if the authentication server became available again. The existence and details of this sort of fallback scheme would be part of the service provision agreement between the user's organisation and the server's operator.
                     • Users would be unable to send confidential email - this is likely to be a critical failure from the user's perspective. However, if the PGP proxy keeps a cache of validated public keys that have been recently retrieved then the user can choose whether to use the cached key instead of freshly re-retrieving it (the user's PSE is the ideal place to keep this cache). The user is taking the added risk that the key could have been changed or withdrawn since it was last retrieved (possibly because the private key was compromised), but this risk may be acceptable depending on the nature of the email (the sender can also telephone the recipient to find out if their key has been withdrawn, they are then taking the risk that they are talking to the correct person). Therefore, the main effect of a failure is that users would be unable to send confidential email to a user they had not previously corresponded with, and this may not be considered as serious a problem.
                     • Users would be unable to verify authenticated email - this is likely to be a non-critical failure, as the message contents would still be readable and the message could be authenticated later when services had resumed. Additionally, if a cache of recently validated public keys were kept by the PGP proxy then user could provisionally check the authenticity of the message (subject to the proviso that the key could have been changed or withdrawn since it was last validated).
                     • Telnet and FTP from external sites would be unable to authenticate the user - this is likely to be a critical failure. However, telnet and ftp servers that are unable to use the authentication servers could gracefully degrade and use the conventional local password file as a fallback, providing some continuity of service (requiring users to remember the fallback password - as it is hoped they would be used infrequently then it is likely they could be hard to remember).

                     For added resilience, to make sure these problems are less likely to occur, organisations may choose to have two authentication servers, preferably with as little common communications infrastructure as possible. The second would be identical to the first except it's DNS name would be auth-server2.institution.ac.uk, and applications making use of the authentication servers should know that this should be tried if connection to the primary server fails.

                     If replication of the authentication server is implemented then particular care must be taken with replication of data that changes over time. In particular, the following data can be changed by the authentication server:

                     • Information relating to S/Key will be over-written every time a successful S/Key login is made. If the change is not made simultaneously to all replicas then there is the possibility that the user may be able to make two logins with the same S/Key challenge, which would violate the pre-payment schemes that S/Key is designed to implement (though would not necessarily be a security disaster)
                     • Users can change their simple passwords by telnetting to the authentication server, and this must be propagated to all replicas (it is probably acceptable for there to be a noticeable propagation delay while this happens - for the password.demon.co.uk system mentioned earlier, this can be of the order of hours)

                     It is doubtful that there is a need for massive redundancy such as uninterruptable power supplies or off-site location of the reserve authentication server, as long as some level of fallback access can be achieved for all services. Also, the problem of maintaining offsite replicas of data that is very sensitive regarding confidentiality and integrity is great, and may outweigh the perceived advantage gained.

                     ="TofC21">

                     Conclusions

                     This report has shown how security services can be implemented for deployment around the JANET community using the model proposed by Bell/Wiseman. The solutions are proprietary but consider the issue of interoperation with members of other user communities.

                     The proposed solutions require the following initial software development:

                     • Authentication server - converts http requests for data into queries to a local database and digitally signs the results. Also allows telnet access for password modification.
                     • CA tools - to generate X.509 certificates and signed PGP keys for users (some tools to assist bulk generation and transfer to the authentication server will also be useful)
                     • PGP proxy - to interface between the mail user agent and the PGP program
                     • Integration of PGP into mail user agents
                     • JISC services - integration of enhanced security into servers and user agents
                     • Telnet and FTP - integration of enhanced security into servers and user agents

                     with the following infrastructure:

                     • Authentication server (probably a high spec PC) within each participating institution
                     • Certification authority (responsible person) within each participating institution
                     • Authentication server operated centrally, possibly by UKERNA
                     • Certification authority operated centrally, possibly by UKERNA

                     the following on-going development:

                     • Consolidation of new versions of mail user agents and of PGP

                     and the following required study:

                     • Analysis of the current smart-card market

                     For the purposes of a preliminary pilot deployment phase, the implementation could be simplified as follows while still being useful and allowing the full range of capabilities to be demonstrated:

                     • Authentication server - allow only one form of local database for storage of the authentication server information for the participating organisations (in a full deployment you would need more flexibility to fit in with the working practices of all organisations, but for piloting a more rigid approach is acceptable).
                     • CA tools - handle only PGP keys initially.
                     • PGP proxy - cannot really be simplified.
                     • Integration into mail user agents - allow only use of Pegasus Mail for Windows (a pointer to a Pegasus/PGP integration is included at the end of the document). If a unix option is required to demonstrate interoperability then allow only MH (there is also a pointer to a MH/PEM integration at the end of the document).
                     • JISC services - select one service for initial security integration.
                     • Telnet and FTP - implement a server for unix and a user agent for PCs initially.
                     • PSE - floppy disc based only

                     Even this simplified pilot project is a substantial implementation project involving complex technology. As a first estimate, at least a man year should be allocated to the pilot implementation (more if the implementors are unfamiliar with security technology).

                     The author of this document believes that a project to implement and deploy these services is reasonable and viable and has no hesitation in recommending that it should continue to the next phase.

                  3. The server connects to the user's authentication server to retrieve the certificate containing the user's public key signed by the organisation's CA and also the organisation's CA's certificate signed by the UKERNA CA.
                  4. The server can optionally connect to root-auth-server.ukerna.ac.uk to verify that the certificate of the organisation's CA is still valid.
                  5. The server uses the public key of the UKERNA CA (from it's own PSE) to verify the public key of the user's organisation's CA is correct, and then uses that key to verify that user's public key of AJY.
                  6. The proxy optionally makes an http connection to root-auth-server.ukerna.ac.uk and checks that the PGP key for the UCL CA signed by the UKERNA CA is still valid.
                  7. The proxy uses the public key of the UKERNA CA (from AJY's PSE) to verify the public key of the UCL CA is correct, and then uses that key to verify that the public key of PTK is correct.
                  8. The proxy then constructs a public keyring containing the public key of PTK, labelled as being completely trusted.
                  9. The proxy retrieves AJY's private key from his PSE and constructs a private keyring containing this key.
                  10. The proxy then invokes PGP, requesting the same security services that the user requested.
                  11. PGP finds that it has the keys necessary to do the encryption and the digital signature.
                  12. The mail program captures PGP's output and incorporates this into the mail message.
                  13. As well as needing the information required to authenticate themselves to the computer service they use, improved authentication services will allow users to authenticate these computers and be sure they are accessing the correct service. This is yet more information for the user to manage.