Difference between revisions of "KrbWeb Outline of Work"

Latest revision as of 18:15, 29 October 2008

Towards Kerberizing Web Identity and Services

Abstract

Today authentication and authorization are addressed in an incoherent, and often site-specific, fashion on the Internet 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. Organizations that currently use Kerberos as a key element of their infrastructure wish to take advantage of its unique benefits while moving to Web-based systems, but have had limited success in doing so.

In this document we outline the evolution of Web Identity and Services and describe the issues surrounding this complex landscape. These issues are captured within a set of more specific requirements that are deemed necessary to satisfy the relevant stakeholders; these requirements are then framed within the context of some general use cases. We then propose and describe a number of activities that leverage Kerberos to realize these improvements, and present an overall strategy and architectural model for working towards a more cohesive and widely deployed Kerberos-based Web authentication infrastructure.

Authors (alphabetical): Jeff Hodges; Josh Howlett, JANET; Leif Johansson; RL "Bob" Morgan, Internet2

1 Introduction
2 Acknowledgments
3 Related Pages
4 Overview
- 4.1 A Short History of Web Identity & Services
- 4.2 Summary
5 Stakeholder Requirements
6 Use Cases
7 Security Technologies and Opportunities
8 Implementation and Deployment Technologies
- 8.1 Browsers
- 8.2 Application Environments & Libraries
9 Analysis
10 Recommendations

Introduction

In this paper we attempt to provide a high level overview of how authentication, and to a lesser extent authorization, fits into today's Web landscape and explain Kerberos' place in that landscape. We follow with a brief presentation of "user stories" -- simple statements of what end users, service providers and enterprises desire in terms of their security related experiences when using the Web. Next, we describe a number of use cases that are intended to place these requirements within the context of typical scenarios. A number of specific web-relevant security technologies are discussed, and opportunities for extensions and improvements highlighted. 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 along with recommended opportunities to pursue.

This document surveys a broad spectrum of diverse, complex technologies and is intended to be suggestive of opportunities rather than rigorous. We hope that it will inspire enthusiasm for future efforts intended to make Kerberos work better for the Web.

Acknowledgments

The authors are grateful for the support of the MIT Kerberos Consortium. We also acknowledge and thank Russ Allbery, Love Hörnquist Åstrand, Steve Buckley, Michael Gettes, Sam Hartman, 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 & Services

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 is generally considered unsatisfactory (for example, the bland and "unbrandable" username and password dialog). Consequently, while these methods are often deployed within the Enterprise (typically to protect Intranets and programmatic web services where the user experience is a secondary concern), they were largely ignored by the broader Web development community, where so-called Form-based authentication has become 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 Form submission 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 similar solutions were concocted roughly in parallel, and the practice continues to the present day. Some examples include the WebAuth system concocted and deployed at Stanford University (mid-to-late 1990s); PubCookie from University of Washington; CoSign from the University of Michigan, and Yale's Central Authentication System (CAS). Today there are a number of commercial vendors present in this field.

The first OS-vendor-driven effort to improve Web authentication, providing users with a cohesive experience of web-based "identity" in addition to 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. This was derived from two earlier proposals, S2ML and AuthXML. SAML was the first technology for federated identity, and is the most successful. The SAML specifications were quickly leveraged by the Liberty Alliance, a broad vendor and "deploying organizations" consortium 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

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 centralize authentication (Form-based, Kerberos, X.509 certificate, etc) at the user's 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, dGovernment 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 many use cases -- and not scalable to the Internet community at large. These contentions form one of the many foci of the lively debates within the Internet identity technology community. More philosophically, there was also opposition to what many -- arguably 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 debate.

Arguably the claimed unique "user-centric" properties of OpenID are misconceived, and SAML can be profiled equivalently such that it is no less "user-centric". OpenID implementations however, being optimized for abject simplicity, are often 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. This architecture emerged in parallel with the development of Web services, and the systems used to secure them.

Emergence of Web Services

The notion of "Web Services" emerged in the late 1990s, and was intended to provide methods to facilitate "machine-to-machine" interactions that leveraged the same technologies underlying the browser-orientated "user-to-machine" Web. Web services were conceived, in part at least, as a response to the problems (such as transport through firewalls) of using earlier systems such as CORBA and DCOM between loosely coupled domains. Since there are many different interpretations of what web services are, what problems they address, and how they might be utilized, here are the interpretations taken in this paper:

A definition of Web Services:

A vague term referring to distributed software applications and/or agents that leverage the widely deployed Web infrastructure and protocols in order to compose higher-level applications also typically accessible via the Web. The term is also used to name a category of protocol and API specifications, the implementations of which become enabling components for actual web services applications and/or agents.

What problems are Web Services meant to solve?

Web services are envisioned to both minimize development time and effort of building distributed loosely-coupled web-based applications and/or features, and to enable making new/engaging/useful/profitable distributed web-based applications and/or features available to deployers and end users.

A generic Web Services example:

A hotel reservation web site that is able to additionally offer to end users airline, car, and dinner reservation capabilities, using an ever-changing set of partners, whose user-visible site presentation is also ever-changing, without site reprogramming.

The earliest attempts at Web Services, such as XML-RPC, took a Remote Procedure Call (RPC) orientated approach in which commands, parameters, and the return values are expressed using a small set of data types, encapsulated using XML and delivered directly over HTTP. While simple, this approach encouraged the development of services in which the RPC commands were bound directly to language or service specific functions, leading to criticisms that RPC-orientated approaches were too tightly coupled.

The RPC approach has, to a great extent, been superseded by message-orientated systems. These became widely visible with the submission of the Simple Object Access Protocol (SOAP) 1.1 specification to the W3C (as a "W3C Note") by Microsoft, IBM et al in the spring of 2000. SOAP consists of highly tailorable XML-encoded protocol messages capable of encapsulating arbitrary data, which 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 even though other transports (notably MQSeries) is common in large-scale homogeneous deployments. It is possible to discern an increased interest in SOAP conveyed by Message Oriented Middleware (MoM) in situations where performance is an issue. The distinction between SOAP as it was originally intended (a transport-neutral message layer) and SOAP as it is often deployed (using HTTP) has implications for the security mechanisms used.

A year later, IBM and 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 both the RPC and message orientated systems -- authentication, confidentiality, and integrity protection -- was originally left 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 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.

Despite energetic promotion by vendors as the "standards-based" approach to implementing web services, they are often criticized as being inefficient (owing to the XML overheads) and too complex for many applications.

More recently an alternative approach to both the RPC and message orientated systems has emerged with the development of services based on REST principles. While REST was originally framed in the context of hypermedia systems (of which the Web is one instance), it is now commonly used to describe resource-orientated Web services, where the resource is identified by a URI that yields a representation of that resource which is operated on using a constrained set of operations; for web services, these are the standard HTTP methods (GET, PUT, POST, DELETE).

An important distinction between these styles of Web services is that REST is descriptive, and not prescriptive like the message-based systems that have been discussed. Therefore, apart from the common use of URIs and adherence to RESTful principles, REST-based services' interfaces share relatively little in common; there are no standards for REST-based web services, although a number a REST-based web services may be considered as de facto standards.

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-*. 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 backend "web services"-based systems.

ID-WSF specifies use of SAML 2.0 security tokens (though other token types may be profiled for use) and leverages SAML 2.0's Web Browser SSO Profile for web single sign-on. The authentication service uses a SASL-based authentication exchange thus supporting the plethora of extant SASL mechanisms (including 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 (for example, "I am asking for my service locations"); it is also possible to express target identity contexts (for example, "I am asking for her calendar service"). While ID-WSF's specifications explicitly allow for extensions and profiling, these are carefully constrained; ID-WSF was designed to be concretely implementable and deployable directly from the original specification suite with no further profiling required.

This is markedly different from the WS-* stack, whose composition is much more ambiguous. First, IBM and Microsoft have different perspective on what constitutes the WS-* stack; secondly, 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 use 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). Therefore, 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.

Project Concordia

The balkanization of the Web identity landscape has lead to a highly confused marketplace. The large vendors (for example, Microsoft, Sun, IBM, etc) have not, to date, made any serious attempts to resolve their differences. The smaller Identity-focused vendors, such as Ping, who are not aligned to any particular technologies, have typically responded by implementing the most visible technologies.

An exception to this is Project Concordia, a recently formed effort to "drive interoperability across identity protocols". Project Concordia, while originally conceived by members of the Liberty Alliance, has taken pains to adopt a neutral stance and has subsequently attracted participation from all of the main stakeholders. Although it has been operating for approximately 18 months, Project Concordia is still only at the stage of developing use cases; these focus primarily on bridging between identity systems.

Kerberos is not currently represented as one of the technologies within the metasystem that they are addressing.

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.

Nonetheless, 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 sets out to describe a number of missing pieces of the puzzle which, when combined, can help the Kerberos Consortium realize the full potential of Kerberos as an authentication technology for the Web.

Stakeholder Requirements

The purpose of this section is to define a set of requirements by unpacking the high level issues identified in the previous section. These requirements are stated as "user stories", which are tools for evaluating the effectiveness of development activities and frequently appear in "Agile" development frameworks. A user story is simply a statement that describes a specific desire by a specific type of user in order to achieve a specific result. 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 the various stakeholders.

The user stories are presented in the table below, grouped by stakeholder type. These types are:

End Users: technically unsophisticated consumers of services provided by Enterprises (in the context of their employment) and Service providers (in the contexts of their employment and general online activities (shopping, leisure, etc))
Enterprises: organizations (often large-scale) that operate complex information systems for the benefit of end users affiliated to that organization (employees, contractors, students, etc).
Service Providers: organisations (often large-scale) that operate complex information systems for the benefit of end users that are not affiliated to that organization (customers, etc).
Federated Partners: two or more Enterprise and/or Service Providers who wish to federate their identity systems, for the purpose of enabling federated management of access to services.


	User Story
Stakeholders	Type	Code	Description
End Users
	Simplicity	U1	End users want to reduce the number of sign-on technologies and credentials that they are required to use to access web-based service providers.
	Transparency	U2	End users want to reduce the number of authentication steps taken when using service providers.
	Transparency	U3	End users want to use mobile devices when authenticating to service providers.
	Flexibility	U4	End users 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 service providers (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).
	Flexibility	U5	End users want to use untrusted devices (e.g. an airport Internet kiosk or a borrowed device) to access service providers without compromising their credentials.
Service Providers	Simplicity	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.
Service Providers	Risk management	S2	Service providers want to be able to manage and minimize the risks they assume in providing their service, particularly with respect to phishing in Financial services and similarly sensitive applications.
Enterprise	Risk management	E1	Enterprise security officers want secure authentication for SOA.
	Simplicity	E2	Enterprise SOA architects want flexible life-cycle management for identities used for SOA.
		E3	Enterprise administrators want to reuse existing Kerberos infrastructure when deploying web applications and web services in order to reduce the cost of security administration.
		E4	Enterprise system integrators want interoperability between web service implementations from major vendors.
	N-Tier	E5	Enterprise identity architects want SSO-support in popular browsers with credential delegation capabilities turned on by default.
	N-Tier	E6	Enterprise identity architects want to be able to extend existing cookie-based SSO systems with support for Kerberos backchannel authentication and credentials delegation.
Federated Partners	N-tier	F1	Deployers of web-based portal services with kerberized backend-services need to be able to use federated identity with N-tier authentication.
	Level of 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.
	Identity Provider Discovery	F3	Service providers 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'.
	Technical trust establishment	F4	Federated partners want to reduce the complexity and effort incurred in establishing technical trust between their systems.
	Governance	F5	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.

Use Cases

This section presents a number of use cases that are intended to illustrate the stakeholders' requirements within the context of some specific scenarios, which are used as a tool to expose the necessary development activities.

These 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 (and identity) providers occurring indirectly via a user-wielded tool -- typically, although not exclusively, a web browser. These interactions are normally invoked in response to an action performed by a user. For example, attempting to access a "protected" web page, and being asked to login at one's identity provider as a result.
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 pilot deployments, which were few in number, relied on the use of shared secrets for authentication and TLS for transport security.

As the deployments of web services expands, the management of the shared secrets becomes an issue. 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 and/or larger scale deployments; these concerns include the security (E1) and manageability (E2) (E3) of credentials. 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 organization would like to use Kerberos with these web services in order to simplify the management of their security requirements. However, the web services are perceived as distinct from the existing business infrastructure, and so consequently these services are often treated as a separate domain isolated from everything except those business systems to which they connect. There is therefore a requirement that the Kerberos administration must integrate into the various web service governance solutions that exist (E4).

Business-to-Business

A business needs to integrate with another business using a SOAP-based web service. 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 reasonably straightforward (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.

These businesses want to use Kerberos in order to leverage their pre-existing Kerberos infrastructure, and possibly an existing cross-realm trust, in order to avoid establishing a special purpose trust infrastructure (E1) (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 (F4).

The use of the web service is likely to be governed by contract. This may require provisions stipulating the required properties of the security technology used to manage and protect access to the service (F2) (F5).

Front channel

Business-to-employee and business-to-customer use cases typically involve front-channel exchanges through the user's (customer or employee) browser to the service provider. 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 lack of SSO impairs the user experience; the lack of mutual authentication increases the risks imposed by phishing.

In both cases, end users expect a single sign-on experience (U1) (U2) and increasingly demand access to service providers in a variety of non-traditional settings, including mobile devices (U3) and Internet kiosks (U5).

In multiparty federations, it is often difficult or impossible for a service provider to transparently determine which identity provider an end user is affiliated with. This leads to service providers implementing their own "discovery" user interfaces, which are frequently confusing to end users (F3).

Business-to-employee

A business wants to provide secure (E1) (E5) (E6) and manageable (E2) (E3) access to both internal corporate resources and resources offered by third-party service providers (such as SaaS providers). Employees want a single-sign on experience, but the business does not want to encourage the user to abuse their Enterprise identity or credentials within inappropriate non-business contexts (U4).

Business-to-customer

A service provider wants to provide secure (S2) and standardized (S1) access to end users affiliated to a very diverse range of identity providers.

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 backend 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, the company wants to use SAML-based Web SSO to provide federated authentication by the SAML identity providers operated by each IT function. These identity providers could provide the web portal with delegatable credentials for their own IMAP server(s) (E5) (E6) (F1).

Level-of-Assurance transport

A service provider has a policy that stipulates which type(s) of credentials are acceptable (this is often called the level of assurance). In scenarios where the service provider itself is authenticating the user's credentials, the policy is normally trivial to enforce using technical means because the service provider has visibility of the authentication event.

However in a distributed or federated environment the authentication of user credentials is often performed by a third party (the identity provider), 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 an element that enables an Identity Provider to express an Authentication Context, it is unspecified how this should be used in a Kerberos deployment (F2).

Deployment Case Studies

This section contains two brief case-studies that are intended to complement the scenarios depicted in the previous sections. The case-studies describes organizations that use Kerberos extensively to support large scale services (e.g. they have deployed the Andrew File System (AFS)), but nevertheless have very different views on web services. This illustrates that there is much work remaining before Kerberos is a natural choice for securing web services and web applications

Stanford University

In 2003, Stanford University redesigned its RPC middleware layer. At that time it was decided not to use web services because they wanted to avoid having to deploy an HTTP stack on a large number of systems and partly because initial experiments demonstrated problems using Kerberos as the basis for web service authentication. Consequently, Stanford decided to design their own RPC layer called "remctl". In this system, endpoints (servers and clients) authenticate themselves using GSS-API. A core design requirement was that Kerberos must be used for authentication because the cost of managing large numbers of username and passwords (or client certificates) was judged to be too high. Standford has developed multiple implementations of its system (using different application environments/languages currently in use there). Although the project is considered a resounding success there is increasing interest in the use of web services, typically to integrate with vendor solutions; where they do use web services, REST is preferred over SOAP.

Stockholm University

Stockholm University deploys a smaller (compared to Stanford) middleware infrastructure, implemented using SOAP-based web services. HTTPS is used as message transport for almost all web services. Server-side authentication is based on X.509 certificates using commercial PKIs. Client-side authentication is done using Negotiate. Credentials transport is sometimes done using GSS-API credentials delegation over Negotiate and in some cases using s4u2self (aka constrained delegation). Web services are often cross-platform (eg. clients and servers run on different application environments) but servers are mostly written using .NET or J2EE. Stockholm University also uses PubCookie as an enterprise SSO which is sometimes used to delegate Kerberos credentials to browser-facing web applications.

Conclusions

There is a clear need for interoperability and cross-platform support for Negotiate and credentials delegation and service deployment should be lightweight. Identity lifecycle management for services is an important consideration, which is often overlooked in the early stages of web service deployments. A Kerberos-based authentication mechanism for REST-based web services is also urgently needed.

Security Technologies and Opportunities

The security technologies that are relevant to the Web can be divided into four overall categories: transport, application, message and composite. This section discusses these technologies, how they compare and contrast with Kerberos, and presents potential opportunities for complementing these technologies with Kerberos.

It is not, however, unreasonable to ask what value Kerberos might bring to an already crowded and complex landscape. However, as described in The Role of Kerberos In Modern Information Systems, Kerberos possesses a number of properties, sometimes unique, that might contribute towards a more satisfactory Web authentication architecture.

Web-Specific Security Technology Requirements

Therefore, this section will initially discuss the general properties that security technologies employed in the Web context ought to satisfy, and highlight where Kerberos may be able to contribute.

Note that this is not an exhaustive set of overall security requirements, nor is it an overall security analysis.

Authentication Method Independence

It is often desirable to make the method of end user authentication independent of the mechanism that is used to subsequently to prove the user's identity to a service, particularly within federated environments. This independence allows identity providers to implement any user authentication method that satisfies the policies of the service providers, without those services needing to support the authentication method itself.

While Kerberos deployments commonly only use shared secret authentication, the protocol does support other methods of authentication.

Mutual Authentication

Mutual authentication describes a situation where both parties of a communication obtain attestation as to the identity of the other party, ideally upon initial authentication and effectively simultaneously. Mutual authentication is an essential part of building trust between users and systems, and the lack of mutual authentication in many Web authentication dialogues is the root causes of many security and privacy violations on the Web, such as phishing.

Kerberos provides mutual authentication as a normal feature of its protocol operation. In other security technologies, for example TLS, authentication of both parties is optional -- typically the server is authenticated to the client, and not the other direction.

Authorization

Authentication is normally a necessary criterion for satisfying many typical service providers' policies, but is rarely sufficient in isolation from authorization. For example, service providers commonly require evidence that an authenticated user has been accorded a set of privileges necessary to satisfy the service provider's security policy.

Kerberos service tickets can be embellished with authorization data describing the privileges accorded to the user. This facility is used extensively by Microsoft's Kerberos implementation to assert a user's authorizations within a data structure called the Privilege Attribute Certificate (PAC).

Credentials Delegation

It is useful to distinguish between two different scenarios that delegation can be used for: Enterprise and User driven.

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 also often difficult if one wants to retain the "end-to-end principle"; which in this context requires maintaining a cryptographic association 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 the 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 web application 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 delegation in which a user is asked to provide authorization every time a service needs to be able to access another service with the rights of that user. A typical example is a social networking site requiring access to the user's email service's address book. The OAuth protocol (discussed below) supports this type of case-by-case delegation. Although the Kerberos V5 specification has allowances that would permit implementations to craft such "user driven" behavior, such behavior is not typically implemented and/or presented to users.

Kerberos provides the ability to forward tickets; that is, 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 service is a simple traditional host-based service (for example, ssh or telnet) the delegation process is relatively uncomplicated. This changes dramatically with the advent of web-based applications which need access to user credentials in order to authenticate to kerberized backend services; this is sometimes referred to as "n-tier". The classic example is the web front-end to a kerberized IMAP server. As long as the authentication mechanism for the web application is basic access authentication or form-based authentication (so that 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.

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.

Security Token Size

The "chatty" nature of some web interactions, and the necessity of each individual HTTP request being authenticated, implies that the security token size will likely be an important consideration.

It is worth noting that the inclusion of authorization information in the Kerberos protocol can have 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 an intra-Enterprise or Federated SSO system, 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.

Experience with Active Directory in large-scale deployments, where the PAC can often grow to ~20k, indicates that the use of Kerberos can significantly degrade a Web application's performance, 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 hundreds of connections to the server. Microsoft reports customer feedback to this effect.

The same would likely also be the case for any other "large" chuck of information attached to service tickets, and/or the HTTP requests themselves.

User Interaction

Some security technologies, including Kerberos, are designed with the notion of signing the user on once; subsequent authentication interactions with participating entities (such as other service providers) occurs in manner that is transparent to the end user.

However, in some contexts -- especially those in which principal attributes beyond baseline principal name and secret are conveyed -- it may be necessary for there to be some interaction with the end user, at least whenever the user agent is being compelled to convey more information beyond some configurable baseline minimum, in order to prevent violations of the end user privacy.

This is one of the features of Information Cards' "Identity Selector" user agent, and the underlying "Identity Selector Interoperability Profile" protocol.

Transport security

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).

Kerberos-based alternatives (existing and proposed) for securing transports include:

Kerberos with TLS
- 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 [need citation].
- 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.
- University of Michigan CITI has produced a suite of middleware leveraging Kerberos for the provision of a lightweight PKI known as: Kerberos-leveraged PKI (K-PKI), and occasionally identified by one of its components, KX.509. The protocols do not appear to be officially standardized as yet. They are described in this CITI Technical Report: Kerberized Credential Translation: A Solution to Web Access Control. The LionShare project at Penn State produced a similar but more general service called SASL-CA that supports Kerberos and other authentication methods.
Kerberos with IPSec
- Some deployments apparently use Kerberos in concert with IPsec. We do not have good data on how well this works, but there are obvious issues with NAT boxes and firewalls in the path, as well as heterogeneous environments.

Opportunities

Specify the use of Kerberos with TLS

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O1	U1, U2, S1, E1, E3, E4.	High	High	High	TLS, Kerberos, GSS-API.	IETF Kerberos and TLS WGs.

The ability to use Kerberos via GSS-API as a CipherSuite option in Transport Layer Security (TLS) would avoid the problems inherent in using Kerberos at the application layer within HTTP (see the discussion on Negotiate for more information), thereby allowing general protection of HTTP-based services including REST. The same technique could also be used for the other styles of Web services (RPC and Message), thereby providing a common approach to securing Web services.

Investigate Leveraging and Standardizing K-PKI

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O1a	U1, U2, S1, E1, E3, E4.	Medium	Medium	High	TLS, Kerberos, GSS-API, KX.509 et al.	IETF Kerberos and TLS WGs, NSF NMI, CITI.

Short-lived Kerberos-leveraged key pairs and certificates could act as a key link between PKI-based transport security and Kerberos-based infrastructure.

Application security

Application security is provided by the application protocol itself; 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. Application security mechanisms are typically defined independent of transport security, although in practice implementations of application security often depend on transport 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, "HTTP Negotiate Authentication Scheme" defined in RFC 4559, SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows, uses the SPNEGO GSS-API mechanism (RFC 4178). Other implementations use the Kerberos 5 GSS-API mechanism (RFC 4121) instead. To add to the confusion, the term SPNEGO is sometimes said to denote both the GSS-API mechanism and the HTTP authentication mechanism.

It is worth noting that Negotiate authentication does not protect the HTTP request because it is 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 (this is the case with all other authentication techniques that are conveyed within HTTP message headers, including Basic and Digest), which implies use of transport layer security mechanisms, e.g. TLS, in conjunction with Negotiate.

Negotiate is observed to suffer from a lack of mutual authentication and effective support for multiple-roundtrip GSS-API mechanisms in a "real world" Web filled with "TLS concentrators" and HTTP proxies. 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.

Opportunities

Update Negotiate

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O2	U1, U2, S1, S2, E1, E3, E4.	Low	Low	Medium	Kerberos, GSS-API.	IETF Kerberos WG, Microsoft, other implementors of Negotiate.

Investigate the proposed modifications to Negotiate to perform state management.

Information Card

Information Card is an identity technology based on the notion of a smart client, called the identity selector, that resides on the end user's device. Under the control of a user, the identity selector can interact with a service provider, and also optionally an identity provider, to perform application sign-on and delivery of user information to the service provider.

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 Identity Provider, and requires authentication to that identity provider when used. Alternatively a card can be "self-issued", meaning that it is generated within the identity selector itself, and uses a keypair managed by the identity selector to authenticate to the service provider.

These interactions use the WS-Trust protocol, part of the WS-* suite of specifications. WS-Trust is intended to be a "meta" authentication protocol that can, in theory, permit a security token to be delivered to the service provider in whatever format it requires, independent of the method the client uses to authenticate to the identity provider.

Although 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 identity selector implementation is called CardSpace; because it is the best known implementation, many people incorrectly refer to the whole technology using this name. The Information Card concept was originally developed by Kim Cameron of Microsoft as part of a comprehensive design called the "Identity Metasystem." 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 identity providers (in the case of managed cards); Kerberos is one of these methods. The other methods include X.509 certificates, username and password, and the self-issued card (which is technically a SAML token).

Opportunities

Kerberos authentication from Identity Selector to identity provider

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O3	U1, U2.	Low	Low	Medium	Kerberos, WS-Trust, Information Card.	Enterprise deployers.

In a managed-card scenario the Identity Selector can authenticate to an identity provider using Kerberos, via the WS-Security Kerberos Token Profile bound to WS-Trust. An identity provider supporting Kerberos authentication would be an application server from the Kerberos point of view. However, none of the existing Information Card identity provider implementations supports Kerberos authentication, and so this presents an opportunity for improvement. Microsoft's identity provider (which probably won't be available until 2009) will support all four defined methods, including Kerberos.

Kerberos token delivery to the service provider

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O4	U1, U2, S1, S2, F3.	Low	Low	Medium	Kerberos, WS-Trust, Information Card.	Enterprise deployers, Kerberos community.

WS-Trust operates by delivering security tokens to service providers to authenticate clients. WS-Trust claims to be token agnostic -- meaning it can carry anything -- but for a token to be used its nature and processing must be specified and implemented by both the issuer and consumer of the token.

As mentioned previously, 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, which presumably would be based on a KRB_AP_REQ, would be generated by the IdP, carried by WS-Trust from the IdP via the user's Identity Selector to the relying party, where, after removing the WS-Trust wrapper, it could be 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 Kerberos tokens in WS-Trust as described here, hence there may be an opportunity for producing an interoperable implementation.

Identity Selector as the standard authentication user interface

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O5	U1, U2, S1, S2, F3.	Medium	Medium	High	Information Card, Kerberos.	Enterprises, end users, application protocol designers.

Information Card technology has been promoted primarily and energetically as an approach for browser authentication to web applications, given the urgency of a better web authentication solution. The identity selector concept, however, can apply to any instance of user authentication. This might involve extending identity 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

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 convey the access token (via their user agent). 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

OAuth augmented with SAML or Kerberos

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O6	U1,U2,E3,E6,S1	Medium	High	High	Kerberos, SAM, OAuth.	End Users, Enterprise, Service Providers, OAuth community, SAML community

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 Kerberos-based trust bootstrap

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O7	U1,U2,E1,E2,E3,S1	Medium	High	High	Kerberos and OAuth expertise.	End Users, Enterprise, Service Providers, OAuth community, SAML community

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

OpenID (http://openid.net/) is a specification for a web SSO system. It has many interoperable implementations and has been deployed at many sites, including large Internet providers such as Yahoo! and AOL. Originally proposed by a single developer, it was first formalized (in version 1.1) by an adhoc group. Based on industry-wide interest, the technology is now managed by the OpenID Foundation, which deals with intellectual property rights, specification process, and technology evangelism. The current version of the core authentication specification is 2.0, but there are several extensions at various levels of maturity.

OpenID's founding principles are (a) being web-oriented, (b) being simple, and (c) promoting ubiquitous interoperability of deployments. Being web-oriented means that the scope of the system is browser-based signon to web resources, the protocols use plain old HTTP (or HTTPS), and the preferred user identifiers are HTTP URLs. Being simple means, at least in version 1.1, addressing only mainstream authentication use cases, crafting the spec in a concrete fashion (i.e. it is not readily profilable), and avoiding reliance on other technologies (eg XML -- by using only name-value pairs to convey data). Promoting interoperability means providing a one-size-fits-all concrete solution to the "IdP discovery problem" (via URLs as userids), and providing a dynamic key establishment mechanism.

Like many web SSO schemes, OpenID leaves user initial authentication out of scope, so OpenID Identity Providers (OPs) can use any means to authenticate users. In practice almost all use username/password with form-based authentication. Since OpenID's deployment model promotes spontaneous interaction between OPs and SPs that may not have interacted before, the phishing vulnerability inherent in any username/password web SSO system is exacerbated.

Opportunities

Negotiate authentication against OpenID identity provider

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O8	U1,U2,E3	Low	Medium	Medium	Kerberos and OpenID.	End Users, Enterprise, OpenID community.

OpenID identity providers could use Kerberos to authenticate web users using SPNEGO/HTTP. The Identity Providers would the existing Kerberos infrastructure, enabling enterprise users to sign on to OpenID service providers thereby reducing the risk that users might reuse their enterprise credentials.

OpenID leveraging Kerberos for trust bootstrap

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O9	E1,E2,E3,F4	Medium	Medium	High	Kerberos and OpenID.	Enterprise, Service Providers, OpenID community.

Normally OpenID identity providers and service providers engage in a dynamic key setup protocol at their first interaction. This protocol is subject to DNS attacks (at least). If the identity provider and service provider were part of a common Kerberos infrastructure (perhaps via cross-realm trust) this setup protocol could use Kerberos and thus be performed more securely.

Message security

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, XMPP, etc), transit intermediate systems, or be retained on endpoint systems, while retaining intact their originating security context (modulo any allowances for message modification in-transit). This is in contrast to security context derived from the transport layer which typically reflects only the immediately communicating endpoints, that is it is "hop-by-hop", and the originating security context is lost if a message transits more than one hop, or tier.

Thus message security provides discernible endpoint-to-endpoint benefits in the face of multiple hops and/or differing transports.

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. 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.

SOAP method calls are either secured at the transport or message layer or both. Even though various web services specifications and stacks specify and promote using WS-Security to secure SOAP messages, it is common to use transport-layer security especially in the cross-domain cases. In the latter cases 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 (HTTP/TLS) to be used in combination with a username and clear-text password.

The reasons 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 impractical 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 (if we ignore the possibility of using Kerberos with IPSEC for now):

by securing the transport (this was discussed in a previous section of transport security).
by securing the SOAP messages.

WS-Security Kerberos Token Profile

The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token in conjunction with the WS-Security specification, the latter specifying a particular approach to obtaining SOAP message security. Although it is a piece of the broad WS-* composite web services specification suite, it may be employed in other contexts, for example, the Liberty ID-WSF web services framework also employs it.

The Kerberos message is attached to the SOAP message using the <wsse:BinarySecurityToken> element, however the acquisition of the Kerberos service ticket contained in the KRB-AP-REQ message is out-of-scope. Six different types of KRB-AP-REQ message are supported, including: RFC 1510-style, RFC 4120-style and their equivalent GSS-API encapsulations. The octet sequence is encoded using the indicated method.

Opportunities

Update WS-Security Kerberos Token Profile specification

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O10	U1,U2,E1,E2,E3,E6,F1.	High	High	High	Kerberos, WS-Security, OASIS	End Users, Enterprise

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).

Composite Security

This category refers to technologies where various aspects of the other categories are employed in various fashions. Such technologies are often defined in extensive, full-featured specification suites. Some technologies require further profiling in order to yield an implementable system that will address real-world use cases. Others feature concrete profiles as a part of the specification suite.

OASIS Security Assertion Mark-up Language (SAML)

SAML provides a suite of XML-based protocols that enables different security domains to exchange security data about subjects. A subject might be a user principal in a particular use case, but doesn't have to be, similar to how Kerberos is often deployed with explicit service principals.

Broadly, the SAML specifications define:

assertion, a security token that can express a subject's authentication status, authorizations and other general attribute information.
protocols, that are primarily for requesting assertions about subjects.
bindings defining how protocols are bound to certain transports (such as HTTP or SOAP).
profiles constraining and concretely defining the use of assertions, protocols and bindings to realize specific use cases (such as the "Web SSO Profile").
federation metadata, a format for expressing information (primarily configuration data, such as a public key) about SAML endpoints for consumption by partner endpoints.

Although many existing SAML profiles focus primarily on generating, obtaining, and conveying SAML assesrtions in order to federate identities in different security domains for Web SSO applications or web services, the architecture of SAML allows discrete functional elements to be re-used in other contexts, allowing a broad range of potential applications. In other words, SAML itself is an abstract framework (see: How to Study and Learn SAML). For example, the SAML assertion is re-used in many other technologies -- even technologies, such as WS-Federation implementations, which are competitive with SAML as a whole.

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.

Opportunities

Leverage SAML metadata to enable large-scale Kerberos cross-realm communities

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O11	U1,U2,E2,E3,F4	Low	High	Medium	Kerberos, SAML	End users, Enterprise, Service providers.

SAML Metadata is a key enabling technology for large-scale multi-party SAML federations (e.g. the InCommon Federation or the UK Access Management Federation). Via metadata trusted site configurations can be aggregated, annotated, signed, and distributed. There is no similar capability with Kerberos cross-realm technology today, which may be a barrier to growing Kerberos-based trust communities. The SAML metadata specification could be extended to support describing Kerberos entities. Alternatively, XRDS is a similar technology that is beginning to be used in OpenID, XRI, OAuth, and other related identity systems. It could also be profiled to describe Kerberos entities.

Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O12	U1,U2,E2,E3	Low	Low	Medium	Kerberos, SAML.	End users, Enterprise.

There are a number of ways a SAML identity provider can use Kerberos today to authenticate end users, such as validating user-supplied Kerberos credentials or Negotiate. The main benefit offered by these approaches is that they allow end users to access resources protected by both SAML and Kerberos, offering end users greater convenience. These methods are often achievable with little or no modifications to software, but nonetheless are not widely used. This activity would aim to promote the use of these methods.

Specify a SAML profile supporting the generation of SAML assertions containing Kerberos tickets ("Kerberos-in-SAML")

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O13	U1,U2,E1,E2,E3,E6,F1,F2.	Medium	High	High	Kerberos, SAML	End users, Enterprise, Service providers.

This would allow a SAML service provider to acquire a Kerberos ticket as part of a SAML transaction. This could be used by the service provider to authenticate, as another principal, against a Kerberos protected resource, thereby providing support for n-tier web-based use cases (such as the webmail use case). This would offer greater convenience to users and possibly reduce the abuse of user credentials that might otherwise be provided to applications with delegatable credentials.

Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data ("SAML-in-Kerberos")

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O14	U1,U2,U4,E1,E2,E3,E6,F1,F2,F3.	Medium	High	High	Kerberos, SAML.	End users, Enterprise, Service providers.

This would allow a Kerberos service to acquire a SAML assertion within a Kerberos ticket. This could be used to complement Kerberos-based authentication and/or provide richer authorization.

Specify a SAML profile that allows automatic discovery of the end user's identity provider based on the Kerberos-realm in the GSS-API authentication request

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O15	U1,U2,U4,F3.	Low	High	Medium	Kerberos, SAML.	End users, Service Providers, Enterprise.

This would reduce or eliminate the use of GUI-based IdP discovery (the commonest form of IdP discovery), which scales poorly and introduces considerations such as localization, accessibility, and phishing, significantly improving the end user experience.

Include a SAML attribute assertion within a GSSAPI protocol exchange

Code	Contributes towards addressing requirement(s)	Effort	Risk	Reward	Skills	Stakeholders
O16	U1,U2,U4,E1,E2,E3,F1,F2,F3.	Low	High	Medium	Kerberos, SAML, GSS-API	End users, Service Providers, Enterprise.

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

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.

The WS-* suite

WS-* 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 the overall security of the typical WS-*-based system:

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.

Opportunities

The most straightforward opportunity is to enhance the WS-Security Kerberos Token Profile as noted above. Such enhancements ought to subsequently carry throughout the WS-* suite by virtue of many of the suite's other specifications directly depending upon WS-Security and its token profiles.

Implementation and Deployment Technologies

This section lists the browsers and application environments and libraries deployers often use when constructing web-based applications. Specific features and ramifications of their use in the context of a web application environment are mentioned.

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

This section touches briefly on Kerberos and Negotiate HTTP mechanism capabilities in a number of application development environments. The number of potential environments of interest is large, and details of capabilities complex. Future work should focus on those environments of most importance to the Kerberos community stakeholders.

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.

Analysis

The diagram below summarizes the opportunities previously proposed.

We believe that, as a whole, the opportunities revealed through the back channel use cases are, in general, addressed more easily than those from the front channel use cases, in a technical sense. We also believe that satisfying the back channel use cases would yield greater benefits for relatively less effort. Many of these opportunities are shared with the front channel use cases; therefore, greater emphasis should be placed on them, even if they cannot be immediately realized within the front channel context because of other dependencies. Consequently, we recommend that the Kerberos Consortium focus primarily on the opportunities within this class of use cases. These opportunities, in suggested priority order, are:

O10 - Update WS-Security Kerberos Token Profile specification
O11 - Leverage SAML metadata to enable large-scale Kerberos cross-realm communities
O13 - Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets
O14 - SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data
O2 - Update Negotiate
O1 - Specify the use of Kerberos with TLS

Opportunity O10 is likely to yield benefits immediately, unlike O11 which is essentially a common dependency for other longer-term opportunities whose requirements will become more apparent as those opportunities are taken forwards. We therefore recommend that O10 is given a higher priority.

Four of these opportunities (O1, O2, O13, O14) are variations on the theme of improving or enhancing the transport of Kerberos and/or SAML tokens.

Opportunities O13 and O14 are superficially similar, in that they share SAML, Kerberos and a goal (authentication) in common, but are quite different architecturally. In particular O13 is, in essence, somewhat of an elaboration of the conventional SAML Web SSO Profiles, whereas O14 could be also used in other non-Web contexts. In this sense (of being limited to HTTP-only transactions) O1 is similar in applicability to O13. In light of this, and also the politics that is likely to impede progress on O1, we recommend that this opportunity is given a lower priority. Both O13 and O14 are likely to depend on, or be significantly enhanced by, O11, and are subsequently given lower priorities.

Another interesting distinction to draw between these activities is the potential impact on the client. It is likely that neither O13 nor O14 would require changes to existing client Kerberos or browser implementations, whereas O1 and O2 would probably require updates to the client TLS provider and browser implementations respectively. The inertia exerted by legacy client systems, particularly in the consumer context, would impede the proliferation of implementations.

The priority given to O2 probably depends on the importance given to the ability for a client to authenticate using Kerberos directly to a service provider rather than being used merely as evidence for some other type of authentication method, such as a SAML assertion. Given the widespread use of technologies such as SAML it would appear pragmatic to leverage these initially, particularly given the challenges presented by Kerberos cross-realm operation. While Negotiate has some flaws, these are generally manageable where it is used within a domain (for example, to authenticate against an Enterprise's identity provider). Consequently, we recommend that O2 is given a lower priority.

Strategically, the Kerberos Consortium needs to consider whether future work should emphasise Kerberos as a technology that complements existing Web authentication technologies ("Complementary Kerberos"), which could be realised more quickly but might be viewed as dilutory (O13, and to a lesser extent O14); or should this work emphasis strategies for authentication that are less tightly bound to other authentication technologies (O2), such as SAML, and the Web in general (O1), but that would require significant updates to clients perhaps incurring greater cost and delay ("King Kerberos").

Some of the opportunities within the front channel use cases are reasonably straightforward (in a technical sense) and could deliver benefits relatively quickly:

O12 - Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider
O3 - Kerberos authentication from Identity Selector to identity provider
O8 - Negotiate authentication against OpenID identity provider

We believe that opportunity O12 would be useful as a means of encouraging adoption of Kerberos for web authentication, raising awareness of the Kerberos Consortium's interest in this area, and "laying the foundations" for the more sophisticated opportunities discussed in this document. For example, MIT's Touchstone system could provide a case-study that would be of considerable value to other organizations attempting to leverage Kerberos for web authentication. Opportunities O3 and O8 would usefully complement existing federated systems, and these might also contribute towards O12.

Two other front channel opportunities exist that would yield significant benefits, but incur greater effort and time to realise owing to the necessary client updates. These are:

O5 - Identity Selector as the standard authentication user interface
O15 - Specify a SAML profile that allows automatic discovery of the end user's identity provider

The primary benefits of these opportunities are that they would improve the user experience and reduce the exposure to phishing attacks. These opportunities are therefore somewhat duplicative in their goals, but technologically highly dissimilar. The most appropriate approach would probably become more apparent when the strategic question concerning "Complementary Kerberos" or "King Kerberos" is resolved. In the former case, O15 is probably more appropriate; in the later case, O5 is probably more appropriate.

In summary, the table below provides two prioritized lists of the opportunities discussed to this point, depending on the strategic approach adopted by the Kerberos Consortium, and the relative risk and effort associated with which.

Opportunity code	Opportunity name	"King Kerberos" pre-requisite	"Complementary Kerberos" pre-requisite	Effort	Risk
10	Update WS-Security Kerberos Token Profile specification	High (3)	High (3)	High (3)	High (3)
11	Leverage SAML metadata to enable large-scale Kerberos cross-realm communities	High (3)	High (3)	Low (1)	High (3)
2	Update Negotiate	High (3)	Low (1)	Low (1)	Low (1)
12	Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider	Low (1)	High (3)	Low (1)	Low (1)
13	Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets	Low (1)	High (3)	Medium (2)	High (3)
14	SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data	High (3)	Low (1)	Medium (2)	High (3)
15	Specify a SAML profile that allows automatic discovery of the end user's identity provider	Low (1)	Medium (2)	Low (1)	High (3)
1	Specify the use of Kerberos with TLS	Medium (2)	Low (1)	High (3)	High (3)
3	Kerberos authentication from Identity Selector to identity provider	Low (1)	Medium (2)	Low (1)	Low (1)
5	Identity Selector as the standard authentication user interface	Medium (2)	Low (1)	Medium (2)	Medium (2)
8	Negotiate authentication against OpenID identity provider	Low (1)	Medium (2)	Low (1)	Medium (2)
Approximate overall relative effort		37	35
Appropriate overall relative risk		50	51

The remaining opportunities are:

01a - Investigate Leveraging and Standardizing K-PKI
O4 - Kerberos token delivery to the service provider
O6 - OAuth augmented with SAML or Kerberos
O7 - OAuth Kerberos-based trust bootstrap
O9 - OpenID leveraging Kerberos for trust bootstrap
O16 - Include a SAML attribute assertion within a GSS-API protocol exchange

We are not at this time assigning priorities amongst these remaining opportunities.

Recommendations

On the basis of the analysis presented in the previous section, we conclude by presenting a set of recommendations.

Recommendation 1: Determine the overall strategic approach in consultation with relevant stakeholders

In our analysis, we presented two possible directions: "King Kerberos" and "Complementary Kerberos". The risks and effort associated with both courses are roughly equivalent, although we believe that the latter is likely to yield faster results given the opportunity to leverage existing Web authentication systems and minimize alterations to the client.

These options are not, of course, mutually exclusive; it would be possible to develop a hybrid strategy that, for example, assumes a "Complementary Kerberos" direction initially to achieve some results sooner and transition towards a "King Kerberos" direction once this strategy's more complex dependencies are resolved. This is the recommendation of the authors although we accept that, given the complexity and number of variables involved, there are probably a number of other approaches that would be difficult to argue against.

We recommend that the Kerberos Consortium continues this discussion with all the relevant stakeholders.

Recommendation 2: Initiate activities to address those opportunities whose applicability is independent of strategic direction

There are three opportunities whose applicability is largely independent of the strategic direction chosen; these are opportunities O10 ("Update WS-Security Kerberos Token Profile specification"), O11 ("Leverage SAML metadata to enable large-scale Kerberos cross-realm communities"), and O12 ("Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider").

Recommendation 3: Plan and prioritize the most critical subsequent activities

In our analysis, we presented two possible strategic directions. While recognising that other strategies probably exist, in this recommendation we provide a list of what the present authors consider to be the most urgent opportunities for each of these stategies.

These activities should be planned in parallel to the development of the activities initiated previously to ensure that these key outputs form part of a cohesive architecture.

"King Kerberos"
- O2: Update Negotiate.
- O14: SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data.
"Complementary Kerberos"
- O13: Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets.
- O3: Kerberos authentication from Identity Selector to identity provider.

Recommendation 4: Develop an overall architecture

It will be necessary to develop an overall architecture that presents a conceptual model describing how the relevant components are coupled and work together.

While certain elements of this architecture are relatively obvious (thus the recommended activities in recommendations 2 and 3), it is the authors' opinion that the space of acceptable and feasible architectures (given the requirements and constraints that we know about today) is of significant volume and therefore difficult to make concrete without making grievous assumptions.

However, in the process of planning and implementing the activities recommended in recommendations 2 and 3, it is likely that new constraints (technical, political or otherwise) will present themselves. These will, most probably, significantly constrain the space of acceptable and feasible architectures and highlight gaps that might not be evident to the authors at the present time. If gaps are identified their impact should be analyzed and, if necessary, steps taken to remedy them.

We therefore recommend that the Kerberos Consortium develops an overall architecture, and that this should proceed in parallel with the activities initiated in the previous recommendations.

@@ Line 1: / Line 1: @@
 '''<font size="5">Towards Kerberizing Web Identity and Services</font>'''
+<font size="5">Abstract</font>
+Today authentication and authorization are addressed in an incoherent, and often site-specific, fashion on the Internet 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.
-<font size="5">Abstract</font>
+Kerberos is a widely-implemented and widely-deployed authentication substrate with a long history in various communities and vendor products. Organizations that currently use Kerberos as a key element of their infrastructure wish to take advantage of its unique benefits while moving to Web-based systems, but have had limited success in doing so.
-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.
+In this document we outline the evolution of Web Identity and Services and describe the issues surrounding this complex landscape. These issues are captured within a set of more specific requirements that are deemed necessary to satisfy the relevant stakeholders; these requirements are then framed within the context of some general use cases. We then propose and describe a number of activities that leverage Kerberos to realize these improvements, and present an overall strategy and architectural model for working towards a more cohesive and widely deployed Kerberos-based Web authentication infrastructure.
 ;Authors (alphabetical):
-:Jeff Hodges, Kings Mountain Systems
+:Jeff Hodges
 :Josh Howlett, JANET
-:Leif Johansson, Stockholm University
+:Leif Johansson
-:RL "Bob" Morgan, Internet2 / University of Washington
+:RL "Bob" Morgan, Internet2
@@ Line 21: / Line 23: @@
 ==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.
+In this paper we attempt to provide a high level overview of how authentication, and to a lesser extent authorization, fits into today's Web landscape and explain Kerberos' place in that landscape. We follow with a brief presentation of "user stories" -- simple statements of what end users, service providers and enterprises desire in terms of their security related experiences when using the Web. Next, we describe a number of use cases that are intended to place these requirements within the context of typical scenarios. A number of specific web-relevant security technologies are discussed, and opportunities for extensions and improvements highlighted. 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 along with recommended opportunities to pursue.
+This document surveys a broad spectrum of diverse, complex technologies and is intended to be suggestive of opportunities rather than rigorous. We hope that it will inspire enthusiasm for future efforts intended to make Kerberos work better for the Web.
 ==Acknowledgments==
@@ Line 37: / Line 39: @@
 ===A Short History of Web Identity & Services===
-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.
+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====
@@ Line 60: / Line 62: @@
 The need for some notion of "Web [http://en.wikipedia.org/wiki/Single_sign-on 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 similar solutions were concocted roughly in parallel, and the practice continues to the present day. Some examples include the [http://www.stanford.edu/services/webauth/ WebAuth] system concocted and deployed at Stanford University (mid-to-late 1990s); [http://en.wikipedia.org/wiki/Pubcookie PubCookie] from University of Washington; [http://www.umich.edu/~umweb/software/cosign/ CoSign] from the University of Michigan, and Yale's [http://www.ja-sig.org/products/cas/ Central Authentication System (CAS)]. Today there are a number of commercial vendors present in this field.
-The first OS-vendor-driven effort to improve Web authentication, providing users with a cohesive experience of web-based "identity" in addition to Web SSO, was [http://en.wikipedia.org/wiki/Windows_Live_ID 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.
+The first OS-vendor-driven effort to improve Web authentication, providing users with a cohesive experience of web-based "identity" in addition to Web SSO, was [http://en.wikipedia.org/wiki/Windows_Live_ID 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 [http://www.oasis-open.org OASIS] -- the [http://www.oasis-open.org/committees/security Security Services TC (SSTC)] -- was established to define [http://en.wikipedia.org/wiki/Saml SAML], an open XML-based identity system. This was derived from two earlier proposals, S2ML and AuthXML. SAML was the first technology for [http://en.wikipedia.org/wiki/Federated_identity federated identity], and is the most successful. The SAML specifications were quickly leveraged by the [http://en.wikipedia.org/wiki/Single_sign-on Liberty Alliance], a broad vendor and "deploying organizations" consortium reacting to the perceived threat from Passport, for their own [http://www.projectliberty.org/liberty/resource_center/specifications/specifications_archives/liberty_alliance_phase_i_1_0_specifications ID-FF (Identity Federation Framework)] specifications.
@@ Line 70: / Line 72: @@
 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 centralize authentication (Form-based, Kerberos, X.509 certificate, etc) at the user's 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, dGovernment 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 many use cases - and not scalable to the Internet community at large. These contentions form one of the many foci of the lively debates within the Internet identity technology community. More philosophically, there was also opposition to what many -- arguably 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.
+SAML, and the Liberty Alliance specifications in particular, are perceived to focus primarily on finding solutions for Enterprise, dGovernment 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 many use cases -- and not scalable to the Internet community at large. These contentions form one of the many foci of the lively debates within the Internet identity technology community. More philosophically, there was also opposition to what many -- arguably 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 [http://www.openid.net/ OpenID] protocol, and the "user-centric" movement that espouses it, is the clearest manifestation of this debate.
@@ Line 76: / Line 78: @@
 Arguably the claimed unique "user-centric" properties of OpenID are misconceived, and SAML can be profiled equivalently such that it is no less "user-centric". OpenID ''implementations'' however, being optimized for abject simplicity, are often 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.
+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====
@@ Line 84: / Line 86: @@
 ====Emergence of Web Services====
-The notion of "Web Services" emerged in the late 1990s, and was intended to provide methods to facilitate 'machine-to-machine' transactions that leveraged the same technologies underlying the browser-orientated 'user-to-machine' Web. Web services were conceived, in part at least, as a response to the problems (such as transport through firewalls) of using earlier systems such as CORBA and DCOM between loosely coupled domains.
+The notion of "Web Services" emerged in the late 1990s, and was intended to provide methods to facilitate "machine-to-machine" interactions that leveraged the same technologies underlying the browser-orientated "user-to-machine" Web. Web services were conceived, in part at least, as a response to the problems (such as transport through firewalls) of using earlier systems such as CORBA and DCOM between loosely coupled domains. Since there are many different interpretations of what web services are, what problems they address, and how they might be utilized, here are the interpretations taken in this paper:
-;A definition of Web Services is:
+A definition of Web Services:
 :A vague term referring to distributed software applications and/or agents that leverage the widely deployed Web infrastructure and protocols in order to compose higher-level applications also typically accessible via the Web. The term is also used to name a category of protocol and API specifications, the implementations of which become enabling components for actual web services applications and/or agents.
-;What problems are Web Services meant to solve?
+What problems are Web Services meant to solve?
-:Web Services are envisioned to both minimize development time and effort of building distributed loosely-coupled web-based applications and/or features, and to enable making new/engaging/useful/profitable distributed web-based applications and/or features available to deployers and end users.
+:Web services are envisioned to both minimize development time and effort of building distributed loosely-coupled web-based applications and/or features, and to enable making new/engaging/useful/profitable distributed web-based applications and/or features available to deployers and end users.
-;A generic Web Services example is:
+A generic Web Services example:
 :A hotel reservation web site that is able to additionally offer to end users airline, car, and dinner reservation capabilities, using an ever-changing set of partners, whose user-visible site presentation is also ever-changing, without site reprogramming.
-The earliest attempts at Web Services, such as [http://en.wikipedia.org/wiki/XML-RPC XML-RPC], took a Remote Procedure Call (RPC) orientated approach in which commands, parameters, and the return values are expressed using a small set of data-types, encapsulated using XML and delivered directly over HTTP. While simple, this approach encouraged the development of services in which the RPC commands were bound directly to language or service specific functions, leading to criticisms that RPC-orientated approaches were too tightly coupled.
+The earliest attempts at Web Services, such as [http://en.wikipedia.org/wiki/XML-RPC XML-RPC], took a Remote Procedure Call (RPC) orientated approach in which commands, parameters, and the return values are expressed using a small set of data types, encapsulated using XML and delivered directly over HTTP. While simple, this approach encouraged the development of services in which the RPC commands were bound directly to language or service specific functions, leading to criticisms that RPC-orientated approaches were too tightly coupled.
 The RPC approach has, to a great extent, been superseded by message-orientated systems. These became widely visible with the submission of the ''Simple Object Access Protocol ([http://en.wikipedia.org/wiki/SOAP SOAP]) 1.1'' specification to the W3C (as a "W3C Note") by Microsoft, IBM et al in the spring of 2000. SOAP consists of highly tailorable XML-encoded protocol messages capable of encapsulating arbitrary data, which 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 even tough other transports (notably [http://www.mqseries.net/ MQSeries]) is common in large-scale homogeneous deployments. It is possible to discern an increased interest in SOAP conveyed by [http://en.wikipedia.org/wiki/Message_Oriented_Middleware Message Oriented Middleware (MoM)] in situations where performance is an issue. The distinction between SOAP as it was originally intended (a transport-neutral message layer) and SOAP as it is often deployed (using HTTP) has implications for the security mechanisms used.
+"Web Services" were felt by these practitioners to essentially exclusively consist of SOAP messages conveyed by HTTP even though other transports (notably [http://www.mqseries.net/ MQSeries]) is common in large-scale homogeneous deployments. It is possible to discern an increased interest in SOAP conveyed by [http://en.wikipedia.org/wiki/Message_Oriented_Middleware Message Oriented Middleware (MoM)] in situations where performance is an issue. The distinction between SOAP as it was originally intended (a transport-neutral message layer) and SOAP as it is often deployed (using HTTP) has implications for the security mechanisms used.
 A year later, IBM and 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.
@@ Line 107: / Line 109: @@
 By 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.
-Despite energetic promotion by vendors as the 'standards-based' approach to implementing web services, they are often criticized as being inefficient (owing to the XML overheads) and too complex for many applications.
+Despite energetic promotion by vendors as the "standards-based" approach to implementing web services, they are often criticized as being inefficient (owing to the XML overheads) and too complex for many applications.
-An alternative approach to both the RPC and message orientated systems has emerged with the development of services based on [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] principles. While REST was originally framed in the context of hypermedia systems (of which the Web is one instance), it is now commonly used to describe resource-orientated Web services, where the resource is identified by a URI that yields a representation of that resource which is operated on using a constrained set of operations; for web services, these are the standard HTTP methods (GET, PUT, POST, DELETE)
+More recently an alternative approach to both the RPC and message orientated systems has emerged with the development of services based on [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] principles. While REST was originally framed in the context of hypermedia systems (of which the Web is one instance), it is now commonly used to describe resource-orientated Web services, where the resource is identified by a URI that yields a representation of that resource which is operated on using a constrained set of operations; for web services, these are the standard HTTP methods (GET, PUT, POST, DELETE).
 An important distinction between these styles of Web services is that REST is descriptive, and not prescriptive like the message-based systems that have been discussed. Therefore, apart from the common use of URIs and adherence to RESTful principles, REST-based services' interfaces share relatively little in common; there are no standards for REST-based web services, although a number a REST-based web services may be considered as ''de facto'' standards.
@@ Line 117: / Line 119: @@
 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.
+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-*''. 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 backend "web services"-based systems.
-ID-WSF specifies use of SAML 2.0 security tokens (though other token types may be profiled for use) and leverages SAML 2.0's Web Browser SSO Profile for web single sign-on. The authentication service uses a SASL-based authentication exchange thus supporting the plethora of extant SASL mechanisms (including 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 (for example, "'''I''' am asking for '''my''' service locations"); it is also possible to express target identity contexts (for example, "'''I''' am asking for '''her''' calendar service"). While ID-WSF's specifications explicitly allow for extensions and profiling, these are carefully constrained; ID-WSF was designed to be concretely implementable and deployable directly from the original specification suite with no further profiling required.
+ID-WSF specifies use of SAML 2.0 security tokens (though other token types may be profiled for use) and leverages SAML 2.0's Web Browser SSO Profile for web single sign-on. The authentication service uses a SASL-based authentication exchange thus supporting the plethora of extant SASL mechanisms (including 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 (for example, "''I'' am asking for ''my'' service locations"); it is also possible to express target identity contexts (for example, "''I'' am asking for ''her'' calendar service"). While ID-WSF's specifications explicitly allow for extensions and profiling, these are carefully constrained; ID-WSF was designed to be concretely implementable and deployable directly from the original specification suite with no further profiling required.
 This is markedly different from the WS-* stack, whose composition is much more ambiguous. First, IBM and Microsoft have different perspective on what constitutes the WS-* stack; secondly, 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 use 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). Therefore, 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.
@@ Line 127: / Line 129: @@
 The balkanization of the Web identity landscape has lead to a highly confused marketplace. The large vendors (for example, Microsoft, Sun, IBM, etc) have not, to date, made any serious attempts to resolve their differences. The smaller Identity-focused vendors, such as Ping, who are not aligned to any particular technologies, have typically responded by implementing the most visible technologies.
-An exception to this is Project Concordia, a recently-formed effort to "drive interoperability across identity protocols". Project Concordia, while originally conceived by members of the Liberty Alliance, has taken pains to adopt a neutral stance and has subsequently attracted participation from all of the main stakeholders. Although it has been operating for approximately 18 months, Project Concordia is still only at the stage of developing use-cases; these focus primarily on bridging between identity systems.
+An exception to this is Project Concordia, a recently formed effort to "drive interoperability across identity protocols". Project Concordia, while originally conceived by members of the Liberty Alliance, has taken pains to adopt a neutral stance and has subsequently attracted participation from all of the main stakeholders. Although it has been operating for approximately 18 months, Project Concordia is still only at the stage of developing use cases; these focus primarily on bridging between identity systems.
 Kerberos is not currently represented as one of the technologies within the metasystem that they are addressing.
@@ Line 134: / Line 136: @@
 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.
+Nonetheless, 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 [http://en.wikipedia.org/wiki/Active_directory 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 sets out to describe a number of missing pieces of the puzzle which, when combined, can help the Kerberos Consortium realize the full potential of Kerberos as an authentication technology for the Web.'''
@@ Line 139: / Line 145: @@
 ==Stakeholder Requirements==
-The purpose of this section is to define a set of requirements by unpacking the high-level issues identified in the previous section. These requirements are stated as "user stories", which are tools for evaluating the effectiveness of development activities and frequently appear in "Agile" development frameworks.  A user story is simply a statement that describes a specific desire by a specific type of user in order to achieve a specific result. 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 the various stakeholders.
+The purpose of this section is to define a set of requirements by unpacking the high level issues identified in the previous section. These requirements are stated as "user stories", which are tools for evaluating the effectiveness of development activities and frequently appear in "Agile" development frameworks.  A user story is simply a statement that describes a specific desire by a specific type of user in order to achieve a specific result. 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 the various stakeholders.
 The user stories are presented in the table below, grouped by stakeholder type. These types are:
-* '''End-users''': technically unsophisticated consumers of services provided by Enterprises (in the context of their employment) and Service providers (in the contexts of their employment and general online activities (shopping, leisure, etc))
+* '''End Users''': technically unsophisticated consumers of services provided by Enterprises (in the context of their employment) and Service providers (in the contexts of their employment and general online activities (shopping, leisure, etc))
-* '''Enterprises''': organizations (often large-scale) that operate complex information systems for the benefit of end-users affiliated to that organization (employees, contractors, students, etc).
+* '''Enterprises''': organizations (often large-scale) that operate complex information systems for the benefit of end users affiliated to that organization (employees, contractors, students, etc).
-* '''Service Providers''': organisations (often large-scale) that operate complex information systems for the benefit of end-users that are not affiliated to that organization (customers, etc).
+* '''Service Providers''': organisations (often large-scale) that operate complex information systems for the benefit of end users that are not affiliated to that organization (customers, etc).
 * '''Federated Partners''': two or more Enterprise and/or Service Providers who wish to federate their identity systems, for the purpose of enabling federated management of access to services.
 {| border=1
-|- bgcolor=grey
+|- bgcolor=#CDCDCD
-! Stakeholders
+!rowspan=2|
-! User Story Type
+|- bgcolor=#CDCDCD
-! User Story Code
+!colspan=3|User Story
-! User Story Description
+|- bgcolor=#CDCDCD
+!Stakeholders
+!Type
+!Code
+!Description
 |-
-|rowspan=6| End Users
+|rowspan=6|End Users
 |-
 |Simplicity
@@ Line 231: / Line 237: @@
 ==Use Cases==
-This section presents a number of use-cases that are intended to illustrate the requirements within the context of some specific scenarios.
+This section presents a number of use cases that are intended to illustrate the stakeholders' requirements within the context of some specific scenarios, which are used as a tool to expose the necessary development activities.
-The scenarios are used as a tool to expose the development activities that are needed to realize the use-cases.
-These use-cases are divided between three categories
+These 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.
+* ''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 Channel'': this describes interactions between service (and identity) providers occurring indirectly via a user-wielded tool -- typically, although not exclusively, a web browser. These interactions are normally invoked in response to an action performed by a user. For example, attempting to access a "protected" web page, and being asked to login at one's identity provider as a result.
-* ''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).
+* ''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===
@@ Line 243: / Line 249: @@
 ====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.
+A large organization is deploying an increasing number of web services. Initial pilot deployments, which were few in number, relied on the use of shared secrets for authentication and TLS for transport security.
 As the deployments of web services expands, the management of the shared secrets becomes an issue. 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 and/or larger scale deployments; these concerns include the security (E1) and manageability (E2) (E3) of credentials. 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. 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 (E4).
+The organization would like to use Kerberos with these web services in order to simplify the management of their security requirements. However, the web services are perceived as distinct from the existing business infrastructure, and so consequently these services are often treated as a separate domain isolated from everything except those business systems to which they connect. There is therefore a requirement that the Kerberos administration must integrate into the various web service governance solutions that exist (E4).
 ====Business-to-Business====
-A business needs to integrate with another business using a SOAP-based web service. 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.
+A business needs to integrate with another business using a SOAP-based web service. 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 reasonably straightforward (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 (E1) (E2).
+These businesses want to use Kerberos in order to leverage their pre-existing Kerberos infrastructure, and possibly an existing cross-realm trust, in order to avoid establishing a special purpose trust infrastructure (E1) (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 (F4).
+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 (F4).
 The use of the web service is likely to be governed by contract. This may require provisions stipulating the required properties of the security technology used to manage and protect access to the service (F2) (F5).
@@ Line 261: / Line 267: @@
 ===Front channel===
-Business-to-employee and business-to-customer use-cases typically involve front-channel exchanges through the user's (customer or employee) browser to the service provider. 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 lack of SSO impairs the user experience; the lack of mutual authentication increases the risks imposed by phishing.
+Business-to-employee and business-to-customer use cases typically involve front-channel exchanges through the user's (customer or employee) browser to the service provider. 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 lack of SSO impairs the user experience; the lack of mutual authentication increases the risks imposed by phishing.
-In both cases, end-users increasingly expect to be able to access service providers in a variety of non-traditional settings, including mobile devices (U3) and Internet kiosks (U5).
+In both cases, end users expect a single sign-on experience (U1) (U2) and increasingly demand access to service providers in a variety of non-traditional settings, including mobile devices (U3) and Internet kiosks (U5).
-In multiparty federations, it is often difficult or impossible for a service provider to transparently determine which identity provider an end-user is affiliated with. This leads to service providers implementing their own 'discovery' user interfaces, which are frequently confusing to end-users (F3).
+In multiparty federations, it is often difficult or impossible for a service provider to transparently determine which identity provider an end user is affiliated with. This leads to service providers implementing their own "discovery" user interfaces, which are frequently confusing to end users (F3).
 ====Business-to-employee====
-A business wants to provide secure (E1) (E5) (E6) and manageable (E2) (E3) access to both internal corporate resources and resources offered by third-party service providers (such as SaaS providers). Employees want to use their usual Enterprise credentials for both types of access (U1) (U2).
+A business wants to provide secure (E1) (E5) (E6) and manageable (E2) (E3) access to both internal corporate resources and resources offered by third-party service providers (such as SaaS providers). Employees want a single-sign on experience, but the business does not want to encourage the user to abuse their Enterprise identity or credentials within inappropriate non-business contexts (U4).
 ====Business-to-customer====
-A service provider wants to provide secure (S2) and standardized (S1) access to end-users affiliated to a very diverse range of identity providers.
+A service provider wants to provide secure (S2) and standardized (S1) access to end users affiliated to a very diverse range of identity providers.
 ===Front and Back Channel Composition===
@@ Line 279: / Line 285: @@
 ====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, the company wants to use SAML-based Web SSO ito provide federated authentication by the SAML Identity Providers operated by each IT function. These Identity Providers could provide the web portal with delegate-able credentials for their own IMAP server(s) (E5) (E6) (F1).
+A recently merged company wishes to provide the newly-united workforces with a single web portal providing access to various backend 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, the company wants to use SAML-based Web SSO to provide federated authentication by the SAML identity providers operated by each IT function. These identity providers could provide the web portal with delegatable credentials for their own IMAP server(s) (E5) (E6) (F1).
 ====Level-of-Assurance transport====
-A service provider has a have policy that stipulates which type(s) of credentials are acceptable (this is often called the ''level of assurance''). In scenarios where the service provider itself is authenticating the user's credentials, the policy is normally trivial to enforce using technical means because the service provider has visibility of the authentication event.
+A service provider has a policy that stipulates which type(s) of credentials are acceptable (this is often called the ''level of assurance''). In scenarios where the service provider itself is authenticating the user's credentials, the policy is normally trivial to enforce using technical means because the service provider has visibility of the authentication event.
 However in a distributed or federated environment the authentication of user credentials is often performed by a third party (the identity provider), 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).
@@ Line 289: / Line 295: @@
 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 an element that enables an Identity Provider to express an ''Authentication Context'', it is unspecified how this should be used in a Kerberos deployment (F2).
-==Deployment Case Studies and Lessons==
+===Deployment Case Studies===
-This section contains two brief case-studies. Both organizations described below are "Kerberos-shops" with large scale services depending on Kerberos (e.g. they have deployed the [http://en.wikipedia.org/wiki/Andrew_File_System Andrew File System (AFS)]) but have nevertheless have very different views on web services. This illustrates that there is much work remaining before Kerberos is a natural choice for securing web services and web applications
+This section contains two brief case-studies that are intended to complement the scenarios depicted in the previous sections. The case-studies describes organizations that use Kerberos extensively to support large scale services (e.g. they have deployed the [http://en.wikipedia.org/wiki/Andrew_File_System Andrew File System (AFS)]), but nevertheless have very different views on web services. This illustrates that there is much work remaining before Kerberos is a natural choice for securing web services and web applications
-===Stanford University===
+====Stanford University====
-In 2003 Stanford redesigned its RPC middleware layer. At that time it was determined not to use web services but rather to design a new RPC system ("remctl") from scratch. Endpoints (servers and clients) authenticate themselves using GSS-API. A core design requirement was that Kerberos must be used for authentication since the cost of managing large numbers of username and passwords (or client certificates) was judged to be too high. Standford has developed multiple implementations of its system (using different application environments/languages currently in use there). The project is considered a resounding success. The reason Stanford decided to design their own RPC layer was partly to avoid having to deploy an HTTP stack on a large number of systems and partly because initial experiments showed problems using Kerberos as the basis for web service authentication. When they do use web services, REST is preferred over SOAP.
+In 2003, Stanford University redesigned its RPC middleware layer. At that time it was decided not to use web services because they wanted to avoid having to deploy an HTTP stack on a large number of systems and partly because initial experiments demonstrated problems using Kerberos as the basis for web service authentication. Consequently, Stanford decided to design their own RPC layer called "remctl".  In this system, endpoints (servers and clients) authenticate themselves using GSS-API. A core design requirement was that Kerberos must be used for authentication because the cost of managing large numbers of username and passwords (or client certificates) was judged to be too high. Standford has developed multiple implementations of its system (using different application environments/languages currently in use there). Although the project is considered a resounding success there is increasing interest in the use of web services, typically to integrate with vendor solutions; where they do use web services, REST is preferred over SOAP.
-===Stockholm University===
+====Stockholm University====
 Stockholm University deploys a smaller (compared to Stanford) middleware infrastructure, implemented using SOAP-based web services. HTTPS is used as message transport for almost all web services. Server-side authentication is based on X.509 certificates using commercial PKIs. Client-side authentication is done using Negotiate.  Credentials transport is sometimes done using GSS-API credentials delegation over Negotiate and in some cases using s4u2self (aka constrained delegation). Web services are often cross-platform (eg. clients and servers run on different application environments) but servers are mostly written using .NET or J2EE. Stockholm University also uses [http://www.pubcookie.org PubCookie] as an enterprise SSO which is sometimes used to delegate Kerberos credentials to browser-facing web applications.
-===Lessons===
+====Conclusions====
-* There is a clear need for interoperability and cross-platform support for
+There is a clear need for interoperability and cross-platform support for Negotiate and credentials delegation and service deployment should be lightweight. Identity lifecycle management for services is an important consideration, which is often overlooked in the early stages of web service deployments. A Kerberos-based authentication mechanism for REST-based web services is also urgently needed.
-** Negotiate/SPNEGO
-** Credentials delegation/n-Tier
-* Service deployment should be light-weight
-* Identity lifecycle management for services is important
-* A Kerberos-based authentication mechanism for RESTful web services is urgently needed
 ==Security Technologies and Opportunities==
-The security technologies relevant to the HTTP-based Web can be divided into four overall categories: ''transport'', ''application'', ''message'' and ''composite''. This section discusses these technologies, how they compare and contrast with Kerberos, and presents potential opportunities for complementing these technologies with Kerberos.
+The security technologies that are relevant to the Web can be divided into four overall categories: ''transport'', ''application'', ''message'' and ''composite''. This section discusses these technologies, how they compare and contrast with Kerberos, and presents potential opportunities for complementing these technologies with Kerberos.
-Before starting this discussion, however, this section will briefly discuss the properties of Kerberos that are likely to be valuable within the Web context.
+It is not, however, unreasonable to ask what value Kerberos might bring to an already crowded and complex landscape. However, as described in [http://www.kerberos.org/software/rolekerberos.pdf The Role of Kerberos In Modern Information Systems], Kerberos possesses a number of properties, sometimes unique, that might contribute towards a more satisfactory Web authentication architecture.
-===Kerberos===
+===Web-Specific Security Technology Requirements===
-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 [http://en.wikipedia.org/wiki/Active_directory Active Directory].
+Therefore, this section will initially discuss the general properties that security technologies employed in the Web context ought to satisfy, and highlight where Kerberos may be able to contribute.
-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.
+Note that this is not an exhaustive set of overall security requirements, nor is it an overall security analysis.
-It is not, however, unreasonable to ask what value Kerberos might bring to an already crowded and complex landscape. However, as described in [http://www.kerberos.org/software/rolekerberos.pdf The Role of Kerberos In Modern Information Systems], Kerberos possesses a number of interesting and frequently unique technical properties that might contribute towards a more satisfactory Web authentication architecture; some of these properties are enumerated below:
 ====Authentication Method Independence====
-The method used to authenticate the user is independent of the mechanism that is used to subsequently to prove the user's identity to a service. This independence allows deployers of Kerberos to implement any user authentication method (supported by their Kerberos client and authentication server) that satisfies their local policy without modifying the services that those users subsequently attempt to access.
+It is often desirable to make the method of end user authentication independent of the mechanism that is used to subsequently to prove the user's identity to a service, particularly within federated environments. This independence allows identity providers to implement any user authentication method that satisfies the policies of the service providers, without those services needing to support the authentication method itself.
+While Kerberos deployments commonly only use shared secret authentication, the protocol does support other methods of authentication.
 ====Mutual Authentication====
-Kerberos provides mutual authentication of peers; this allows each peer to establish that the other peer is authorized to wield its asserted identifier. Mutual authentication is an essential part of building trust between users and systems, and the lack of mutual authentication in many Web authentication dialogues is the root causes of many security and privacy violations on the Web, such as phishing.
+Mutual authentication describes a situation where both parties of a communication obtain attestation as to the identity of the other party, ideally upon initial authentication and effectively simultaneously. Mutual authentication is an essential part of building trust between users and systems, and the lack of mutual authentication in many Web authentication dialogues is the root causes of many security and privacy violations on the Web, such as phishing.
-====Authorization Data====
+Kerberos provides mutual authentication as a normal feature of its protocol operation. In other security technologies, for example TLS, authentication of both parties is optional -- typically the server is authenticated to the client, and not the other direction.
-Kerberos service tickets can be embellished with authorization data describing the privileges accorded to the user. This facility is used extensively by Microsoft's Kerberos implementation to assert a user's authorizations within a data structure called the Privilege Attribute Certificate (PAC).
+====Authorization====
-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 an intra-Enterprise or Federated SSO system, 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.
+Authentication is normally a necessary criterion for satisfying many typical service providers' policies, but is rarely sufficient in isolation from authorization. For example, service providers commonly require evidence that an authenticated user has been accorded a set of privileges necessary to satisfy the service provider's security policy.
-Experience with Active Directory in large-scale deployments, where the PAC can often grow to ~20k, indicates that the use of Kerberos can significantly degrade a Web application's performance, 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.
+Kerberos service tickets can be embellished with authorization data describing the privileges accorded to the user. This facility is used extensively by Microsoft's Kerberos implementation to assert a user's authorizations within a data structure called the Privilege Attribute Certificate (PAC).
 ====Credentials Delegation====
-Kerberos provides the ability to forward tickets; that is, 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 service is a simple traditional host-based service (for example, ssh or telnet) the delegation process is relatively uncomplicated. This changes dramatically with the advent of web-based applications which need access to user credentials in order to authenticate to kerberized backend services; this is sometimes referred to as "n-tier". The classic example is the web front-end to a kerberized IMAP server. As long as the authentication mechanism for the web application is basic access authentication or form-based authentication (so that 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.
 It is useful to distinguish between two different scenarios that delegation can be used for: ''Enterprise'' and ''User driven''.
@@ Line 354: / Line 351: @@
 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 delegation in which a user is asked to provide authorization every time a service needs to be able to access another service with the rights of that user. A typical example is a social networking site requiring access to the user's email service's address book. The OAuth protocol (discussed below) supports this type of case-by-case delegation. Although the Kerberos V5 specification has allowances that would permit implementations to craft such "user driven" behavior, such behavior is not typically implemented and/or presented to users.
-However, credentials delegation in Kerberos <!-- , given its lack of support for user-driven credentials delegation and the gaps in the model that does exist, --> 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.
+Kerberos provides the ability to forward tickets; that is, 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 service is a simple traditional host-based service (for example, ssh or telnet) the delegation process is relatively uncomplicated. This changes dramatically with the advent of web-based applications which need access to user credentials in order to authenticate to kerberized backend services; this is sometimes referred to as "n-tier". The classic example is the web front-end to a kerberized IMAP server. As long as the authentication mechanism for the web application is basic access authentication or form-based authentication (so that 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.
-<!-- There is no correspondence to this model in Kerberos today. -->
+However, credentials delegation in Kerberos <!-- , given its lack of support for user-driven credentials delegation and the gaps in the model that does exist, --> 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.<!-- There is no correspondence to this model in Kerberos today. -->
+====Security Token Size====
+The "chatty" nature of some web interactions, and the necessity of each individual HTTP request being authenticated, implies that the security token size will likely be an important consideration.
+It is worth noting that the inclusion of authorization information in the Kerberos protocol can have 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 an intra-Enterprise or Federated SSO system, 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.
+Experience with Active Directory in large-scale deployments, where the PAC can often grow to ~20k, indicates that the use of Kerberos can significantly degrade a Web application's performance, 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 hundreds of connections to the server. Microsoft reports customer feedback to this effect.
+The same would likely also be the case for any other "large" chuck of information attached to service tickets, and/or the HTTP requests themselves.
+====User Interaction====
+Some security technologies, including Kerberos, are designed with the notion of signing the user on once; subsequent authentication interactions with participating entities (such as other service providers) occurs in manner that is transparent to the end user.
+However, in some contexts -- especially those in which principal attributes beyond baseline principal name and secret are conveyed -- it may be necessary for there to be some interaction with the end user, at least whenever the user agent is being compelled to convey more information beyond some configurable baseline minimum, in order to prevent violations of the end user privacy.
+This is one of the features of [[Information Card]]s' "Identity Selector" user agent, and the underlying [http://www.oasis-open.org/committees/download.php/29511/Identity_Selector_Interoperability_Profile_V1.5.pdf "Identity Selector Interoperability Profile"] protocol.
 ===Transport security===
@@ Line 363: / Line 381: @@
 Kerberos-based alternatives (existing and proposed) for securing transports include:
-* Kerberos with IPSec
-** Some deployments apparently use Kerberos in concert with IPsec. We do not have good data on how well this works, but there are obvious issues with NAT boxes and firewalls in the path, as well as homogeneous environments.
 * Kerberos with TLS
 ** A specification describing a Kerberos-based cipher suite for TLS exists ([http://www.ietf.org/rfc/rfc2712.txt RFC2712]), and has seen at least two implementations ([http://www.openssl.org OpenSSL], [http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/part2.html JGSS]), but is widely regarded as flawed [need citation].
 ** A recently-expired [http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 draft] describes extensions to [http://tools.ietf.org/html/rfc4279 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 [http://www.ietf.org/mail-archive/web/tls/current/msg01887.html has argued] that user principal authentication is an application-level concern, and so this work appears to have stalled.
+** University of Michigan [http://www.citi.umich.edu/ CITI] has produced a suite of middleware leveraging Kerberos for the provision of a lightweight PKI known as: [http://www.citi.umich.edu/projects/kerb_pki/ Kerberos-leveraged PKI (K-PKI)], and occasionally identified by one of its components, [http://www.kx509.org/ KX.509]. The protocols do not appear to be officially standardized as yet. They are described in this CITI Technical Report: [http://www.citi.umich.edu/techreports/reports/citi-tr-01-5.pdf ''Kerberized Credential Translation: A Solution to Web Access Control''].  The [http://lionshare.psu.edu/ LionShare] project at Penn State produced a similar but more general service called [http://lionshare.psu.edu/support/documentation/developers/sasl-ca-deployment-guide SASL-CA] that supports Kerberos and other authentication methods.
+* Kerberos with IPSec
+** Some deployments apparently use Kerberos in concert with IPsec. We do not have good data on how well this works, but there are obvious issues with NAT boxes and firewalls in the path, as well as heterogeneous environments.
 ====Opportunities====
-'''Work towards progression of draft-santesson-tls-gssapi-xx, perhaps outside of the TLS working group'''
+'''Specify the use of Kerberos with TLS'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 382: / Line 401: @@
 !Stakeholders
 |-
-|Ox
+|O1
-|U1, U2, E1, E3, E4,
+|U1, U2, S1, E1, E3, E4.
 |High
 |High
 |High
-|TLS, Kerberos, GSS-API expertise
+|TLS, Kerberos, GSS-API.
 |IETF Kerberos and TLS WGs.
 |}
-:The use of Kerberos and GSS-API at the transport layer would avoid the problems inherent in using these technologies at the application layer within HTTP (see the discussion on Negotiate for more information), thereby allowing general protection of REST-based services. The same technique could also be used for the other styles of Web services (RPC and Message), thereby providing a common approach to securing Web services.
+:The ability to use Kerberos via GSS-API as a CipherSuite option in Transport Layer Security (TLS) would avoid the problems inherent in using Kerberos at the application layer within HTTP (see the discussion on Negotiate for more information), thereby allowing general protection of HTTP-based services including REST. The same technique could also be used for the other styles of Web services (RPC and Message), thereby providing a common approach to securing Web services.
+'''Investigate Leveraging and Standardizing K-PKI'''
+{|border=1|
+|- bgcolor=#CDCDCD
+!Code
+!Contributes towards addressing requirement(s)
+!Effort
+!Risk
+!Reward
+!Skills
+!Stakeholders
+|-
+|O1a
+|U1, U2, S1, E1, E3, E4.
+|Medium
+|Medium
+|High
+|TLS, Kerberos, GSS-API, KX.509 et al.
+|IETF Kerberos and TLS WGs, NSF NMI, CITI.
+|}
+:Short-lived Kerberos-leveraged key pairs and certificates could act as a key link between PKI-based transport security and Kerberos-based infrastructure.
 ===Application security===
@@ Line 398: / Line 417: @@
 ====Negotiate====
-''Negotiate'' is the collective name of a loosely defined set of HTTP authentication mechanisms that provide a simple 2-way [http://en.wikipedia.org/wiki/GSS-API 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 Kerberos 5 GSS-API mechanism (RFC 4121) instead. To add to the confusion, the term SPNEGO is sometimes said to denote both the GSS-API mechanism and the HTTP authentication mechanism.
+''Negotiate'' is the collective name of a loosely defined set of HTTP authentication mechanisms that provide a simple 2-way [http://en.wikipedia.org/wiki/GSS-API GSS-API] handshake with the HTTP server. The most commonly deployed variant, "HTTP Negotiate Authentication Scheme" defined in RFC 4559, ''SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows'', uses the SPNEGO GSS-API mechanism (RFC 4178). Other implementations use the Kerberos 5 GSS-API mechanism (RFC 4121) instead. To add to the confusion, the term SPNEGO is sometimes said to denote both the GSS-API mechanism and the HTTP authentication mechanism.
-It is worth noting that Negotiate authentication does not protect the HTTP request because it is 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 (this is the case with all other authentication techniques that are conveyed within HTTP message headers, including Basic and Digest).
+It is worth noting that Negotiate authentication does not protect the HTTP request because it is 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 (this is the case with all other authentication techniques that are conveyed within HTTP message headers, including Basic and Digest), which implies use of transport layer security mechanisms, e.g. TLS, in conjunction with 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.
+Negotiate is observed to suffer from a lack of mutual authentication and effective support for multiple-roundtrip GSS-API mechanisms in a "real world" Web filled with "TLS concentrators" and HTTP proxies. 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.
 =====Opportunities=====
@@ Line 409: / Line 428: @@
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 417: / Line 437: @@
 !Stakeholders
 |-
-|O1
+|O2
-|U1, U2.
+|U1, U2, S1, S2, E1, E3, E4.
 |Low
 |Low
 |Medium
-|Kerberos and GSS-API expertise
+|Kerberos, GSS-API.
 |IETF Kerberos WG, Microsoft, other implementors of Negotiate.
 |}
-Description:
 :Investigate the proposed modifications to Negotiate to perform state management.
 ====Information Card====
-''Information Card'' is an identity technology based on the notion of a smart client, called the ''identity selector'', that resides on the end-users device. Under the control of a user, the identity selector can interact with a service provider, and also optionally an identity provider, to perform application sign-on and delivery of user information to the service provider.
+''Information Card'' is an identity technology based on the notion of a smart client, called the ''identity selector'', that resides on the end user's device. Under the control of a user, the identity selector can interact with a service provider, and also optionally an identity provider, to perform application sign-on and delivery of user information to the service provider.
 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 Identity Provider, and requires authentication to that identity provider when used. Alternatively a card can be "self-issued", meaning that it is generated within the identity selector itself, and uses a keypair managed by the identity selector to authenticate to the service provider.
@@ Line 437: / Line 457: @@
 These interactions use the WS-Trust protocol, part of the WS-* suite of specifications.  WS-Trust is intended to be a "meta" authentication protocol that can, in theory, permit a security token to be delivered to the service provider in whatever format it requires, independent of the method the client uses to authenticate to the identity provider.
-Although 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 identity selector implementation is called CardSpace; because it is the best known implementation, many people incorrectly refer to the whole technology using this name.  The Information Card concept was originally developed by Kim Cameron of Microsoft as part of the "Identity Metasystem" concept, and the technology is now being standardized in an OASIS technical committee called the Identity Metasystem Interoperability TC (http://www.oasis-open.org/committees/imi/).
+Although 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 identity selector implementation is called CardSpace; because it is the best known implementation, many people incorrectly refer to the whole technology using this name.  The Information Card concept was originally developed by Kim Cameron of Microsoft as part of a comprehensive design called the "Identity Metasystem."  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 identity providers (in the case of managed cards); Kerberos is one of these methods.  The other methods include X.509 certificates, username and password, and the self-issued card (which is technically a SAML token).
@@ Line 446: / Line 466: @@
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 454: / Line 475: @@
 !Stakeholders
 |-
-|O2
+|O3
 |U1, U2.
 |Low
 |Low
 |Medium
-|Kerberos, WS-Trust and InfoCard expertise.
+|Kerberos, WS-Trust, Information Card.
-|Microsoft, other implementors of Infocard.
+|Enterprise deployers.
 |}
-:The Identity Selector can, in principle, authenticate to an identity provider using Kerberos using the ''WS-Security Kerberos Token Profile'' bound to WS-Trust. An identity provider supporting Kerberos authentication would be an application server from the Kerberos point of view. However, none of the existing Information Card identity provider implementations supports Kerberos authentication, and so this presents an opportunity for improvement. Microsoft's identity provider (which probably won't be available until 2009) will support all four defined methods, including Kerberos.
+:In a managed-card scenario the Identity Selector can authenticate to an identity provider using Kerberos, via the ''WS-Security Kerberos Token Profile'' bound to WS-Trust. An identity provider supporting Kerberos authentication would be an application server from the Kerberos point of view. However, none of the existing Information Card identity provider implementations supports Kerberos authentication, and so this presents an opportunity for improvement. Microsoft's identity provider (which probably won't be available until 2009) will support all four defined methods, including Kerberos.
@@ Line 469: / Line 490: @@
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 477: / Line 499: @@
 !Stakeholders
 |-
-|O3
+|O4
-|U1, U2.
+|U1, U2, S1, S2, F3.
 |Low
 |Low
 |Medium
-|Kerberos, WS-Trust and InfoCard expertise.
+|Kerberos, WS-Trust, Information Card.
-|Microsoft, other implementors of Infocard.
+|Enterprise deployers, Kerberos community.
 |}
 :WS-Trust operates by delivering security tokens to service providers to authenticate clients. WS-Trust claims to be token agnostic -- meaning it can carry anything -- but for a token to be used its nature and processing must be specified and implemented by both the issuer and consumer of the token.
-:JH: I don't understand the following para
+:As mentioned previously, 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, which presumably would be based on a KRB_AP_REQ, would be generated by the IdP, carried by WS-Trust from the IdP via the user's Identity Selector to the relying party, where, after removing the WS-Trust wrapper, it could be 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 Kerberos tokens in WS-Trust as described here, hence there may be an opportunity for producing an interoperable implementation.
-:As mentioned previously, Information Card also 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.
@@ Line 496: / Line 516: @@
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 504: / Line 525: @@
 !Stakeholders
 |-
-|O3
+|O5
-|U1, U2.
+|U1, U2, S1, S2, F3.
 |Medium
 |Medium
 |High
-|InfoCard and Kerberos expertise.
+|Information Card, Kerberos.
-|Microsoft, other implementors of Infocard.
+|Enterprises, end users, application protocol designers.
 |}
@@ Line 527: / Line 548: @@
 =====Opportunities=====
-'''NAME REQUIRED'''
+'''OAuth augmented with SAML or Kerberos'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 538: / Line 560: @@
 !Stakeholders
 |-
-|Ox
+|O6
-|U1,U2,E3,S1
+|U1,U2,E3,E6,S1
+|Medium
 |High
 |High
-|High
+|Kerberos, SAM, OAuth.
-|Kerberos, SAML and OAuth expertise.
 |End Users, Enterprise, Service Providers, OAuth community, SAML community
 |}
@@ Line 553: / Line 574: @@
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 561: / Line 583: @@
 !Stakeholders
 |-
-|Ox
+|O7
 |U1,U2,E1,E2,E3,S1
-|High
+|Medium
 |High
 |High
@@ Line 585: / Line 607: @@
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 593: / Line 616: @@
 !Stakeholders
 |-
-|Ox
+|O8
-|U1,U2,E2,E3
+|U1,U2,E3
 |Low
 |Medium
 |Medium
-|Kerberos and OpenID expertise.
+|Kerberos and OpenID.
-|End Users, Enterprise
+|End Users, Enterprise, OpenID community.
 |}
@@ Line 608: / Line 631: @@
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 616: / Line 640: @@
 !Stakeholders
 |-
-|Ox
+|O9
-|E1,E2,E3
+|E1,E2,E3,F4
 |Medium
 |Medium
 |High
-|Kerberos and OpenID expertise.
+|Kerberos and OpenID.
-|Enterprise, Service Providers
+|Enterprise, Service Providers, OpenID community.
 |}
@@ Line 629: / Line 653: @@
 ===Message security===
-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).
+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, XMPP, etc), transit intermediate systems, or be retained on endpoint systems, while retaining intact their originating security context (modulo any allowances for message modification in-transit). This is in contrast to security context derived from the transport layer which typically reflects only the immediately communicating endpoints, that is it is "hop-by-hop", and the originating security context is lost if a message transits more than one hop, or tier.
-HTTP is the most common transport in message-orientated architectures. Transport security and server-side authentication is usually provided using TLS and X.509 certificates often using username and password as client-side authentication.
+Thus message security provides discernible endpoint-to-endpoint benefits in the face of multiple hops and/or differing transports.
-Other transports, such as [http://www.xmpp.org 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.
 =====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.
+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. 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.
-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.
+SOAP method calls are either secured at the transport or message layer or both. Even though various web services specifications and stacks specify and promote using WS-Security to secure SOAP messages, it is common to use transport-layer security especially in the cross-domain cases. In the latter cases 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 (HTTP/TLS) to be used in combination with a username and clear-text password.
 The reasons for using Kerberos may be any of:
@@ Line 651: / Line 671: @@
 There are therefore two ways to authenticate SOAP using Kerberos (if we ignore the possibility of using Kerberos with IPSEC for now):
-* by securing the transport.
+* by securing the transport (this was discussed in a previous section of transport security).
 * by securing the SOAP messages.
@@ Line 658: / Line 678: @@
 <!-- [https://spaces.internet2.edu/display/kerweb/WS-Security+Kerberos+Token+Profile] <font size="1">(reference material)</font>  -->
-The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token in conjunction with the WS-Security specification, the latter specifying a particular approach to obtaining SOAP message security. Although it is a piece of the broad WS-* composite web services specification suite, it may be employed in other contexts, e.g. the Liberty ID-WSF web services framework employs it.
+The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token in conjunction with the WS-Security specification, the latter specifying a particular approach to obtaining SOAP message security. Although it is a piece of the broad WS-* composite web services specification suite, it may be employed in other contexts, for example, the Liberty ID-WSF web services framework also employs it.
 The Kerberos message is attached to the SOAP message using the <wsse:BinarySecurityToken> element, however the acquisition of the Kerberos service ticket contained in the KRB-AP-REQ message is out-of-scope. Six different types of KRB-AP-REQ message 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).
 =====Opportunities=====
-'''Shepherding a revision to the WS-Security Kerberos Token Profile specification such that mutual authentication and channel bindings are supported'''
+'''Update WS-Security Kerberos Token Profile specification'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 677: / Line 696: @@
 !Stakeholders
 |-
-|Ox
+|O10
-|U1,U2,E1,E2,E3
+|U1,U2,E1,E2,E3,E6,F1.
 |High
 |High
@@ Line 685: / Line 704: @@
 |End Users, Enterprise
 |}
+: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).
 ===Composite Security===
 This category refers to technologies where various aspects of the other categories are employed in various fashions. Such technologies are often defined in extensive, full-featured specification suites. Some technologies require further profiling in order to yield an implementable system that will address real-world use cases. Others feature concrete profiles as a part of the specification suite.
 ====OASIS Security Assertion Mark-up Language (SAML)====
@@ Line 702: / Line 722: @@
 * ''protocols'', that are primarily for requesting assertions about subjects.
 * ''bindings'' defining how protocols are bound to certain transports (such as HTTP or SOAP).
-* ''profiles'' constraining and concretely defining the use of assertions, protocols and bindings to realize specific use-cases (such as the "Web SSO Profile").
+* ''profiles'' constraining and concretely defining 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.
+* ''federation metadata'', a format for expressing information (primarily configuration data, such as a public key) about SAML endpoints for consumption by partner endpoints.
-Although many existing SAML profiles focus primarily on generating, obtaining, and conveying SAML assesrtions in order to federate identities in different security domains for Web SSO applications or web services, the architecture of SAML allows discrete functional elements to be re-used in other contexts, allowing a broad range of potential applications. In other words, SAML itself is an abstract framework (see: [http://www.oasis-open.org/committees/download.php/21265/draft-hodges-HowToLearnSAML-01.html How to Study and Learn SAML]). For example, the SAML assertion is 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). -->
+Although many existing SAML profiles focus primarily on generating, obtaining, and conveying SAML assesrtions in order to federate identities in different security domains for Web SSO applications or web services, the architecture of SAML allows discrete functional elements to be re-used in other contexts, allowing a broad range of potential applications. In other words, SAML itself is an abstract framework (see: [http://www.oasis-open.org/committees/download.php/21265/draft-hodges-HowToLearnSAML-01.html How to Study and Learn SAML]). For example, the SAML assertion is 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.
@@ Line 711: / Line 731: @@
 =====Opportunities=====
-There are several ways in which SAML may be employed in concert with Kerberos:
+'''Leverage SAML metadata to enable large-scale Kerberos cross-realm communities'''
-'''Leverage SAML metadata to more easily enable Kerberos cross-realm operations'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 724: / Line 743: @@
 !Stakeholders
 |-
-|Ox
+|O11
-|U1,U2,E2,E3
+|U1,U2,E2,E3,F4
 |Low
 |High
 |Medium
 |Kerberos, SAML
-|End users, Enterprise
+|End users, Enterprise, Service providers.
 |}
-:[http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf SAML Metadata] features sharable site descriptions that can be aggregated, annotated, signed, and distributed.  There is no similar capability with Kerberos cross-realm technology today. Using a technique such as this could ease deployment effort for cross-realm relationships. Note that [http://en.wikipedia.org/wiki/XRDS XRDS] is a similar technology that may also be employed.
+:[http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf SAML Metadata] is a key enabling technology for large-scale multi-party SAML federations (e.g. the [http://incommonfederation.org InCommon Federation] or the [http://www.ukfederation.org.uk UK Access Management Federation]).  Via metadata trusted site configurations can be aggregated, annotated, signed, and distributed.  There is no similar capability with Kerberos cross-realm technology today, which may be a barrier to growing Kerberos-based trust communities.  The SAML metadata specification could be extended to support describing Kerberos entities.  Alternatively, [http://en.wikipedia.org/wiki/XRDS XRDS] is a similar technology that is beginning to be used in OpenID, XRI, OAuth, and other related identity systems.  It could also be profiled to describe Kerberos entities.
-'''The SAML Identity Provider (IdP) uses Kerberos to validate usernames and passwords supplied by users on webpage forms'''
+'''Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 747: / Line 767: @@
 !Stakeholders
 |-
-|Ox
+|O12
 |U1,U2,E2,E3
 |Low
 |Low
 |Medium
-|Kerberos, SAML
+|Kerberos, SAML.
-|End users, Enterprise
+|End users, Enterprise.
 |}
-: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.
+:There are a number of ways a SAML identity provider can use Kerberos today to authenticate end users, such as validating user-supplied Kerberos credentials or Negotiate. The main benefit offered by these approaches is that they allow end users to access resources protected by both SAML and Kerberos, offering end users greater convenience. These methods are often achievable with little or no modifications to software, but nonetheless are not widely used. This activity would aim to promote the use of these methods.
-'''The IdP uses Kerberos authentication at the HTTP layer - e.g. Negotiate or NTLM'''
+'''Specify a SAML profile supporting the generation of SAML assertions containing Kerberos tickets ("Kerberos-in-SAML")'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 770: / Line 791: @@
 !Stakeholders
 |-
-|Ox
+|O13
-|U1,U2,E1,E2,E3
+|U1,U2,E1,E2,E3,E6,F1,F2.
-|Low
 |Medium
-|Medium
-|Kerberos, SAML
-|End users, Enterprise
-|}
-: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. However, Negotiate authentication is disabled by default in all browsers, and browsers must typically be configured to authenticate against named hosts. Negotiate is also often not implemented in the browsers installed on mobile devices.
-'''The IdP issues SAML assertions containing Kerberos tickets as an attribute'''
-{|border=1|
-!Code
-!Contributes towards addressing requirement(s)
-!Effort
-!Risk
-!Reward
-!Skills
-!Stakeholders
-|-
-|Ox
-|U1,U2,E1,E2,E3,E6
-|Low
 |High
-|Medium
+|High
 |Kerberos, SAML
-|End users, Enterprise
+|End users, Enterprise, Service providers.
 |}
-:It would allow a SAML Relying Party to acquire a Kerberos ticket that it could subsequently use 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.
+:This would allow a SAML service provider to acquire a Kerberos ticket as part of a SAML transaction. This could be used by the service provider to authenticate, as another principal, against a Kerberos protected resource, thereby providing support for n-tier web-based use cases (such as the webmail use case). This would offer greater convenience to users and possibly reduce the abuse of user credentials that might otherwise be provided to applications with delegatable credentials.
-'''The KDC includes a SAML assertion and/or authentication response message encapsulated in KDC-issued authorization data'''
+'''Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data ("SAML-in-Kerberos")'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 815: / Line 815: @@
 !Stakeholders
 |-
-|Ox
+|O14
-|U1,U2,U4,E1,E2,E3,E6
+|U1,U2,U4,E1,E2,E3,E6,F1,F2,F3.
 |Medium
 |High
 |High
-|Kerberos, SAML
+|Kerberos, SAML.
-|End users, Enterprise
+|End users, Enterprise, Service providers.
 |}
-: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.
+:This would allow a Kerberos service to acquire a SAML assertion within a Kerberos ticket. This could be used to complement Kerberos-based authentication and/or provide richer authorization.
-'''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'''
+'''Specify a SAML profile that allows automatic discovery of the end user's identity provider based on the Kerberos-realm in the GSS-API authentication request'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 838: / Line 839: @@
 !Stakeholders
 |-
-|Ox
+|O15
-|U1,U2,U4,E1,E2,E3
+|U1,U2,U4,F3.
 |Low
 |High
 |Medium
-|Kerberos, SAML
+|Kerberos, SAML.
-|End users, Service Providers, Enterprise
+|End users, Service Providers, Enterprise.
 |}
-: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, accessibility, and phishability. This is achievable with little modification to the SAML SP. It has already been implemented on [http://www.switch.ch/aai/support/tools/wayf.html SWITCH's "Where Are You From" service] (but not used in their production federation).
+:This would reduce or eliminate the use of GUI-based IdP discovery (the commonest form of IdP discovery), which scales poorly and introduces considerations such as localization, accessibility, and phishing, significantly improving the end user experience.
-'''A GSSAPI peer implementing the proposed GSSAPI naming extensions receives a SAML attribute assertion as part of a GSSAPI protocol exchange'''
+'''Include a SAML attribute assertion within a GSSAPI protocol exchange'''
 {|border=1|
+|- bgcolor=#CDCDCD
 !Code
 !Contributes towards addressing requirement(s)
@@ Line 861: / Line 863: @@
 !Stakeholders
 |-
-|Ox
+|O16
-|U1,U2,U4,E1,E2,E3
+|U1,U2,U4,E1,E2,E3,F1,F2,F3.
 |Low
 |High
 |Medium
 |Kerberos, SAML, GSS-API
-|End users, Service Providers, Enterprise
+|End users, Service Providers, Enterprise.
 |}
@@ Line 874: / Line 876: @@
 ====Liberty Alliance Identity Web Services Framework====
 <!-- [https://spaces.internet2.edu/display/kerweb/ID-WSF] <font size="1">(reference material)</font> -->
 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.
 ====The WS-* suite====
@@ Line 889: / Line 889: @@
 * 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.
+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.
 =====Opportunities=====
 The most straightforward opportunity is to enhance the WS-Security Kerberos Token Profile as noted above. Such enhancements ought to subsequently carry throughout the WS-* suite by virtue of many of the suite's other specifications directly depending upon WS-Security and its token profiles.
-==Web-Specific Security Technology Requirements==
-This section presents overall requirements that security technologies employed in the HTTP-based Web context ought to satisfy. Note that this is not an exhaustive set of overall security requirements, nor is it an overall security analysis.
-===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 of requests to the server (not infrequently on the order of tens O(10)). 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 and 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 Card]]s' "Identity Selector" user agent, and the underlying [http://www.oasis-open.org/committees/download.php/29511/Identity_Selector_Interoperability_Profile_V1.5.pdf "Identity Selector Interoperability Profile"] protocol.
-===Mutual Authentication===
-Mutual authentication describes a situation where both parties of a communication obtain attestation as to the identity of the other party, ideally upon initial authentication and effectively simultaneously. Kerberos provides mutual authentication as a normal feature of its protocol operation. In other security technologies, for example TLS, authentication of both parties is optional -- typically the server is authenticated to the client, and not the other direction.
-Various aspects of addressing phishing, for example, hinge on employing mutual authentication, hence its desirability and applicability.
 ==Implementation and Deployment Technologies==
@@ Line 945: / Line 918: @@
 ===Application Environments & Libraries===
+This section touches briefly on Kerberos and Negotiate HTTP mechanism capabilities in a number of application development environments.  The number of potential environments of interest is large, and details of capabilities complex.  Future work should focus on those environments of most importance to the Kerberos community stakeholders.
 ====IIS====
@@ Line 956: / Line 930: @@
 ====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.
+The LPW::Authen::Negotiate module implements Negotiate using the [http://search.cpan.org/search?query=GSSAPI&mode=all 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.
+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====
@@ Line 967: / Line 941: @@
 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==
+==Analysis==
-[[Image:Kerberos-ArchAndProposedWorkItems-00.png|Figure 1]]
+The diagram below summarizes the opportunities previously proposed.
-* Back Channel (BC)
-*# Update the Kerberos Security Token Profile to support mutual authentication and channel bindings.
-*# Promote the implementation of the updated Kerberos Token Profile in common software frameworks (e.g. .NET, wss4j) and demonstrate interoperability.
-*# Update Kerberos cross-realm operation (in progress).
-*# Develop conventions or best-practices for integrating Kerberos into web-services governance solutions.
-* Front Channel (FC)
+[[Image:Krbandweb-opps 05-700x363.png|Figure 1]]
-*# Promote implementation and interoperability testing of Kerberos authentication for Information Card.
-*# Update Negotiate (in progress).
-*# Interoperability testing of Negotiate implementations.
-*# Investigate the role of Kerberos in OpenID.
-*# 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.
-*# Define a mechanism in Kerberos allowing TLS-like "session resumption" to reduce redundant KRB_AP messages exchanged within multiple connections to a single web application.
-* Front and Back Channel (FB)
-*# Specify credentials-delegation for SAML-based SSO.
-*# Investigate the role of Kerberos in OAuth.
-*# 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)
+We believe that, as a whole, the opportunities revealed through the back channel use cases are, in general, addressed more easily than those from the front channel use cases, in a technical sense. We also believe that satisfying the back channel use cases would yield greater benefits for relatively less effort. Many of these opportunities are shared with the front channel use cases; therefore, greater emphasis should be placed on them, even if they cannot be immediately realized within the front channel context because of other dependencies. Consequently, we recommend that the Kerberos Consortium focus primarily on the opportunities within this class of use cases. These opportunities, in suggested priority order, are:
-*# 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.
-*# Develop best-practices and boilerplate covering governance of Kerberos-based web services.
+* O10 - Update WS-Security Kerberos Token Profile specification
+* O11 - Leverage SAML metadata to enable large-scale Kerberos cross-realm communities
+* O13 - Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets
+* O14 - SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data
+* O2 - Update Negotiate
+* O1 - Specify the use of Kerberos with TLS
-===Activity breakdown===
+Opportunity O10 is likely to yield benefits immediately, unlike O11 which is essentially a common dependency for other longer-term opportunities whose requirements will become more apparent as those opportunities are taken forwards. We therefore recommend that O10 is given a higher priority.
-The table below provides a breakdown of the proposed activities.
+Four of these opportunities (O1, O2, O13, O14) are variations on the theme of improving or enhancing the transport of Kerberos and/or SAML tokens.
-{| border="1" cellspacing="0" cellpadding="5" align="center"
+Opportunities O13 and O14 are superficially similar, in that they share SAML, Kerberos and a goal (authentication) in common, but are quite different architecturally. In particular O13 is, in essence, somewhat of an elaboration of the conventional SAML Web SSO Profiles, whereas O14 could be also used in other non-Web contexts. In this sense (of being limited to HTTP-only transactions) O1 is similar in applicability to O13. In light of this, and also the politics that is likely to impede progress on O1, we recommend that this opportunity is given a lower priority. Both O13 and O14 are likely to depend on, or be significantly enhanced by, O11, and are subsequently given lower priorities.
-! Activity
-! Impact
+Another interesting distinction to draw between these activities is the potential impact on the client. It is likely that neither O13 nor O14 would require changes to existing client Kerberos or browser implementations, whereas O1 and O2 would probably require updates to the client TLS provider and browser implementations respectively. The inertia exerted by legacy client systems, particularly in the consumer context, would impede the proliferation of implementations.
-! Effort
-! Risks
+The priority given to O2 probably depends on the importance given to the ability for a client to authenticate using Kerberos directly to a service provider rather than being used merely as evidence for some other type of authentication method, such as a SAML assertion. Given the widespread use of technologies such as SAML it would appear pragmatic to leverage these initially, particularly given the challenges presented by Kerberos cross-realm operation. While Negotiate has some flaws, these are generally manageable where it is used within a domain (for example, to authenticate against an Enterprise's identity provider). Consequently, we recommend that O2 is given a lower priority.
-! Stakeholders
-! Skill sets
+Strategically, the Kerberos Consortium needs to consider whether future work should emphasise Kerberos as a technology that complements existing Web authentication technologies ("Complementary Kerberos"), which could be realised more quickly but might be viewed as dilutory (O13, and to a lesser extent O14); or should this work emphasis strategies for authentication that are less tightly bound to other authentication technologies (O2), such as SAML, and the Web in general (O1), but that would require significant updates to clients perhaps incurring greater cost and delay ("King Kerberos").
+Some of the opportunities within the front channel use cases are reasonably straightforward (in a technical sense) and could deliver benefits relatively quickly:
+* O12 - Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider
+* O3 - Kerberos authentication from Identity Selector to identity provider
+* O8 - Negotiate authentication against OpenID identity provider
+We believe that opportunity O12 would be useful as a means of encouraging adoption of Kerberos for web authentication, raising awareness of the Kerberos Consortium's interest in this area, and "laying the foundations" for the more sophisticated opportunities discussed in this document. For example, MIT's [https://wikis.mit.edu/confluence/display/TOUCHSTONE/What+is+MIT+Touchstone Touchstone] system could provide a case-study that would be of considerable value to other organizations attempting to leverage Kerberos for web authentication. Opportunities O3 and O8 would usefully complement existing federated systems, and these might also contribute towards O12.
+Two other front channel opportunities exist that would yield significant benefits, but incur greater effort and time to realise owing to the necessary client updates. These are:
+* O5 - Identity Selector as the standard authentication user interface
+* O15 - Specify a SAML profile that allows automatic discovery of the end user's identity provider
+The primary benefits of these opportunities are that they would improve the user experience and reduce the exposure to phishing attacks. These opportunities are therefore somewhat duplicative in their goals, but technologically highly dissimilar. The most appropriate approach would probably become more apparent when the strategic question concerning "Complementary Kerberos" or "King Kerberos" is resolved. In the former case, O15 is probably more appropriate; in the later case, O5 is probably more appropriate.
+In summary, the table below provides two prioritized lists of the opportunities discussed to this point, depending on the strategic approach adopted by the Kerberos Consortium, and the relative risk and effort associated with which.
+{|border=1|
+|- bgcolor=#CDCDCD
+!Opportunity code
+!Opportunity name
+!"King Kerberos" pre-requisite
+!"Complementary Kerberos" pre-requisite
+!Effort
+!Risk
 |-
-|'''Front channel'''
+|10
-|-
+|Update WS-Security Kerberos Token Profile specification
-|BC1 (Update Kerberos Token Profile)
+|High (3)
-|Medium
+|High (3)
-|Low
+|High (3)
-|
+|High (3)
-|Microsoft, IBM.
-|WS-Security and Kerberos
 |-
-|BC2 (Promote Kerberos Token Profile)
+|11
-|Medium
+|Leverage SAML metadata to enable large-scale Kerberos cross-realm communities
-|Medium
+|High (3)
-|Adoption, given existing implementations of existing profile that may be perceived as 'good enough'.
+|High (3)
-|Microsoft, IBM, Open Source WS* implementation community
+|Low (1)
-|Evangalism
+|High (3)
 |-
-|BC3 (Update Kerberos cross-realm operation)
+|2
-|Medium
+|Update Negotiate
-|High
+|High (3)
-|
+|Low (1)
-|IETF Kerberos WG
+|Low (1)
-|Kerberos and PKIX
+|Low (1)
 |-
-|BC4 ( Kerberos / Web services governance best practices)
+|12
-|Medium
+|Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider
-|Low
+|Low (1)
-|
+|High (3)
-|Vendors of Web Services governance solutions
+|Low (1)
-|Web services governance solutions
+|Low (1)
 |-
-|'''Back channel'''
+|13
+|Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets
+|Low (1)
+|High (3)
+|Medium (2)
+|High (3)
 |-
-|FC1 (Promote Kerberos & Infocard)
+|14
-|High
+|SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data
-|Medium
+|High (3)
-|
+|Low (1)
-|Microsoft, other implementors of Infocard
+|Medium (2)
-|Kerberos & Infocard
+|High (3)
 |-
-|FC2 (Update Negotiate)
+|15
-|High
+|Specify a SAML profile that allows automatic discovery of the end user's identity provider
-|High
+|Low (1)
-|
+|Medium (2)
-|IETF Kerberos WG, Microsoft, other implementors of Negotiate
+|Low (1)
-|Kerberos
+|High (3)
 |-
-|FC3 (Negotiate interoperability testing)
+|1
-|Medium
+|Specify the use of Kerberos with TLS
-|Low
+|Medium (2)
-|
+|Low (1)
-|Implementors of Negotiate
+|High (3)
-|Kerberos & web technologies
+|High (3)
 |-
-|FC4 (Investigate role of Kerberos in OpenID)
+|3
-|Medium
+|Kerberos authentication from Identity Selector to identity provider
-|Low
+|Low (1)
-|
+|Medium (2)
-|OpenID community
+|Low (1)
-|Kerberos & OpenID
+|Low (1)
 |-
-|FC5 (SAML IdP discovery)
+|5
-|High
+|Identity Selector as the standard authentication user interface
-|High
+|Medium (2)
-|Diverse target adopter community may inhibit broad acceptance
+|Low (1)
-|OASIS SSTC, SAML implementors, large RPs.
+|Medium (2)
-|Kerberos and SAML
+|Medium (2)
 |-
-|'''Front and Back channel'''
+|8
+|Negotiate authentication against OpenID identity provider
+|Low (1)
+|Medium (2)
+|Low (1)
+|Medium (2)
 |-
-|FB1 (Kerberos credentials delegation & SAML)
+|colspan=2|Approximate overall relative effort
-|High
+|37
-|High
+|35
-|
-|OASIS SSTC
-|Kerberos & SAML
 |-
-|FB2 (Investigate role of Kerberos in OAuth)
+|colspan=2|Appropriate overall relative risk
-|Low
+|50
-|Medium
+|51
-|
-|OAuth community, large RPs.
-|Kerberos & OAuth
-|-
-|FB3 (KDC signing of SAML elements)
-|High
-|High
-|Complex
-|Kerberos implementors
-|Kerberos & SAML
-|-
-|'''Others'''
-|-
-|O1 (Document contemporary Kerberos/SAML uses)
-|High
-|Medium
-|
-|
-|Kerberos & SAML
-|-
-|O2 (Governance)
-|Medium
-|High
-|
-|Users of Kerberos & Web services
-|Kerberos, Regulatory & Statutory environment
 |}
-===Proposed stategy===
+The remaining opportunities are:
+* 01a - Investigate Leveraging and Standardizing K-PKI
+* O4 - Kerberos token delivery to the service provider
+* O6 - OAuth augmented with SAML or Kerberos
+* O7 - OAuth Kerberos-based trust bootstrap
+* O9 - OpenID leveraging Kerberos for trust bootstrap
+* O16 - Include a SAML attribute assertion within a GSS-API protocol exchange
+We are not at this time assigning priorities amongst these remaining opportunities.
+==Recommendations==
+On the basis of the analysis presented in the previous section, we conclude by presenting a set of recommendations.
+===Recommendation 1: Determine the overall strategic approach in consultation with relevant stakeholders===
+In our analysis, we presented two possible directions: "King Kerberos" and "Complementary Kerberos". The risks and effort associated with both courses are roughly equivalent, although we believe that the latter is likely to yield faster results given the opportunity to leverage existing Web authentication systems and minimize alterations to the client.
+These options are not, of course, mutually exclusive; it would be possible to develop a hybrid strategy that, for example, assumes a "Complementary Kerberos" direction initially to achieve some results sooner and transition towards a "King Kerberos" direction once this strategy's more complex dependencies are resolved. This is the recommendation of the authors although we accept that, given the complexity and number of variables involved, there are probably a number of other approaches that would be difficult to argue against.
+We recommend that the Kerberos Consortium continues this discussion with all the relevant stakeholders.
+===Recommendation 2: Initiate activities to address those opportunities whose applicability is independent of strategic direction===
+There are three opportunities whose applicability is largely independent of the strategic direction chosen; these are opportunities O10 ("Update WS-Security Kerberos Token Profile specification"), O11 ("Leverage SAML metadata to enable large-scale Kerberos cross-realm communities"), and O12 ("Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider").
+===Recommendation 3: Plan and prioritize the most critical subsequent activities===
+In our analysis, we presented two possible strategic directions. While recognising that other strategies probably exist, in this recommendation we provide a list of what the present authors consider to be the most urgent opportunities for each of these stategies.
+These activities should be planned in parallel to the development of the activities initiated previously to ensure that these key outputs form part of a cohesive architecture.
+* "King Kerberos"
+** O2: Update Negotiate.
+** O14: SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data.
+* "Complementary Kerberos"
+** O13: Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets.
+** O3: Kerberos authentication from Identity Selector to identity provider.
+===Recommendation 4: Develop an overall architecture===
+It will be necessary to develop an overall architecture that presents a conceptual model describing how the relevant components are coupled and work together.
-Short
+While certain elements of this architecture are relatively obvious (thus the recommended activities in recommendations 2 and 3), it is the authors' opinion that the space of acceptable and feasible architectures (given the requirements and constraints that we know about ''today'') is of significant volume and therefore difficult to make concrete without making grievous assumptions.
-Medium
+However, in the process of planning and implementing the activities recommended in recommendations 2 and 3, it is likely that new constraints (technical, political or otherwise) will present themselves. These will, most probably, significantly constrain the space of acceptable and feasible architectures and highlight gaps that might not be evident to the authors at the present time. If gaps are identified their impact should be analyzed and, if necessary, steps taken to remedy them.
-Long
+We therefore recommend that the Kerberos Consortium develops an overall architecture, and that this should proceed in parallel with the activities initiated in the previous recommendations.

Difference between revisions of "KrbWeb Outline of Work"

Latest revision as of 18:15, 29 October 2008

Contents

Introduction

Acknowledgments

Related Pages

Overview

A Short History of Web Identity & Services

The Primordial Identity Soup

Birth of Web Single Sign-On and Identity

Evolution Towards Federated Identity

From Identity Monopoly to Identity Metasystem

Emergence of Web Services

Web Services Stacks and Identity

Project Concordia

Summary

Stakeholder Requirements

Use Cases

Back channel

Intra Enterprise

Business-to-Business

Front channel

Business-to-employee

Business-to-customer

Front and Back Channel Composition

Credentials Delegation

Level-of-Assurance transport

Deployment Case Studies

Stanford University

Stockholm University

Conclusions

Security Technologies and Opportunities

Web-Specific Security Technology Requirements

Authentication Method Independence

Mutual Authentication

Authorization

Credentials Delegation

Enterprise Web SSO and Credentials Delegation

User Driven Credentials Delegation

Security Token Size

User Interaction

Transport security

Opportunities

Application security

Negotiate

Opportunities

Information Card

Opportunities

OAuth

Opportunities

OpenID

Opportunities

Message security

Security Strategies for Message-based architectures

WS-Security Kerberos Token Profile

Opportunities

Composite Security

OASIS Security Assertion Mark-up Language (SAML)

Opportunities

Liberty Alliance Identity Web Services Framework

The WS-* suite

Opportunities

Implementation and Deployment Technologies

Browsers

Safari

Mozilla/Firefox

Internet Explorer

Konqueror

Application Environments & Libraries

IIS

.NET

Apache

Perl

Ruby

Java

WSS4j

Analysis

Recommendations

Recommendation 1: Determine the overall strategic approach in consultation with relevant stakeholders

Recommendation 2: Initiate activities to address those opportunities whose applicability is independent of strategic direction