KrbWeb Outline of Work

Towards Kerberizing Web Identity and Services

Abstract

Today, authentication and authorization are addressed in an incoherent, often site-specific fashion on the Internet overall and the Web specifically. This situation stems from many factors including the evolution, design, implementation, and deployment history of HTTP and HTTP-based systems in particular, and Internet protocols in general. Kerberos is a widely-implemented and widely-deployed authentication substrate with a long history in various communities and vendor products. Here we outline the history of "Web identity", "Web Single Sign-On", "Web Services" and "Web Services Stacks", and present how Kerberos fits into this picture today. Relevant "user stories" are then presented, as well as technological use cases along with a taxonomy of extant Web-relevant security technologies. From this we present an overall general architecture model and suggested activities for working towards more cohesive and widely deployed Kerberos-based Web authentication infrastructure.

Authors (alphabetical)

Jeff Hodges, Kings Mountain Systems

Josh Howlett, JANET

Leif Johansson, Stockholm University

RL "Bob" Morgan, Internet2 / University of Washington

Introduction

In this paper we attempt to provide a high-level overview of how authentication of end users, and to some extent their authorization, fits into the Web landscape -- and Kerberos' place in that picture along with its strengths and gaps. We follow with a brief presentation of "user stories" -- simple statements of what end users, deployers, and enterprises desire in terms of their security-related experiences when using the Web. Next, we discuss technological use cases, specific web-relevant security technologies, and some overall requirements such technologies should meet. Then we touch briefly on implementation and deployment technologies -- e.g. browsers and application development libraries, before closing the paper with a presentation of an architectural model, suggested activities, recommendations, and analysis.

Acknowledgments

The authors are grateful for the support of the MIT Kerberos Consortium. We acknowledge and thank Love Hörnquist Åstrand, Steve Buckley, Michael Gettes, Ken Raeburn, Tom Yu, and Larry Zhu for their input and comments.

Related Pages

"Backlog" Page

Steve's "slides and notes from the Consortium Board meeting" from 24-Jul-2008

Overview

A Short History of Web Identity

For a system that was originally intended to facilitate collaboration between physicists, it is remarkable how ubiquitous Web technologies have become. It is no exaggeration to claim that the HTTP protocol defined in RFC 2616 is the de facto transport for applications operating between internetworked hosts. This is due, in part, to HTTP's success in meeting its authors' goal of defining a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext transfer', but perhaps mainly to the convenience of using a common transport in an Internet composed of networks with diverse capabilities and policies.

The Primordial Identity Soup

HTTP's standard authentication capabilities, Basic and Digest, are specified in RFC 2617. The most obvious deficiencies of these protocols, such as capture of credentials on-the-wire, were widely appreciated at the time, and the response was to remedy them using SSL (and subsequently TLS). However, the user experience provided by browsers implementing these methods was deemed by many as "poor" (for example, the bland username and password dialog) and also was effectively "unbrandable". So while these methods were deployed within the Enterprise (typically to protect Intranets and programmatic web services), they were largely ignored by the broader Web development community, where so-called Form-based authentication became dominant.

Unlike Basic and Digest authentication, which are typically implemented in the web server -- at a system level -- Form-based authentication is typically implemented at the web application level. The application uses XHTML elements to construct a Form, typically consisting of username and password fields (and increasingly also a captcha dialog). The user enters his credentials into the Form, which is submitted to the application using the HTTP POST method.

The paradigm of using TLS-protected Forms for user authentication and X.509-based server authentication became extremely common, and it remains the most common approach to authentication and establishing trust. However, this paradigm is not without drawbacks. The most significant problems include:

• Phishing of credentials
• Excessive numbers of credentials
• Inconsistent and complex user experience
• Privacy violations
• Ad-hoc and unstandardized
• not a system-level approach

These drawbacks can be viewed as symptoms of this paradigm's failure to scale with the explosive growth of the Web. This confounded early attempts to improve HTTP authentication (for example, attempts to leverage SASL (RFC 4422)) which might have permitted the use of a Kerberos mechanism) because the Web had not yet attained the scale and significance where the symptoms had developed to the chronic level that we observe today, and so consequently there was no obvious case for significant alterations to protocols or implementations.

Birth of Web Single Sign-On and Identity

The need for some notion of "Web single sign-on" -- termed "Web SSO" -- was perceived by various disparate parties from the mid-1990s onwards. Often this occurred in a commercial, higher educational, or governmental enterprise setting. Many roughly similar solutions were concocted roughly in parallel, and the practice continues right to the present day. Some examples are the WebAuth system concocted and deployed at Stanford University (mid-to-late 1990s), PubCookie from University of Washington, and Yale's Central Authentication System (CAS).

The first OS-vendor-driven effort to improve Web authentication, and provide users a cohesive notion of web-based "identity" as well as Web SSO, was Microsoft's Passport service. However, Passport failed to gain any lasting traction, beyond Microsoft's own services, for reasons of trust. Technically, Microsoft's initial Passport SSO protocol was flawed, reducing confidence in this aspect of the system. More critically, Passport was perceived by potential consumers of the system - and others - as a vehicle that could hand Microsoft a monopoly in Internet identity. Passport's importance began to diminish in 2004 when Microsoft canceled the contracts with the most significant consumers of Passport, including eBay and Monster.com.

In parallel with Passport, a Technical Committee (TC) within OASIS -- the Security Services TC (SSTC) -- was established to define SAML, an open XML-based identity system derived from two earlier specifications, S2ML and AuthXML. SAML was the first, and is the most successful, technology for federated identity. The SAML specifications were quickly leveraged by the Liberty Alliance, a broad vendor and "deploying organizations" consortium initially reacting to the perceived threat from Passport, for their own ID-FF (Identity Federation Framework) specifications.

In contrast to Passport, which was conceived as a wholly centralized identity system, federated identity is an approach in which a website (normally called the Service Provider, or SP) delegates responsibility for user authentication (and sometimes user authorization) to a trusted third party (normally called an Identity Provider, or IdP) with which the user is affiliated. The relationship between one or more IdP(s) and one or more SP(s) that have federated is often called a "federation" (the Liberty Alliance refers to this as a Circle of Trust).

Evolution Towards Federated Identity

However, Federated Identity does not replace Form-based authentication, nor was it ever intended to. Federated identity is independent of the authentication technique used by the IdP (although the authentication method may sometimes be a property of the authentication event about which the IdP informs the SP). Federated Identity can, however, be used to move the deployment of Form-based authentication from the SP to the IdP, alleviating the SP of the burden of authenticating user credentials and implementing the processes require to issue and manage those. It also means that, in general, a user only needs to maintain a single identity per federation.

SAML, and the Liberty Alliance specifications in particular, are perceived to focus primarily on finding solutions for Enterprise and eCommerce use-cases. In the case of the Liberty Alliance framework, the federated identity technology is complemented by non-technological deliverables, such as federation governance models, security best practices, and deployment guidelines. While comprehensive, some within the Web development community viewed this approach to federated identity as unnecessarily complex for various use cases - and not scaleable to the Internet community at large (though these contentions are debatable). More philosophically, there was also opposition to what many (largely incorrectly) perceived as SAML's leanings towards "Enterprise-centric" identity, in which the user's identity is associated with some corporate entity issuing assertions on the user's behalf, than it is with the natural person represented by that identity.

The OpenID protocol, and the "user-centric" movement that espouses it, is the clearest manifestation of this.

Many argue that the claimed "user-centric" properties of OpenID are a distraction, and that SAML can be profiled equivalently such that it is no less "user-centric". While accurate, OpenID implementations, being optimized for abject simplicity, can be easier to deploy than some SAML implementations. For example, OpenID is not burdened by any notions of trust, whose subtleties add significantly to the SAML specification, and thus implementation and deployment complexity of SAML profiles reflecting and accommodating trust nuances.

Relieved of these burdens, OpenID has seen significant deployments - but, almost invariably, only for applications where the consumer of the OpenID identity does not require a significant level of trust in the assertion (which, owing to the way in which the protocol operates, is equivalent to the level of trust that can be attributed to the DNS). Therefore, while OpenID is satisfactory for low-value applications it is perceived by many as typically not appropriate for higher-value applications.

From Identity Monopoly to Identity Metasystem

The recognition of the diversity of identity technologies, and the requirements of the applications consuming the identities, is a key feature of Kim Cameron's widely referenced Laws of Identity in which he proposes the need for (or perhaps the inevitable reality of) the Identity Metasystem. Cameron was a vocal critic of Microsoft Passport and was subsequently recruited by Microsoft as its Chief Identity Architect. In the Laws of Identity, Cameron proposes seven axiomatic properties of identity systems that, he claims, must be observed for any identity system to succeed. While the Laws of Identity have been subject to criticism, it is a nonetheless important document in that it expounds the philosophical underpinnings of the identity architecture being developed by Microsoft in the wake of Passport.

Emergence of Web Services

The notion of "Web Services" emerged in the late 1990s, becoming widely visible with IBM and Microsoft et al's submission of the Simple Object Access Protocol (SOAP) 1.1 specification to the W3C (as a "W3C Note") in the spring of 2000. SOAP consists of highly tailorable XML-encoded protocol messages capable of encapsulating arbitrary data. They can be employed in either remote procedure call (RPC) or message passing styles.

"Web Services" were felt by these practitioners to essentially exclusively consist of SOAP messages conveyed by HTTP, effectively excluding other extant protocols with well-defined URI schemes, e.g. FTP, LDAP, IMAP, etc., from the "web services party".

A year later, IBM-Microsoft produced the Web Services Description Language (WSDL) 1.1 W3C note in Spring 2001. It essentially defines an "interface description language" for SOAP-based protocols, which is purportedly an aid to developers.

Security in the SOAP context -- authentication, confidentiality, and integrity protection -- was originally left as an afterthought, i.e. as an exercise for developers and deployers. Two years after SOAP's initial emergence, the WS-Security specification was publicly announced by IBM and Microsoft in Spring 2002. It specifies a framework for attaching essentially any type and/or number of "security tokens" (such as a Kerberos ticket) to SOAP messages, as well as cryptographically binding tokens to messages. This provides a means for data origin authentication on a per-message basis. This can be built upon to provide high-level security abstractions, e.g. for streams of messages.

By then, 2002, it was clear that there was no industry-wide cohesive vision of what constituted "web services", other than a nominal agreement of them being SOAP-based, nor was there a single "home" for web services specification development. The lack of a home was, and still is, illustrated by the work on various aspects of the broad web services notion being spread across a plethora of fora: privately (e.g. the IBM-Microsoft "workshop process"), in the W3C, in the Web Services Interoperability (WS-I) organization, in OASIS, and in the Liberty Alliance Project.

Web Services Stacks and Identity

Given the fragmentation of the broader web services community noted above, it is not surprising that more than one "web services stack" has emerged. By "stack" we mean a full-featured specification suite addressing messaging and transport binding, interface description language, security framework, resource discovery, authentication and security token services, and web single sign-on.

The two major extant SOAP-based web services stacks are the Liberty Alliance's Identity Web Services Framework (ID-WSF) and IBM-Microsoft-Et-Al's WS-* (dubya-ess star). Both meet the definition of "stack" given above. Both utilize SOAP-based messages and employ WS-Security as well as WSDL. However, they diverge as one goes further "up the stack". Yet, both stacks feature the key notion of federated identity being conveyed between the browser-accessible web-based "world" and back-end "web services"-based systems.

ID-WSF specifies use of SAMLv2-based security tokens (though other token types may be profiled for use) and leverages SAMLv2's Web Browser SSO Profile for web single sign-on. The authentication service leverages a SASL-based authentication exchange thus supporting the plethora of extant SASL mechanisms, e.g. Kerberos. ID-WSF is designed with the notion of a user's identity being a first-order component of the context of interactions. For example, discovery service requests are implicitly made in the context of the identity of the user causing the request to be made, e.g. "I am asking for my service locations", as well as being able to express target identity contexts, e.g. "I am asking for her calendar service". While ID-WSF's specifications explicitly allow for extensions and profiling, where these are possible are carefully constrained. ID-WSF was designed to be concretely implementable and deployable directly from the original specification suite with no further profiling required.

The composition of the WS-* stack is somewhat difficult to pin down in that IBM and Microsoft each have their own perspective on what constitutes the WS-* stack, and also because the specifications are strewn across a landscape including their private "workshop process", as well as OASIS, W3C, and WS-I. The WS-* specifications are designed to be freely "composable" -- one can pick and choose which ones to utilize in solving a particular use case. This is often cited as the rationale for the specifications' style of unconstrained XML element extensibility (in contrast to ID-WSF's constrained approach). In order to concretely implement WS-* to solve some given use case(s), one must leverage the WS-I "profile" specifications in concert with the WS-* protocol specifications. The notion of identity attained in the system will depend upon the selection of which aspects of WS-* are implemented as well as the profiling choices made.

Kerberizing Web Identity & Services

The use of Kerberos as an authentication mechanism for web applications has a long history in certain communities, notably Higher Education and Research as well as large-scale Enterprises. Extending Kerberos to address web authentication in these communities was typically driven by a desire to reuse technology which was well understood and widely deployed. This motivation has become even more pronounced with the wide deployment of Active Directory. There is, therefore, a significant body of experience relating to the use of Kerberos for the Web and related technologies (Web services, XML, identity federations, and so forth) which can be used to formulate a strategy for future work in this field.

This document tries to describe a number of missing pieces of the puzzle which when combined can help the Kerberos Consortium release the full potential of Kerberos as an authentication technology for the web.

Credentials Delegation

An important feature of Kerberos is the ability to forward tickets -- i.e the ability to delegate credentials to remote services where they can be used by that service to act on behalf of the user. When the services are simple traditional host-based services (e.g. ssh or telnet) the credentials-delegation picture is relatively uncomplicated: it just works. This picture changes dramatically with the advent of web-based applications needing access to user credentials in order to authenticate to kerberized backend services. This is sometimes referred to as "n-tier". The classical example is the web frontend to a kerberiezd IMAP server. As long as the authentication mechanism for the web application is basic access authentication or form-based authentication, i.e it has access to the user password, the web application can obtain a TGT -- but at the cost of compromising the secrecy of the user's Kerberos password.

Enterprise Web SSO and Credentials Delegation

Identity management in large-scale deployments of web applications has resulted in the deployment of governance solutions for web single sign-on (Web SSO). Open source products like Shibboleth, WebAuth, CAS, and PubCookie, as well as commercial products like Passlogix, ActivIdentity, Avencis SSOX, are often deployed as central points of authentication for multiple web applications in the enterprise. These systems are often seen as meeting several different requirements involving compliance (e.g. Sarbanes-Oxley (S-OX)) and auditing. However, the enterprise SSO makes Kerberos credentials delegation quite difficult. Some products (e.g. PubCookie) have the ability to forward TGTs from the point of authentication to the web application but these are exceptions rather than the rule.

Combining enterprise SSO with kerberized backend services is often quite difficult if one wants to hang on to the "end-to-end principle" -- which in this context means to maintain a cryptographic connection between the ticket sent to the backend service and the end user credential used to originally authenticate with the IdP in the single sign-on environment. The success of Active Directory led to the introduction (by Microsoft) of a new way to do credentials delegation: s4u2self (aka "constrained delegation"). In this model -- as opposed to the end-to-end end model -- the KDC delegates the right to a "service" principal to impersonate a user to a set of services. In our webmail example the service principal would be associated with the web application itself and the KDC would delegate to it the right to obtain IMAP service tickets for any user. The idea is that the web frontend is trusted to properly authenticate the user, by whatever means, allowing the KDC to delegate part of its responsibility to this service principal. This idea is sometimes called "air gap" security and while not as strong as end-to-end n-tier authentication it is nevertheless often good enough for many applications.

User Driven Credentials Delegation

The advent of "Web 2.0" web applications, notably social networking sites like Facebook, Linked-In and large scale software-as-a-service (SaaS) providers like Hotmail and gmail led to the creation of yet another type of credentials delegation paradigm: user driven credentials delegation whereby a user is asked to provide authorization for each time a service needs to be able to access another service with the rights of that user. The typical example is Facebook wanting access to the users Hotmail address book in order to setup relationships with "buddies" on Facebook. The OAuth protocol (cf below) has built-in support for this type of case-by-case credentials delegation. Although the Kerberos V5 specification, RFC 4120, has allowances for implementations to craft such "user driven" behavior, such behavior is not typically implemented and/or materialized to users.

However, credentials delegation in Kerberos still remains one of its truly unique properties -- no other widely deployed security protocol has the ability to pass credentials between members of a multi-tiered architecture.

Efficiency Concerns

With Active Directory came the notion of the PAC - a data structure included in an extension to the ticket which includes what amounts to authorization data associated with the session. We will return to this notion below when discussing Level of Assurance (LoA) transport and SAML profiles for Kerberos. However it is worth noting that the inclusion of authorization information in the Kerberos protocol has adverse side-effects. When Kerberos is used as an HTTP authentication mechanism (cf Negotiate below) as opposed to being hidden behind an SSO abstraction layer such as the SAML Web Browser SSO Profile or a commercial Web SSO such as any of the products listed above - any extension to the ticket that adds significantly to the payload of the HTTP handshake may be noticeable by users in terms of overall system response time.

Experiences with Active Directory in large-scale deployments (with many groups) shows that the PAC can often grow to ~20k which has a performance impact on HTTP especially when the browser needs to open and process several connections in order to render a single "page" to the user. Modern browsers are optimized for keeping multiple HTTP connections open in parallel and it is not uncommon for single user views ("pages") to result in 100s of connections to the server. In order to address this problem any protocol and/or authentication mechanism employing Kerberos will need a form of session identifier or other way of efficiently re-using the fact of initial authentication for multiple subsequent connections -- for example the "session resumption" feature of TLS (RFC 4346).

Summary

The Web authentication landscape is therefore highly complex and diverse, both in terms of technology and politics. The contrast with the Enterprise space, where Kerberos is virtually ubiquitous, could hardly be starker. The goal of this document is to explore how Kerberos might be used as a bridge over the "authentication gap" that separates these worlds.

The document uses the following methodology :

• First, a set of user stories are presented. A user story describes a particular outcome that a user wants.
• Secondly, a set of use-cases are developed that bind the user stories into scenarios that can be generalized to address other similar problems.
• Thirdly, there is a discussion of all existing technologies that might contribute.
• Finally, a number of activities are proposed that are intended to supplement or extend these technologies in order to realize the use-cases.

User Stories

A user story is a statement describing a specific desire by a specific type of user in order to achieve a specific value. User stories often appear in agile development frameworks (e.g. SCRUM) and are used as a tool for evaluating the effectiveness of development activities. A user story often takes the form of a single sentence of the form "A wants to do B in order to achieve C".

We have chosen to describe requirements as user-stories in an attempt to make the requirements easier to evaluate from the point of view of various stake-holders.

Notes

The term "web-based" is used to denote both "Internet-based" sites/services (connotes likelihood of "third-party"-ness in the overall interactions involved (e.g. ISPs, hosting providers, site/service-providing entity (e.g. bank, store, etc) may figure in the packets' path between user and the site/service process(es), and "enterprise-based" (aka "intranet-based") sites/services (connotes possibility of a range from "single-party"-ness to high "third-party"-ness, depending upon the characteristics of the "enterprise".

The term "site/services" is simply used at this time to consciously acknowledge the range of web-based possibilities from simple static web pages, to wikis, to fancy full-featured sites offering a range of "services", e.g. Google, Yahoo, AOL, etc.

A "site/service-providing entity" is also referred to as a "service provider (SP)".

General: Users

Simplicity

US1: Users want to reduce the number of sign-on technologies 
and credentials that they are required to use to access web-based 
sites/services.

Transparency

UT1: Users want to reduce the number of authentication steps taken 
when using online services.

UT2: Users want to use mobile devices when authenticating to online 
services.

Flexibility

UF1: People want to assert different identity information in different 
contexts, e.g. to be able to "don" different roles when interacting with 
either the same or different site(s)/service(s). E.g. to be able to 
interact with a given bank in the role of either an individual consumer, 
or an officer of a company which is also the same bank's customer. 

UF2: Users want to use untrusted devices (e.g.. an airport Internet kiosk, 
a borrowed device) to access sites/services without compromising their 
credentials. 

General: Service Providers

S1: Service providers that consume identities from third-party identity 
providers want to reduce and/or minimize the number of sign-on 
technologies that they are required to support.This applies to both 
Internet-based and enterprise-based SPs. 

S2: Service providers want to be able to manage and minimize the risks 
they assume when providing authenticated web-based sites/services. 

Financial Services

FS1: Web-based financial services want to avoid phishing, and have their 
experience adhere to the "General: Service Providers" user-stories noted 
above. 

FS2: Customers of web-based financial services want to avoid phishing.

FS3: Customers of web-based financial services want their experience of 
using the site/services to adhere to the "General: Users" user-stories 
noted above.

Note: essentially all web-based sites/services (and their users) are subject to phishing attacks. It would seem that the main reason to single out Financial Services SPs is that the attack results with them can be particularly devastating.

Federation

F1: Deployers of web-based portal services with kerberized backend-services 
need to be able to use federated identity with N-tier authentication.

F2: Grid services (in environments where PK-INIT is used) in the US Federal 
sector need to fulfill policy requirements that authentication be done 
using smartcards.

F3: SAML service provider with a large number of affiliated Identity 
Providers requires a way to determine which Identity Provider a user is 
affiliated with, so that it knows where to request assertions for the user'. 

F4: The IT management at two or more federated partners need to define 
conventions, or an agreement, governing the use of a federated business 
process that is secured using Kerberos.

Enterprise

E1: Enterprise SOA architects want flexible life-cycle management for 
identities used for SOA.

E2: Enterprise security officers want secure authentication for SOA.

E3: Enterprise system integrators want interoperability between 
web service implementations from major vendors.

E4: Enterprise identity architects want SSO-support in popular browsers 
with credential delegation capabilities turned on by default.

E5: Enterprise identity architects want to be able to extend existing 
cookie-based SSO systems with support for Kerberos backchannel 
authentication and credentials delegation.

Use Cases

TODO: complete mapping user-stories to use-cases (user story given as (N))

The use-cases are divided between three categories

• Back Channel - this describes transactions between service providers occur directly, without relying on user-wielded tools (typically, although not exclusively, a web browser) to act as an intermediary. E.g. an ecommerce site interacting directly with a user's banking site, without re-directing communications through the user's web browser. These transactions may either be invoked in response to an action performed by a user (for example, logging into a service provider) or be initiated automatically by software agents.
• Front Channel - this describes interactions between service providers occurring indirectly via a user-wielded tool -- typically, although not exclusively, a web browser -- to mediate. These transactions are normally invoked in response to an action performed by a user (for example, logging into a service provider).
• Front and Back Channel combined - this describes interactions that involve elements of Front and Back Channel activity (for example, a Back Channel transaction that is authorized using a token that was established previously in an earlier authentication event while the user was online).

Back channel

Intra Enterprise

A large organization is deploying an increasing number of web services. Initial deployments, which were typically few in number, relied on the use of shared secrets for authentication and TLS for transport security. Although the web services are mainly SOAP-based, using HTTP for transport, the use of Negotiate or message-layer security is very uncommon.

As the deployments of web services expands, the management of the shared secrets becomes an issue (E2). There is also increasing concern that certain properties of shared secret authentication, or the practices used to manage them, while acceptable during the initial deployments on low-value applications (such as hard-coding secrets into applications), are not appropriate for higher-value applications. The most common action taken is to move to the use of client certificates which, for an organization of this size and complexity, necessitates the acquisition of a web services governance solution. Such products are often based on an ESB (Enterprise Service Bus) and sometimes employ other transports besides HTTP (for example, various message-oriented protocols such as MQ or XMPP).

The motivation for using Kerberos with these web services is to simplify the management of their security requirements (E1). However, the web services are perceived as distinct from the existing business infrastructure, and so consequently these services are often treated as a single administrative domain isolated from everything except those business systems which they connect. Therefore, the security properties of Kerberos are unlikely to be an important criterion in any evaluation against alternative mechanisms. It also means that Kerberos administration, in order to be a viable option, must integrate into the various web service governance solutions that exist.

Business-to-Business

A business needs to integrate with another business using a SOAP-based web service (E3). One or both of these businesses may already be in possession of an existing enterprise-wide SOAP-deployment similar to the one described in the previous use-case. The requirements of the security model are typically fairly simple (for example, there are no n-tier issues). As before, shared secrets are used authenticate endpoints, using either TLS or IPSec for transport security. The use of any transport for SOAP other than HTTP is very uncommon.

The motivation for the use of Kerberos in this use-case may be to leverage each business' pre-existing Kerberos infrastructure, and possibly an existing cross-realm trust, in order to avoid establishing a special-purpose trust infrastructure (E2).

The main difference between this use-case and the one that was described previously is that typically only a small number of web services are required for each pair of Business-to-Business relationships. Therefore, establishing and managing cross-realm trust must be perceived as a low barrier to the adoption of this trust-model.

Front channel

Business-to-employee and Business-to-customer use-cases typically involve front-channel exchanges through the user's (customer or employee) browser. Most technologies involved in front-channel authentication (for example, SAML Web SSO) currently use Form-based username and password authentication, even if other mechanisms are supported.

The motivation to use Kerberos might be to provide a better user-experience. Information Card in combination with Kerberos could also be used to provide a consistent and simplified user experience for web-based authentication. The same is true (to a lesser extent) for Negotiate-based authentication.

Business-to-employee

In this use-case, the business issues credentials to the employee (E1). These could be used to provide access to both internal corporate resources, and resources offered by third-parties (such as SaaS providers).

Business-to-customer

In the case where the business issued credentials to customers, the primary challenge would be identity provisioning and management: a user would typically need to obtain and negotiate the use of credentials from multiple realms, obviating the single sign-on benefits of Kerberos.

This could be mitigated through either the use of Kerberos cross-realm operation, or identity federation technologies (for example, the SAML Web SSO Profile) where Kerberos could be used to authenticate the user at an Identity Provider trusted by those businesses that the customer interacts with. If this were intended to solve the general problem (that is, for most users, for most service providers), there are a number of challenges; these include Identity Provider Discovery (how does a business determine which Identity Provider a customer is affiliated with, assuming a model involving multiple Identity Providers), technical trust model and governance.

Front and Back Channel Composition

Credentials Delegation

A recently merged company wishes to provide the newly-united workforces with a single web portal providing access to various back-end services that, owing to delays in the re-organization of the respective IT functions, will remain administratively separate for some time. The provision of email is a core function of the web portal, which therefore needs to access a set of IMAP servers in these separate administrative domains. To avoid the need to issue new credentials to users, SAML-based Web SSO is used to provide federated authentication by the SAML Identity Providers operated by each IT function. These Identity Providers trusted could provide the web portal with delegate-able credentials for their own IMAP server(s) (E5).

Level-of-Assurance transport

Many services have policies attached to their use that stipulate which type(s) of credentials are acceptable (often called the level of assurance) (E2). In scenarios where the service itself is authenticating the user's credentials, the policy is normally trivial to enforce using technical means because the service has visibility of the authentication event.

However in a distributed environment the authentication of user credentials is often performed by a third party, out of the control of the service. There are several examples from within the US federal sector where services may require the use of smartcard technology and where there is also a desire to provide a federated web front-end (normally to extend access to users affiliated with trusted organizations).

However, there is currently no way to communicate information about the authentication event (except in a few corner cases involving PK-INIT). Although SAML defines n element that enables an Identity Provider to express an Authentication Context, it is unspecified how this should be used in a Kerberos deployment.

Security Technologies

The security technologies relevant to the HTTP-based Web can be divided into three overall categories:

• Transport security is provided by the underlying transport protocol. The security service only acts at the socket or datagram layers between two hosts, and bindings to high-level security measures tend to be non-existent. Credentials are usually issued to hosts (if datagram-based) or services (if socket-based).
• Application security is provided by the application protocol in combination with, or independent of, substrate transport security. Credentials are usually allocated to an application, and the users accessing those applications. Applications may, in some circumstances, leverage user credentials to act on a user's behalf. This is referred to as "impersonation" and/or "delegation" depending upon the detailed context.
• Message security describes an approach where (application) protocol messages are individually cryptographically bound to security tokens they convey directly and/or indirectly (by reference). With such an approach, the protocol messages may be conveyed over different transports (e.g. HTTP, SMTP, TCP, etc), or stored on intermediate or endpoint systems, while retaining intact their originating security context (modulo any allowances for message modification in-transit).

Transport security

HTTP is the common transport in web-orientated architectures. Transport security is usually provided using TLS and X.509 PKI.

Kerberos-based alternatives (existing and proposed) include:

• Kerberos with IPSec.

• Negotiate.

• A specification describing a Kerberos-based cipher suite for TLS exists (RFC2712), and has seen at least two implementations (OpenSSL, JGSS), but is widely regarded as flawed.

• A recently-expired draft describes extensions to RFC4279 to enable dynamic key sharing in distributed environments using a GSS mechanism, and then import that shared key as the "Pre-Shared Key" to complete the TLS handshake. The TLS Working Group has argued that user principal authentication is an application-level concern, and so this work appears to have stalled.

Other transports, such as XMPP, are available. However it is likely that architectures requiring the use of two or more transports would emphasize the use of message-based security, because the transports' respective security properties are not necessarily functionally equivalent. Where multiple web services are deployed from the same application server it is common to use a web service governance solution which abstracts the service business logic from the transports.

In summary, HTTP is almost always used - but sometimes other transports are also used. In this case the logical way to provide security is to use message-based security.

Application security

Negotiate

"Negotiate" is the collective name of a loosely defined set of HTTP authentication mechanisms that provide a simple 2-way GSS-API handshake with the HTTP server. The most commonly deployed variant, "Simple And Protected Negotiate (SPNEGO)", defined in RFC 4559, uses the SPNEGO GSS-API mechanism, itself defined in RFC 4178. Other implementations use the Kerberos5 GSS-API mechanism (RFC 4121) instead. Updates to RFC 4559 have been discussed.

It is worth noting that Negotiate authentication does not protect the HTTP request, because they are sent unprotected during the GSS-API handshake (which is itself encoded within an HTTP header). This authentication method is therefore not advised in some use-cases; in particular, REST-style web-services cannot in general be protected using Negotiate alone. Note that this is the case with all present authentication techniques that are conveyed within an HTTP message itself, e.g. in the HTTP message headers: Basic, Digest, and Negotiate.

Negotiate suffers from a lack of mutual authentication and support for multiple-roundtrip GSS-API mechanisms. Earlier attempts (in the IETF) of introducing SASL-based authentication for HTTP showed that in order to gain wide acceptance any multiple-roundtrip HTTP authentication mechanism has to be able to deal with consecutive HTTP/1.1 connections being sent to different TCP endpoints (e.g. if a concentrator is deployed at the server). This implies that the authentication mechanism needs to support some form of state management. At least two different proposals have been put forward for solving this problem; one in http://tools.ietf.org/html/draft-johansson-http-gss where state management is done in the HTTP layer and one in http://tools.ietf.org/html/draft-zhu-negoex where state management is done in the GSS-API layer.

Information Card

Introduction 

"Information Card" is an identity technology based on the notion of a smart client, the identity selector (IS), under the control of a user, that can interact with a relying party(RP), and optionally an identity provider (IdP), to accomplish application signon and delivery of user information to the RP. Both IS-RP and IS-IdP interactions use the WS-Trust protocol (part of the WS-* suite). WS-Trust is intended to be a "meta" authentication protocol that can in theory permit a security token to be delivered to the RP in whatever format it requires, independent of the method the client uses to authenticate to the IdP. The identity selector has a user interface that presents the user's authentication options in the form of cards. A card can be "managed", meaning that it is issued by an IdP, and requires authentication to that IdP when used. Or, a card can be "self-issued", meaning it is generated within the identity selector, and uses a keypair managed by the selector to authenticate to the RP.

Though Microsoft is the initial developer and evangelist of Information Card, many other companies and projects are developing compatible software and contributing to the technology specifications. The Information Card Foundation (http://www.informationcard.net/) was formed in 2008 to promote the technology. Microsoft's Information Card client (known generically as an "identity selector" or "identity agent") is called CardSpace. Since it is the most well-known implementation, many people (incorrectly) refer to the whole technology as CardSpace. The Information Card concept was originally developed by Kim Cameron of Microsoft as part of an "Identity Metasystem" concept, so this term is also used for this technology. The technology is now being standardized in an OASIS technical committee called the Identity Metasystem Interoperability TC (http://www.oasis-open.org/committees/imi/).

The Information Card specifications define the authentication methods supported between identity selectors and IdPs (in the managed card case). Kerberos is one of these methods. The others are: X.509 cert, username/password, and self-issued card (technically a SAML token).

Kerberos authentication from Identity Selector to IdP 

The Identity Selector (IS; an end-user client-side tool) can authenticate to an IdP using Kerberos. The WS-Security Kerberos Token Profile is used, underlying the WS-Trust protocol that does the security token request. An IdP supporting Kerberos authentication would be an application server from the Kerberos point of view. It doesn't appear that any of the existing Information Card IdP software supports Kerberos authentication however, so this is an opportunity for improvement. Microsoft's IdP (which probably won't be available until 2009) will support all four defined methods, including Kerberos.

Kerberos token delivery to the RP 

WS-Trust operates by delivering security tokens to RPs to authenticate clients. WS-Trust is (or claims to be) token agnostic, meaning it can carry anything, but for a token format to be used interoperably its nature and handling by IdP and RP must be specified. Information Card defines the use of SAML tokens for self-issued cards and these have commonly been used as tokens in managed cards also. It would be possible to define a Kerberos token. Such a token (presumably a KRB_AP_REQ) would be generated by the IdP, carried by WS-Trust from IdP to IS and from IS to RP, and processed by Kerberos software at the RP. There is no such token defined at this time. Recent comments from Microsoft about supporting cross-technology delegation imply that it might be implementing delivery of Kerberos tokens via WS-Trust.

Identity Selector as standard authentication UI 

Information Card technology has been introduced as an approach for browser authentication to web applications, since the web is obviously widely-used and urgently in need of better authentication solutions. The selector concept, however, can apply to any instance of user authentication. This might involve extending selectors to support other protocols, or adding the use of WS-Trust for authentication to existing systems. In particular the Identity Selector could be a user interface for Kerberos initial authentication in some scenarios.

OAuth

Introduction 

OAuth (http://oauth.net/) is a specification for interoperable support of delegated access to web-based resources. It is designed to support a particular common use case: a user of one web-based service (for example, a photo-sharing service, called the OAuth service provider) has protected resources (for example, photos) that the user would like to make accessible via another web-based service (for example, a social-networking service, called the OAuth consumer). This is often done today by the consumer service obtaining from the user their username and password on the service provider. The goal of OAuth is to avoid this practice. This done by defining service points to permit an access token to be produced by the service provider and delivered to the consumer via the browser. This token can then be used (after some transformation) to access the service provider via an OAuth-defined HTTP authentication method.

OAuth was developed by an adhoc group, based on similar specs from a number of web technology companies (e.g. Google, Yahoo!). Its current version is 1.0. There are several implementations for different languages and platforms, and some initial deployments. Google in particular defines extensive support (http://code.google.com/apis/accounts/docs/OAuth.html).

OAuth has no defined relationship to Kerberos or any other existing authentication technology at this time. Note that since the tokens are both issued and consumed by the service provider, their internal format and semantics can be whatever the service provider wants. For example, the validity period of the token is not defined in the spec or represented in the protocol; it is entirely up to the issuer.

The standard OAuth scenario is referred to as "three-legged" since it involves the consumer, the provider, and the user who must indicate consent and transport the access token. There is interest in "two-legged" scenarios where the OAuth HTTP authentication method is used simply between consumer and provider, not on behalf of some user. In this case it would be an alternative to other HTTP authentication methods such as Basic or X.509/SSL.

Opportunities 

There has been recent discussion about profiling OAuth with SAML in order to permit the encapsulation of SAML assertions (that might convey, for example, information about the user) in the OAuth protocol exchange, in conjunction with the otherwise OAuth-specific cryptographic credentials. As an alternative, Kerberos tickets could be sent either instead of or in conjunction with such SAML assertions. This could be appealing for a Kerberos-oriented OAuth service provider.

OAuth defines an initial registration and key-exchange step betwen consumer and service provider. In a scenario where consumer and provider use Kerberos this step could be skipped if a method to bootstrap OAuth keys from Kerberos were defined.

OpenID

[1] (reference material)

OpenID Identity Providers (OPs) could employ Kerberos to authenticate their users and this approach for an OpenID OP would probably be quite useful as a means for an enterprise to stand up an OP in front of its existing authentication infrastructure. It is unclear how common this approach will be but it as been argued that enterprise passwords would become less exposed by something like this since users typically pick the same password for their blog/yammer/amazon account as the password used at work since it is easier to remember it. This practice exposes the enterprise credential to additional risk. There is very little an enterprise security officer could do about this except to provide an alternative and reasonably safe way to reuse the enterprise authentication.

Message security

Security Strategies for Message-based architectures

Good message-based implementations understand that there are multiple SOAP transports and provide an interface for plugging in new ones, however in practice SOAP transports other than HTTP rarely occur when performance isn't an issue.

SOAP method calls are either secured at the transport or message layer or both. The "official" way to secure SOAP is to use WS-Security but transport-layer security is much more common especially in the cross-domain cases. In this case it is not uncommon for IPSEC to be used to provide a tunnel between the client and the server and for the HTTP-based SOAP-calls to be unauthenticated in this tunnel. When tunnels are not practical it is common for HTTPS (TLS) to be used in combination with a username and clear-text password.

The reason for using Kerberos may be any of:

• Kerberos is easier to use once deployed and if the service endpoint is one of many published by "A" then maintaining username and passwords will be unpractical for the same reasons that maintaining lots of password-based user identities would be impractical. In this case Kerberos provides life-cycle management for the identities used to secure the web service.
• Kerberos is the default security service used by the application framework used to develop and deploy the service endpoint.
• Kerberos is chosen because security policy mandates the use of Kerberos for identities.

There are (therefore) two ways to authenticate SOAP using Kerberos and if we ignore the possibility of using Kerberos with IPSEC for now:

• by securing the transport.
• by securing the SOAP messages.

The WS-* suite

[2] (reference material)

WS-* ("dubya ess star") denotes a suite of web services specifications promulgated by IBM, Microsoft and various collaborators. Unlike the SAML and ID-WSF specifications, only a few of the WS-* specifications have been subject to an open standardization process and subsequently their quality can be generously described as variable.

Of these specifications, there are three that are central to WS-* security

• WS-Security: this specification defines how security tokens are bound to messages. WS-* has defined security token profiles for SAML and Kerberos, amongst others, that can be leveraged by this specification. WS-* officially employs WS-Security-based messaging security techniques almost exclusively.
• WS-Trust: this specification defines how to exchange (request, issue, renew, cancel) security tokens with web services. These tokens may be used in a variety of ways; for example, as evidence to authorize access to a web service.
• WS-Federation: this specification is a specialization of WS-Trust that defines how to exchange security tokens in a federated context.

In the Web and Kerberos context, the most important of these is WS-Trust as it provides the mechanisms for using tokens that might be a Kerberos ticket or a SAML assertion) to establish and leverage trust. WS-Trust also plays a key role in the Information Cards technology, another specialization of WS-Trust.

WS-Security Kerberos Token Profile

[3] (reference material) [message security]

The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token. The acquisition of the token is out-of-scope.

The Kerberos message is attached to the SOAP message using the <wsse:BinarySecurityToken> element. Six different types are supported, including RFC 1510-style, RFC 4120-style and their equivalent GSS-API encapsulations. The octet sequence is encoded using the indicated method.

This specification does not support the KRB-AP-REP message, and so consequently neither Kerberos mutual authentication, nor GSS-API channel bindings, are supported. In practice, therefore, this specification needs to be combined with transport layer security (e.g. TLS).

OASIS Security Assertion Mark-up Language (SAML)

[4] (reference material)

SAML provides a suite of XML-based protocols that enables different security domains to exchange security data about user principals.

Broadly, the SAML specifications define:

• the assertion, a security token that can express a user principal's authentication status, authorizations and other general attribute information.
• protocols, that are primarily used to request assertions about a user principal.
• bindings, that define how protocols are bound to certain transports (such as SOAP).
• profiles, that constrain the use of assertions, protocols and bindings to realize specific use-cases (such as the "Web SSO Profile").
• federation metadata, that allows security domains to express information (primarily configuration data, such as a public key) about themselves to other security domains.

Although SAML focuses primarily on the passing of messages to federate identities in different security domains for Web SSO applications, the architecture of SAML allows discrete functional elements to be re-used in other contexts, allowing a broad range of potential applications. For example, the SAML assertion has been re-used in many other technologies - even technologies, such as WS-Federation implementations, which are competitive with SAML as a whole. Consequently it can be argued that the categorization of SAML as 'message security' is a generalization, depending on which particular SAML profile is being examined, and how it is specifically crafted in concert with the target protocol(s).

SAML does not stipulate the use of any particular trust model(s), although X.509-based trust establishment and TLS is widely used in practice.

There are several ways in which SAML, in terms of either SAML assertions themselves or the SAML profiles, can or could interface with Kerberos:

The SAML Identity Provider (IdP) uses Kerberos to validate usernames and passwords supplied by users on webpage forms

The main benefit offered by this configuration is that it allow users to use the same credentials to access resources protected by both SAML and Kerberos, offering users greater convenience. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is likely to be used by IdP deployments today.

The IdP uses Kerberos authentication at the HTTP layer - e.g. Negotiate or NTLM

The main benefit offered by this configuration is that it permits the use of Kerberos-based SSO to authenticate to the SAML IdP, offering greater convenience to users. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is known to be used by many IdP deployments today.

The IdP issues SAML assertions containing Kerberos tickets as an attribute

It would allow a SAML Relying Party to acquire a Kerberos ticket that it could use subsequently to authenticate, as another principal, against a Kerberos protected resource. The main benefit is that it could be used to support n-tier web-based use-cases (such as the webmail use-case), offering greater convenience to users and possibly reduce the abuse of user credentials by providing applications with delegable credentials. This would require modifications (possibly not too significant) to the SAML IdP.

The KDC includes a SAML assertion and/or authentication response message encapsulated in KDC-issued authorization data

It would allow the KDC to issue SAML assertions (or perhaps SAML messages in general) to Kerberos services. The main benefit is that this could be used to complement Kerberos-based authentication and/or provide richer authorization. This would probably require modification (probably reasonably significant) to the KDC.

The SP uses Negotiate to find the preferred IdP of the user (aka IdP discovery) based on the Kerberos-realm in the GSSAPI authentication request.

The benefit of this is that it reduces or eliminates the need to use GUI-based IdP Discovery (the commonest form of IdP discovery), which scales poorly and introduces UI considerations such as localization and accessibility. This is achievable with little modification to the SAML SP. It has already been implemented on SWITCH's "Where Are You From" service (but not used in their production federation).

A GSSAPI peer implementing the proposed GSSAPI naming extensions receives a SAML attribute assertion as part of a GSSAPI protocol exchange

While not strictly tied to Kerberos this may provide a way to tie in with other uses of the GSS-API naming extensions.

Liberty Alliance Identity Web Services Framework

[5] (reference material)

The Identity Web Services Framework (ID-WSF) is a set of specifications from the Liberty Alliance that builds on SAML to provide a full-featured web services stack that leverages WS-Security as its encapsulating security token format. Thus it is possible to leverage Kerberos-based authentication in an ID-WSF-based web services context, although at this time the limitations noted above with respect to the WS-Security Kerberos Token Profile will apply.

Security Technology Requirements

This section presents requirements that security technologies employed in the HTTP-based Web context ought to satisfy.

Security Protocol Overall Efficiency

Some small number of handshake exchanges in order to authenticate the principal with the IdP (i.e. KDC if Kerberos is being employed). Subsequent interactions with other websites, participating in the authentication domain, can be authenticated with a security token (e.g. a service ticket if Kerberos is being employed) accompanying HTTP messages from the user agent.

The rationale here is that for any given web page, a user agent may make any number (not infrequently on the order of tens O(10) ) of requests to the server. This is due to the the user agent typically retrieving web page constituent components, e.g. images, frames, tables, etc., with an HTTP request per component. This is sometimes referred to as being "chatty". Since such requests are performed independently and asynchronously over separate TCP connections, each HTTP request will need to convey authentication information that the service provider can validate & verify without further interactions.

Security Token Size

Because of the "chatty" property of some web interactions noted above, and the necessity of each individual HTTP request being authenticated, the security token size will likely matter.

Microsoft reports customer feedback to this effect: Active Directory et al encode principal group membership information -- Privilege Attribute Certificate (PAC) -- in the Kerberos service ticket. This can expand the ticket size to be over 12k bytes and noticeably slow down "chatty" web interactions. The same would likely be the case for attaching any other "large" chuck of information to service tickets and/or the HTTP requests themselves.

User Interaction

Some security technologies, e.g. Kerberos, are designed with the notion of signing the user on once, and then further interactions with participating entities (e.g. service provider websites) occurs in a transparently authenticated fashion.

However, in some contexts -- especially those in which principal attributes beyond baseline principal name and secret are conveyed -- it may be required for there to be interaction with the principal at least whenever the user agent is being compelled to convey more information than some configurable baseline to the service provider (aka relying party). This, for example, is one of the features of Information Cards' "Identity Selector" user agent, and the underlying Identity "Selector Interoperability Profile" protocol.

Browsers

Most browsers support Negotiate by default, but most either disable the feature (requiring the user to enable it manually) or limit its use to "local" sites or sites explicitly trusted. It is unclear what the threat-model looks like and this should be investigated further.

Safari

Safari supports Negotiate with SPNEGO since Tiger. There is an information card identity selector for safari here: http://www.hccp.org/safari-plug-in.html.

Mozilla/Firefox

The Mozilla and Firefox browser family includes native support for Negotiate using the Kerberos GSS-API mechanism. This feature is not turned on by default though, and must be turned on manually by editing the "prefs.js" file. Credentials delegation is supported but must also be turned on manually. There are a few plugins implementing Information Card for Firefox/Mozilla. It is unclear if any of them support Kerberos authentication for Information Card-based IdPs.

Internet Explorer

Negotiate was invented by Microsoft and is widely deployed through the implementation in the Internet Explorer family of web browsers.

Konqueror

Konqueror is the browser included in the KDE desktop framework. Konqueror supports Negotiate and enables Negotiate for sites in the same domain as the client. There is no support for Information Card yet in Konqueror.

Application environments & Libraries

IIS

IIS naturally has native support for Negotiate using the SPNEGO GSS-API mechanism.

.NET

The .NET framework supports the WS-Security Kerberos Token Profile as well as Negotiate natively.

Apache

Apache has add-on modules supporting Negotiate using both SPNEGO and Kerberos GSS-API including http://modauthkerb.sourceforge.net/.

Perl

The LPW::Authen::Negotiate module implements Negotiate using the GSSAPI perl module which in turn uses either Heimdal or MIT Kerberos libraries. This means that LPW::Authen::Negotiate can support both SPNEGO and Kerberos GSS-API.

Ruby

There is a GSS-API library for ruby which similar to the perl GSS-API library supports either MIT or Heimdal Kerberos. However the Ruby HTTP client library does not natively support Negotiate (it does support NTLM though). There have been working patches but they are not maintained. Ruby is one of the language of choice for "web 2.0" applications especially in combination with the Rails framework. These applications are known to prefer REST-style web services to more "enterprise"-style SOAP-based web services.

Java

Java has native support for the Kerberos GSS-API mechanism since JDK 1.4. A number of implementations of Negotiate exists for various application servers (e.g. Tomcat and JBoss). There are not free implementations of SPNEGO for JDK 1.5 and later although there are at least two commercial implementations. Since JDK 1.6 there is native support for SPNEGO.

WSS4j

WSS4J is the primary free implementation of XML security (from the apache project). It does not include an implementation of the Kerberos token profile.

Suggested Activities

• Back Channel (BC)
  1. Update the Kerberos Security Token Profile to support mutual authentication and channel bindings.
  2. Promote the implementation of the updated Kerberos Token Profile in common software frameworks (e.g. .NET, wss4j) and demonstrate interoperability.
  3. Update Kerberos cross-realm operation (in progress).
  4. Develop conventions or best-practices for integrating Kerberos into web-services governance solutions.

• Front Channel (FC)
  1. Promote implementation and interoperability testing of Kerberos authentication for Information Card.
  2. Update Negotiate (in progress).
  3. Interoperability testing of Negotiate implementations.
  4. Investigate the role of Kerberos in OpenID.
  5. Define a discovery mechanism for SAML Web SSO deployments with many Identity Providers, enabling service providers to establish the Identity Provider that a customer is affiliated with.

• Front and Back Channel (FB)
  1. Specify credentials-delegation for SAML-based SSO.
  2. Investigate the role of Kerberos in OAuth.
  3. Specify a SAML profile based on having the KDC sign a SAML authentication response/attribute assertion/authentication context. Also specify the relationship with GSS naming extensions.

• Other (O)
  1. Document the ways in which Kerberos can be used in a web-context with current technology, to assist contemporary deployers seeking to address certain use-cases today.
  2. Develop best-practices and boilerplate covering governance of Kerberos-based web services.

TODO: classify suggested activities by who needs to work on them, e.g. what SDOs / vendors / projects would need to be involved, skill set needed, SWAG wrt effort, etc.

also recommendations wrt near- / intermediat- / long-term phasing.

suggestion from SteveB:

One way to rank/organize these might be a table with the following  
columns:

Activity  Impact   Effort   Risks						


An example might be

Activity                   Impact                 Effort                  Risks
Investigate the role    May solve large problem   High, many years    Technology neither implemented
of Kerberos in OAuth.                                                 nor well understood