Pilot service for Yubikey two-factor authentication

This is the final report for Project 313 - Pilot service for Yubikey two-factor authentication.

Contents

1. Introduction

This project follows on from the earlier Project 279 - Options for two-factor authentication.

The specific aim of this project was to 'to set up a ssh/Cosign testing/pilot service based on two-factor Yubikey authentication, usable by C(S)Os.' That aim was achieved.

Production services similar to the test ssh and Cosign services described here could now be deployed, if desired. The necessary effort, and remaining issues, are more-or-less as described in 'Section 5. Future work' below. Questions of scalabity also need to be considered.

The principal outstanding technical question is probably that of support for more than one type of two-factor authentication in any service which we might like to provide.

More general questions behind this project are: in which exact circumstances do we want to employ two-factor authentication?; and by which exact mechanism(s) should we choose to implement it? We don't consider those crucial questions here, but some of the following discussion is relevant.

2. Outcome of the project

This project has produced LCFG configuration and setup to support the following:

  1. A test ssh service which implements two-factor authentication via Yubikeys: quail.inf.ed.ac.uk
  2. A test Cosign server which supports two-factor authentication via Yubikeys: albatross.inf.ed.ac.uk a.k.a. https://webloginotptest.inf.ed.ac.uk
  3. Several test Cosign client sites which implement two-factor authentication via Yubikeys by authenticating against the above Cosign server:
    1. Canonical test site: https://canary.inf.ed.ac.uk
    2. Test Theon Portal (running on stoner.inf.ed.ac.uk): https://otptestportal.theon.inf.ed.ac.uk/
    3. Site containing Jabber logs of the cos chatroom: https://jabber.inf.ed.ac.uk/logs/cos/

In addition:

  1. Distribution of Yubikeys to all C(S)Os, allowing each C(S)O to test/pilot any or all of the above.
  2. Test YK-VAL and YK-KSM servers, in order to prove on-site Yubikey authentication: petrel.inf.ed.ac.uk (a.k.a. ykval0.inf.ed.ac.uk), and shearwater.inf.ed.ac.uk (a.k.a. ykksm0.inf.ed.ac.uk), respectively. (Note that setting up and testing synchronized arrays of such servers - as would probably be required for a true production service, has not been tested in the course of this work.)

3. Implementation details

