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:

User visits a Shibbolized protected site protected.com.
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.
The user selects "Carnegie Mellon" from some interface on the WAYF.
The user is redirected to CMU's local Shibboleth handle server, shibboleth.web.cmu.edu.
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.
Lacking a single sign on cookie, Pubcookie presents the user with a login dialog box. (a)
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.
CMU's Shibboleth server sees the authentication assertion and sets another cookie scoped only to it identifying the user for further Shibbolized interactions.
CMU's Shibboleth server then redirects the user back to protected.com with an opaque handle.
protected.com can then make use of this opaque handle to query CMU's attribute authority, aa.cmu.edu, for information on the user.
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.
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:

NATs and other network proxies can obscure the true IP address.
It creates a difficulty when re-IPing a set of machines, which may be necessary for network maintenence.
It can led to difficult to diagnose problems when new machines are added or old machines upgraded.
Intruders with physical access can trivially spoof IP addresses. This is especially important if some of the machines will be use via wireless connections.
Intruders even without physical access can make various IP address spoofing attacks.

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:

Easy to program. No client side software is needed, no external lists need to be maintained by hand.
Reasonably easy to maintain. Administrators can receive such a cookie after logging on to Pubcookie using their username and password.

Downsides:

The cookie is vulnerable to theft via multiple methods. It is probably impossible to keep the cookie from retrieval from a user who access to the web browser.
The cookie will need to be set for each web browser on the machine.
Periodic rekeying is needed, creating a burden for the local administrators.
Accurate logging and analysis may determine when the cookie has been stolen. Either a seperate key must be kept for each kiosk machine (so that key may be deleted when the cookie is compromised) or a blacklist of known stolen cookies must be maintained.
The cookie may be deleted by malicious local users.

Technical details:

the cookie must contain a hostname (at least 256 characters); a version number (4 bytes is easiest); and a expiration time (4 byte time_t). a 4 byte random number leading confounder would be advisable.
the login server needs a new CGI (or equivalent) to issue these cookies, which should be secured with libpbc_mk_safe(). This CGI needs to enforce policy of what users are allowed to request cookies for machines, or at least log the username that retrieves a cookie for their current computer.

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:

If the local security is viewed sufficient, it doesn't require periodic visits from the local administrator.
The easy-to-steal cookie in the browser is good only for X minutes.
The security offered by this solution shouldn't be significantly different from the security offered by Kerberos on cluster machines.

Downsides:

Significant resources must be devoted to the client software that will rotate cookies. Inserting new cookies into the browsers' caches must be understood and kept up to date.
Blacklists or key databases still must be maintained by the login server to deal with compromised local machines.

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:

This would effectively make it very difficult to use a kiosk terminal to utilize a Shibboleth service that requires attributes that can't be derived from FQDN. Since Shibboleth cannot cause the user to reinteract with Pubcookie when a request comes into the attribute authority, if a request comes in that requires more information about the user it must be denied.
If the user uses a different (local) Pubcookie service, they would be presented with the standard username/password prompts and could log out as normal, by closing the browser (if possible).
The easiest way for "machineoruser" to identify the machine name is via a long-term cookie.

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:

the ability to request any existing authentication assertions but never prompt the user for credentials

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

A flat text file can be used to indicate the last version of the long-term cookie. (Thus revocation is as easy as bumping the version number, since no older versions will be accepted.)
The file should also record the last person to set the long-term cookie, the time it was done, and it's set expiration time.
The maximum lifetime of the location cookie should be centrally configurable.
The system should log what IP addresses are claimed to be belonging to various machines; possibly automated auditing should check to see that a single machine doesn't suddenly transport its location.