KrbWeb Outline of Work

This document is a draft concerning Kerberos and the Web.

Related Pages

"Backlog" Page

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

Overview

A Short History of Web Identity

For a system that was originally intended to facilitate collaboration between physicists, it is remarkable how ubiquitous Web technologies have become. It is no exaggeration to claim that the HTTP protocol defined in RFC 2616 is the de facto transport for applications operating between internetworked hosts. This is due, in part, to HTTP's success in meeting its authors' goal of defining a '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, were 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 ptotect these using SSL (and subsequently TLS). However, the user experience provided by browsers implementing these methods was poor (for example, the bland username and password dialogue) and so while these methods were deployed within the Enterprise (typically to protect Intranets and programmatic web services), they were largely ignored by the broader Web development community, where so-called Form-based authentication became dominant.

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

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

• Phishing of credentials
• Excessive numbers of credentials
• Inconsistent and complex user experience
• Privacy violations

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 (for example, attempts to leverage SASL) 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 Identity

The first serious effort to improve Web authentication 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 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 cancelled the contracts with the most significant consumers of Passport, including eBay and Monster.com.

In parallel with Passport, a working group within OASIS was established to define SAML, an open XML-based identity system derived from two earlier specifications, S2ML and AuthXML. The SAML specifications were quickly leveraged by the Liberty Alliance, a vendor 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 centralised identity system, federated identity is an approach in which the service (normally called the Service Provider, or SP) delegates responsibility of user authentication (and sometimes user authorisation) to a trusted third party (normally called an Identity Provider, or IdP) with which the user is affiliated. The relationship between one ore 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).

Federated Identity

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

SAML, and the Liberty Alliance specifications in particular, focus primarily on finding solutions for Enterprise and eCommerce use-cases where the number of parties within a federation is relatively small (typically just an IdP and SP). In the case of the Liberty Alliance framework, the federated identity technology was complemented by non-technological aspects, such as alternate models of governance for federations. While comprehensive, many within the Web development community viewed this approach to federated identity as unnecessarily complex for many, if not most, applications of identity - and not scaleable to the Internet community at large. More philosophically, there was also principled opposition to what many perceived as SAML's perceived leanings towards 'Enterprise-centric' identity, in which the user's identity is associated too strongly with the corporate entity issuing assertions on the user's behalf, than it is with the natural person represented by that identity.

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

Many argue that the claimed 'user-centric' properties of OpenID are a distraction, and that SAML can be used in equivalent ways that are no less 'user-centric'. While probably accurate, it is nonetheless indisputable that OpenID, being optimised for simplicity, can be easier to implement and deploy than SAML. For example, OpenID is not burdened by any notions of trust, whose subtleties add significantly to the SAML specification, implementation and deployment complexity.

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 not typically 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 seminal 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 nonetheless important in that it expounds the philosophical underpinnings of the federated identity architecture developed by Microsoft in the wake of Passport.

Identity and Web Services

Microsoft's identity architecture is not a self-contained system, unlike as SAML, but part of a broader and highly inter-dependent set of specifications concerning web services. These specifications, commonly collectively known as WS-*, do not originate (except in a very few instances) from any standards development organisations but have been proposed by a loose coalition of vendors that includes Microsoft and IBM.