3.1 General

  1. All test services currently implement Yubikey authentication via Yubico's pam_yubico PAM module. That module allows for either remote authentication against the Yubico cloud authentication service, or for internal authentication against a locally-managed service.
  2. All test services currently authenticate Yubikeys remotely via the free Yubico cloud authentication service. This allows Yubikeys to be used as delivered, with no reprogramming being necessary.
    (Pros and cons of the use of the cloud service for our purposes are discussed at http://blog.inf.ed.ac.uk/project313/2016/02/23/is-a-local-authentication-service-necessarydesirable/)
  3. All test services currently arrange their username <->Yubikey public id mappings (used by the the pam_yubico module to formally associate usernames with Yubikey public ids) via a local file created from a live LCFG header file.
    (For a production environment, that should probably be improved by storing such data in LDAP, and reconfiguring the pam_yubico module to do appropriate LDAP lookups.)

3.2 Test ssh service

  1. Kerberos/GSS-API authentication is embedded in OpenSSH in a way which preempts the PAM stack - so any attempt to use the test ssh service from a user/client which already has good Kerberos credentials will 'bypass' two-factor authentication. Therefore, to test the ssh service from an internal DICE machine, first kdestroy.
  2. Since the intention was (and still is) that two-factor authentication would not be imposed on all users, the ssh service currently chooses (via pam_succeed_if) whether or not to impose two-factor authentication depending on whether or not the user involved is a member of a particular Unix group on the server.
    (For a production environment, that should be improved by replacing the use of a local Unix group by the use of a netgroup supplied via LDAP.)

3.3 Test Cosign services

  1. All test Cosign services currently authenticate against a dedicated Cosign server webloginotptest.inf.ed.ac.uk. That means that Cosign cookies are not currently shared with our standard Cosign servers, and, therefore, that 'single signon' currently doesn't work transparently between the test Cosign services and the rest of our production Cosign services.
  2. Internally, the Cosign servers use Yubico's pam_yubico PAM module to arrange the authentication of the Yubikeys. That module is accessed by a generic 'PAM factor adaptor' module supplied as part of the Cosign tarball. That same abstraction layer could be employed to authenticate any other type of second factor, provided that an appropriate PAM module is available (or is written.)
  3. Cosign clients declare the requirement (or not) for two-factor authentication at the granularity of directories or files, by use of the CosignRequireFactor directive. (Such directives can be placed either in Apache conf.d configuration files, or more locally in .htaccess files.) The most recently declared such directive is the (only) one which is applied - to be clear: successive such directives neither 'accumulate'; nor are they 'OR'ed.
  4. For the test Theon portal website, such directives (which in this case appear in .htaccess files) have been arranged via hand-edited additions to the relevant TP000...Access files. Currently, a single directive has been applied at the site entrance by appending the following gurgle code to the end of the top-level TP000_Access file:
    %%footer

    CosignRequireFactor INF.ED.AC.UK otp
    Such hand-edited configuration will not survive Theon conduit RPM updates, but arranging for these directives to be applied in a more robust manner - and also a more granular manner, if desired - is probably best left to those responsible for the Theon service.

4. Discussion

4.1 General

  1. This project has provided the test services which were specified - but how useful those services are for testing is open to question. It took a (very) long time to decide on what would be a good candidate for a test Cosign service: we eventually chose the Theon Portal, but for really serious testing we probably need to impose two-factor authentication on some resource(s) which all COs regularly use. The imposition of two-factor authentication on the Jabber logfile webserver was an attempt - in the very late stages of this work - to do that.

4.2 Cosign

  1. The current design of Cosign assumes the use of only one kind of two-factor authentication. (Specifically, for example, the Apache Cosign filter does not implement 'OR' functionality.) If we want to allow options for the second factor (e.g. Yubikey OTP, or Google Auth OTP, or etc.), then significant effort will probably be required to amend Cosign itself, and/or its Apache filter.
  2. The Cosign weblogin user interface presents a more-or-less standard view to all clients, irrespective of which factors are being requested. As a consequence: if we introduce two-factor authentication to our Cosign service, then all users of Cosign will be aware of the two-factor input fields, irrespective of whether or not those are relevant to the user/website in question. A possible alternative is to set up a distinct two-factor Cosign service, and have that used by Cosign client websites as required. That would fix the 'user interface problem' alluded to here (if, indeed, that is considered a problem) but, as in 3.2 above, it would break the 'single signon' model, unless it were possible to have the new Cosign service replicate cookies with the existing Cosign service. Whether such replication can be made to work isn't yet known.

5. Future work

If we do decide to proceed with the use of Yubikeys for two-factor authentication, then the following observations are relevant:

5.1 General

  1. For large-scale and/or critical use of two-factor authentication, or in a situation where no possibility of disruption caused by external outage can be tolerated, we might want to move to the use an internal authentication service rather than the free Yubico cloud authentication service. This exact issue was discussed at the Development Meeting of 2016-03-02 - see item 1.1 from the the summary of that meeting - and the conclusion was that, for now, the cloud service is a good pragmatic solution. In the course of the current project, we have implemented and tested a hand-configured local authentication service - but there would be significant work involved in getting such a service completely integrated into LCFG. Any such production service would probably need to consist of arrays of synchronized YK-VAL and YK-KSM servers, in order to avoid single points of failure.
  2. Truly large-scale use would almost certainly imply some kind of user portal via which users could upload and/or change the details (at least the public id; more likely, if we were doing internal authentication, both the public id and the AES key) of the Yubikey they choose to use.
  3. In principle, it should be possible to arrange Yubikey two-factor authentication for literally any service which authenticates via PAM - so services like OpenVPN should be good candidates. One can also imagine using the same techniques to impose second-factor authentication on tools like nsu, rfe, etc. (Of course, we need to be very sure that we don't create the possibility of chicken-and-egg problems in cases where service failure means we no longer have access to resources which we might need in order to fix the service problem.) If we do adopt the use of Yubikeys, then all such options should be investigated.

5.2 ssh service

  1. If significant numbers of users are expected to use the service, we should set up mechanism(s) to automatically populate the LDAP-provided netgroup which is used by the ssh server to decide whether or not to impose two-factor authentication on a per-user basis. (The alternative is to insist that everybody using the service uses two-factor authentication.)

5.3 Cosign

  1. We should integrate the build and installation of the general purpose 'PAM factor adaptor' into the build/install of our local Cosign server RPMs. (The PAM factor adaptor itself is supplied as C code in the Cosign tarball, but is otherwise not attended to by the ./configure; make; make install sequence.) Note that the final installation of the PAM factor adaptor requires the creation of symlinks which match the particular names of the factors to be used.
  2. We should tidy up and package the local Informatics Cosign HTML templates so that they present two-factor entry fields (and help information, etc.) in exactly the way we want them.
  3. If significant numbers of users are expected to use the service, we should set up mechanisms to automatically populate in LDAP the necessary username <->Yubikey public id mappings, and then reconfigure the pam_yubico PAM module throughout to use appropriate LDAP lookups rather than a named local file.
  4. We should decide the issues discussed in 4.2.2 above - namely, do we want to have two-factor authentication visible on all of our Cosign servers, or do we want to set up a distinct 'two-factor' Cosign service?
    1. If the second: investigate whether or not replication can be made to work between the two services.
    2. Either way: set up the Cosign service(s).
  5. With the above work complete, Cosign client website configuration is essentially trivial: point the Cosign client authenticator of the website in question at the appropriate Cosign server; and apply CosignRequireFactor directives on the client website as required. We should provide LCFG headers to automatically arrange the first of those two requirements.

6. General remarks

  1. The lack of easy support for more than one type of two-factor authentication seems to me to be a serious limitation of Cosign. Nor does Cosign necessarily appear to be a very active project any more. Are there better alternatives to Cosign of which we are unaware? Otherwise - have I misunderstood the situation? Are there easy ways to work around Cosign's apparent shortcoming in this respect?
  2. If and when we do start imposing two-factor authentication, then it might be that we want to apply different rules depending on whether or not the user is accessing the service(s) from an internal connection, or from an external one. We need to clarify what any expectations are in that respect, and make sure that our proposed solution can satisfy them.
  3. The University of Michigan - the inventors of Cosign - appear to be using it with two-factor authentication apparent on all of their weblogin pages, irrespective of whether or not the client websites involved require the second factor or not. (See https://weblogin.umich.edu, and note the 'MToken' field.) That is, they don't try to 'hide' the second factor fields, even though they might not be required in any particular case.
  4. MIT appear now to be mandating two-factor authentication for everything. They are using Duo Security, and their interfaces allow the use of a variety of types of second factor: the user can mix and match, and choose which type they would like to use on any particular occasion. (See http://kb.mit.edu/confluence/display/istcontrib/Two-Factor+Authentication+with+Duo for more information.)
    Among other second factor methods, they do allow the use of personal Yubikeys (authenticated against internal servers), and provide a registration portal through which any user can upload the relevant details (i.e. public id and AES key) of their own Yubikey. Yubikeys used for this purpose necessarily need first to be reprogrammed (by their owner): in doing so, such Yubikeys then cease to be usable against other services for which they might previously have been valid - as MIT's user-facing documentation makes clear.

7. Lessons learned

The following are all general points, essentially unrelated to the detail of the work discussed above.

  1. There are many distinct aspects to the work which has been undertaken in the course of this project - for example: the general integration of two-factor authentication into the existing Informatics Cosign setup; and the quite new and specific investigation of how to set up an internal Yubikey authentication service - and it seems to me that this is a good example of a project which could have been better handled by a small team consisting of more than one person. In particular, if a rapid outcome to the project was desired, it would have been useful to have had the detailed Informatics Cosign aspects handled by somebody already familiar with the details of that service.
    The customary position here is that all work for a specific 'project' is assigned to a single individual. I realise that there are 'knowledge transfer' counterarguments but, in any case, I pose here a general question about the internal custom and practice pertaining to project assignment and management.
  2. Time was spent on some aspects outside the formal scope of the project: specifically, the establishment of a prototype internal Yubikey authentication service. I consider that a necessary and useful effort - but it is not one which was formally specified as part of the work.
  3. Time was wasted owing to a lack of clarity about what might be useful, and about what, in detail, was actually wanted. That applies particularly in the case of the test Cosign client websites. The canonical test website has been available for a long time - but, since it does nothing in particular, all that happens is that it gets tried once, and then ignored - which is pointless if we are trying to give the service a serious test. Any future project should be wary of abstract goals like 'set up a test Cosign website for use by COs': it would be much better to have well-defined and clear aspirations - in this case, exactly what function the actual test website is to perform.
  4. Time was wasted in the stop-start nature of the work - which is partly correlated with uncertainties connected with the above point. There are numerous details to try to remember, and, if the work is put down for a while and then later taken up again, they all have to be relearned.
  5. The requirement for a project blog (in this case http://blog.inf.ed.ac.uk/project313/) seems questionable. In the current case, I have no evidence that anybody other than myself took any notice of it. It did have some value as a personal 'journal' for the project; but, on the other hand, since it's a completely public entity, I was reluctant to include in it complete nitty-gritty local details: those seem inappropriate for an 'informational blog', and, in any case, might reveal information which could be useful to an attacker. So I am not sure of the intended purpose and use of our project blogs: in cases like this, there appears to be a tension between their use as a 'publicity/advocacy vehicle', and their use as a comprehensive and complete 'project journal.'

8. Effort

The total effort for this work was about 30 days, spread over more than one calendar year.

Appendix

RT ticket RT#76661 contains correspondence between various COs which is germane to some of the implementation points raised in this report.

-- IanDurkacz - 17 Mar 2016

Topic revision: r13 - 06 Apr 2016 - 16:19:47 - IanDurkacz
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies