Difference between revisions of "KrbWeb Outline of Work"

Revision as of 07:05, 16 September 2008

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

Technologies

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.

WS-Security Kerberos Token Profile

[1] (reference material)

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.

SAML

[2] (reference material)

SAML provides a suite of XML-based protocols that enables different security domains to exchange security data about user principals. 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.

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

There are several ways in which SAML, in terms of either SAML assertions themselves or the SAML profiles, can/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.

ID-WSF

[3] (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.

WS-*

[4] (reference material)

WS-* ("dubya ess star") denotes a suite of web services specifications promulgated by IBM, Microsoft and various collaborators. The WS-Security specification, along with the aforementioned WS-Security Kerberos Token Profile specification, are components of WS-*. Thus Kerberos is applicable in this context in a fashion similar to its applicability in ID-WSF.

In the context of security, the most important specification is WS-Trust. This specification defines a general protocol for requesting, issuing, renewing and canceling security tokens. WS-Trust also plays a key role in the Information Cards technology, described next, which is essentially a specialisation of WS-Trust.

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.

Information Card

[5] (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

[6] (reference material)

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

OpenID

[7] (reference material)

A user can use Kerberos to authenticate to her OP (OpenID IdP).

SOAP Security Strategies

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

Transport security

HTTP is the common choice in this case but there are other options - eg XMPP. However it is likely that in this case message-based authentication would be preferred in practice since having support for multiple transports makes it likely that the service endpoint application server will actually support webservices running on more than one transport. Put another way: when 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 which makes it likely that multiple transports will actually get used. Put yet another way: 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.

Transport security is often provided, as mentioned previously, using TLS and X.509 PKI.

Kerberos-based alternatives (existing and proposed) include:

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

Message security

Using Kerberos at the SOAP message layer assumes an implementation of the Kerberos XML-Security token profile. This profile suffers from several drawbacks and in practice needs to be combined with transport layer security (eg TLS).

Browsers

Most browsers supports 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 family browsers include 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 supports kerberos authentication for Information Card IdPs.

Internet Explorer

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,

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.

Use Cases

The use-cases are divided between three categories

• Back Channel - this describes transactions between parties occur directly, without relying on user-wielded tools (typically, although not exclusively, a web browser) to act as an intermediary. 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 transactions between parties occur indirectly, using 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 transactions 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 (for example, a university or a large company) 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-customer

Business-to-customer use-cases typically involve front-channel exchanges through the user's browser. Most technologies involved in front-channel authentication (eg SAML WebSSO) uses passwords as the authentication mechanism 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.

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 the use of 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. However, solving the general case (i.e. for most customers, for most businesses) presents 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 establishment 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.

User Stories

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: 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: More generally, people (aka users) simply want to be able to use any their 
devices -- e.g. deskbound systems, laptops, and handheld mobile devices -- to securely make 
use of web-based sites/services, in as transparent a fashion as possible. For example, I wish 
to simply login to my any of my devices, and then be able to interact 
with my bank(s) without having to jump through obvious further authentication hoops.

Flexibility: In addtion to transparency, 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. 

[issue: typical Kerberos application/client implementations do not support this gracefully]

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

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.