The most interesting feature of the WS-* security architecture is that it does not differentiate between federation of identities and web services. That is, both SAML and ID-FF are generally constrained to scenarios in which the user (and in particular, the user's browser) is an active participant (for example, Web SSO). These specifications do not, therefore, provide security for web services that might need to interact in ways that are independent of any user interactions.

The Liberty Alliance addressed this requirement with ID-WSF (Web Services Framework) etc etc.

TODO: provide more background on ID-WSF

Kerberizing Web Identity & Services

The use of Kerberos as an authentication mechanism for web applications has a long history in certain communities, notably the higher education and research and large scale enterprise community where Kerberos has always had a very strong position. Extending Kerberos to cover 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 success of Active Directory. Today there is a body of experience relating to the use of kerberos for web and related technologies (eg web services, XML, identity federations, etc) which can be used to formulate a strategy for future work in this field.

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

User Stories

A user story is a statement describing a specific desire by a specific type of user in order to achieve a specific value. User stories often appear in agile development frameworks (eg SCRUM) and are used as a tool for evaluating the effectiveness of development activities. A user story often takes the form of a single sentence of the form "As (role) R, (user) U wants to achieve (value) V".

Notes

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

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

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

General: Users

Simplicity

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

Transparency

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

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

Flexibility

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

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

General: Service Providers

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 want to be able to manage and minimize the risks they assume when providing 
authenticated web-based sites/services. 

Financial Services

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

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

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

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

Federation

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

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.

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

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

Enterprise

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

Enterprise security officers want secure authentication for SOA.

Enterprise system integrators want interoperability between webservice implementations from 
major vandors.

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

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

Use Cases

The use-cases are divided between three categories

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

Back channel

Intra Enterprise

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

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

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

Business-to-Business

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

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

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

Front channel

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

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

Business-to-employee

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

Business-to-customer

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

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

Front and Back Channel Composition

Credentials Delegation

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

Level-of-Assurance transport

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

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

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

Technologies

The relevant security technologies can be divided between three overall security technique categories:

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

Transport security

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

Kerberos-based alternatives (existing and proposed) include:

• Kerberos with IPSec.

• Negotiate.

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

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

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

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

Application security

Negotiate

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

It is worth noting that Negotiate authentication does not protect the HTTP request, because they are sent unprotected during the GSS-API handshake (which is itself encoded within an HTTP header). This authentication method is therefore not advised in some use-cases; in particular, REST-style web-services cannot in general be protected using Negotiate.

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 (eg if a concentrator is deployed at the server). This implies that the authentication mechanism needs to support some form of state management. At least two different proposals have been put forward for solving this problem; one in http://tools.ietf.org/html/draft-johansson-http-gss where state management is done in the HTTP layer and one in http://tools.ietf.org/html/draft-zhu-negoex where state management is done in the GSS-API layer.

Information Card

[1] (reference material)

Kerberos authentication from Identity Selector to IdP 

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

Kerberos token delivery to the RP 

WS-Trust operates by delivering security tokens to RPs to authenticate clients.  WS-Trust is (or claims to be) token agnostic, meaning it can carry anything, but for a token format to be used interoperably its nature and handling by IdP and RP must be specified.  Infocard has primarily used SAML tokens, e.g. for self-issued cards.  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.

Identity Selector as standard authentication UI 

Infocard technology has been introduced as an approach to web authentication, since that space is obviously the most widely-used and most urgently in need of better solutions.  The selector concept could be extended to apply to any instance of user authentication.  This might involve extending selectors to support other protocols, or adding the use of WS-Trust for authentication to existing systems.

OAuth

[2] (reference material)

OAuth is a security protocol layered directly onto HTTP. It is a means for a web-based service provider to perform authenticated operations, on behalf of its users, with other service providers.

OAuth has no direct relationship to Kerberos or any other existing authentication technology at this time.

However, at the protocol level, it is essentially yet another re-invention of the classic "HTTP front-channel redirect-based web single sign-on" technique, following the examples of the SAML Web Browser SSO Profile, OpenID, the WS-Federation Passive Requester Profile, and a host of others.

Some parties have recently discussed 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. However, one could imagine conveying Kerberos tickets either instead of or in conjunction with such SAML assertions. Thus the above claim with regards to the relationship of OAuth and other presently existing authentication technologies might morph over time.

OpenID

[3] (reference material)

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

Message security

Security Strategies for Message-based architectures

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

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

The reason for using Kerberos may be any of:

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

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

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

The WS-* suite

[4] (reference material)

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

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

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

WS-Security Kerberos Token Profile

[5] (reference material) [message security]

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

The Kerberos message is attached to the SOAP message using the <wsse:BinarySecurityToken> element. Six different types are supported, including RFC 1510-style, RFC 4120-style and their equivalent GSS-API encapulsations. 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 (eg TLS).

OASIS Security Assertion Mark-up Language (SAML)

[6] (reference material)

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

Broadly, the SAML specifications define:

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

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

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

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

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

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

The IdP uses Kerberos authentication at the HTTP layer - eg Negotiate or NTLM

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

The IdP issues SAML assertions containing Kerberos tickets as an attribute

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

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

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

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

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

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

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

Liberty Alliance Identity Web Services Framework

[7] (reference material)

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

Browsers

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

Safari

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

Mozilla/Firefox

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

Internet Explorer

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

Konqueror

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

Application environments & Libraries

IIS

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

.NET

The .NET framework supports the kerberos xml-sec token profile aswell 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 webservices to more "enterprise"-style SOAP-based webservices.

Java

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

WSS4j

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

Suggested Activities

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

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

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

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