Pubcookie location based authentication

scenarios

the library problem

The problem that has forced this issue to the fore-front is the library/Shibboleth pilot. Many resources on the Internet are licensed by CMU to be accessed by CMU persons: faculty, students, and staff. These resources are generally also available to physical visitors to the CMU library system. Generally, these resources are currently protected by IP address restrictions, making it a pain to support CMU persons off of the CMU network.

Shibboleth is a system developed by Internet2 to address cross-site authentication and attribute release issues. The immediate application envisioned for Shibboleth is replacing the IP address restrictions.

It is required for the Shibboleth solution allow for anonymous in-library access in addition to roaming CMU access.

operations

An imagined scenario: Computer Operations has some console machines which display monitoring information and may be able to take action on certain services. It is desired that physical access to the operator's room is sufficient to use these consoles, since operations has a large turnover and maintaining the access list could be burdensome or even a impediment in the case of a crisis situation.

Such a scenario would require secure identification of the location of the terminal, resisting both spoofing and cloning.

In other ways, this scenario is easier since it involves no Shibboleth interaction.

brief overview of shibboleth

Shibboleth, as intended for deployment at CMU, involves leveraging CMU's Pubcookie deployment for intra-domain authentication services.

A sample session involves:

  1. User visits a Shibbolized protected site protected.com.
  2. protected.com sees no existing authorization to use its service, and directs the user to a "Where Are You From" (WAYF) service, possibly located at protected.com or possibly elsewhere.
  3. The user selects "Carnegie Mellon" from some interface on the WAYF.
  4. The user is redirected to CMU's local Shibboleth handle server, shibboleth.web.cmu.edu.
  5. The local Shibboleth handle server sees no existing session for the user and redirects the user to CMU's Pubcookie login server at webiso.andrew.cmu.edu.
  6. Lacking a single sign on cookie, Pubcookie presents the user with a login dialog box. (a)
  7. The user enters a valid username/password pair. The login server sets a single-sign on cookie (scoped only to the login server) and then redirects the user back to CMU's Shibboleth server, with an authentication assertion.
  8. CMU's Shibboleth server sees the authentication assertion and sets another cookie scoped only to it identifying the user for further Shibbolized interactions.
  9. CMU's Shibboleth server then redirects the user back to protected.com with an opaque handle.
  10. protected.com can then make use of this opaque handle to query CMU's attribute authority, aa.cmu.edu, for information on the user.
  11. CMU's attribute authority looks at the rights of protected.com to retrieve information about this user and returns an attribute assertion that the user is a member of the CMU community.
  12. protected.com then serves the protected page to the user.

Step (a) is obvious the major problem for the library's use case. An anonymous physical visitor to the library may not have an Andrew id and password or does not wish to identify herself. It is therefore impossible for Pubcookie to return an authentication assertion to the local Shibboleth service.

how to identify specific machines

All of this is leading up to Pubcookie needs a way of creating authentication assertions for the user's current location. How can Pubcookie identify where the user is?

A machine-based authentication assertion would be expected to assert the user is logged on to a machine identified by a fully qualified domain name, FQDN, like penguin.andrew.cmu.edu.

ip addresses

The current method for machine-based security uses the request's source IP address. This is annoying for several reasons:

It is therefore not recommended to use IP addresses to identify machines.

external software callbacks a la Sidecar

long-term cookies

A cookie scoped to the login servers contains a signed assertion of the machine's name, verifiable by the login server.

Upsides:

Downsides:

Technical details:

external software rotating cookies

Similiar to the above, this solution makes use of the local computer's access protection to synthesize new cookies locally. The local computer, in a protected process, would be given access to a key whose signature can be verified by the login server. Every X minutes, the local computer creates a new cookie asserting the machine's identity.

Upsides:

Downsides:

hardware devices

Finally, both "external software rotating cookies" and "external software callbacks" can be enhanced by the use of a hardware token. Hardware tokens are resistant to cloning—while they don't prevent theft, presumably the absence of a device will be more obvious than someone copying a cookie or a key.

The major problem with introducing hardware devices is that it complicates further the local programming needed by those solutions.

actual location

None of the above solutions actually identifies the user's physical location, which would be desirable. Such a solution could leverage network infrastructure databases to map an IP address to the last known trusted port, and proceed accordingly.

Another possibility would be to use a trusted LDAP directory to map from FQDN to physical location.

The security of this solution depends on what solution was chosen to authenticate a given machine.

It is recommended that until the infrastructure to deal with physical locations is developed, access control be done by FQDN.

authorization issues

Shibboleth ultimately wants to give the user the union of the user's entitlements, the machine's inheritable entitlements, and the location's inheritable entitlements.

How to maintain a directory of these entitlements and encode them all the way through the Shib process is a very open question.

a solution using flavors

Pubcookie supports multiple "flavors": different policies enforced by the login server. Any Pubcookie application (the Shibboleth service is a Pubcookie client application) may request the services of any of the supported flavors.

Currently, CMU has two different Pubcookie flavors implemented:

basic
The standard require a username/password (from any Kerberos realm) and return an authentication assertion with the username.
getcred
Require a username/password and return an authentication assertion with the username and a Kerberos ticket in the user's name good for a requested service. The flavor also has some login server policy constraints preventing any Pubcookie application receiving a Kerberos ticket for arbitrary services.

a short-term solution

The easiest-to-implement short term solution would be to implement a new flavor, call it "machineoruser".

This flavor would return a FQDN identifying the machine, if that can be done without user interaction, or return a principal identifying the user, prompting the user if necessary.

A Pubcookie assertion of FQDN would contain an empty username with a cookie extension of machineFQDN=library1.whatever.cmu.edu.

The Shibboleth service would then request the services of "machineoruser" instead of the Pubcookie "basic" flavor. The implementation of this is relatively straightforward.

Interesting interactions:

in the longer term

In the longer term we will need a way for Shibboleth to authenticate a user when that becomes necessary, even if it already has machine or location information on that user.

Shibboleth could also make use of other advanced features not implemented in Pubcookie now, such as:

recommendations

If a system is required to be deployed by the end of January, I recommend implementing the simpliest system: an additional "machineoruser" flavor for Pubcookie using a persistant long-term cookie identifying machines.

what this means for location owners

They will have to visit every location machine at least every X days, where X is set centrally. X should vary with the value of the licensed information that the libraries plan to make available in this fashion. Four months is a reasonable time.

trade-offs and vulnerabilities

implementation notes