Difference between revisions of "KrbWeb Outline of Work"

Revision as of 16:37, 1 September 2008

This document is a draft concerning Kerberos and the Web.

Related Pages

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

Technologies

Negotiate

Negotiate is the collected name of a loosely defined set of HTTP authentication mechanisms which provide a simple 2-way GSS-API handshake with the HTTP server. The most commonly deployed variant is 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 to note that Negotiate authentication does not protect the headers of the request since they are sent unprotected during the GSS-API handshake. In particular this means that REST-style webservices cannont in general be protected using Negotiate.

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. Acquisition of the token is out-of-scope.

The Kerberos message is attached to SOAP messages 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)

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

The IdP uses Kerberos authentication at the HTTP layer - eg Negotiate or NTLM: 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 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.

The IdP issues SAML assertions containing Kerberos tickets as an attribute: This would require modifications (possibly not too significant) to the SAML IdP. 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.

The KDC includes a SAML assertion and/or authentication response message encapsulated in KDC-issued authorization data: This would probably require modification (probably reasonably significant) to the KDC. 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.

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

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)

Identity Web Services Framework (ID-WSF - from the Liberty Alliance) is 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.

Note that the WS-Trust protocol -- a component of WS-* -- plays a key role in the Information Cards technology, described next.

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

Browsers

Most browsers supports Negotiate by default but

Safari

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 although there are at least two commercial implementations.

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

Intra Enterprise

A large organization (eg a university or large company) is deploying an increasing number of web services. Initial deployments (which are typically few in number) relied on user name+password sometimes (but not always) with TLS. HTTP is almost always used as a transport for SOAP. Message-layer authentication is very uncommon in these situations.

As the deployment grows the job of keeping track of and provisioning passwords for these services becomes an issue. In some cases the security issues involved are part of the discussion. The most common action taken is to try to move to the use of client certificates but mostly an organization in this situation will buy a webservice-governance solution. Such products are often based on an ESB (enterprise service bus) and sometimes employ other transports besides HTTP, eg various message-oriented protocols such as MQ or XMPP.

The motivation for Kerberos in this type of situation will be because it can simplify the security-management. An enterprise-wide deployment of SOAP-based web services are seldom perceived to have security issues and is often treated as a single administrative domain isolated from everything except the business systems which are connected using the web services. This means that the security properties of Kerberos won't be an important part of evaluating it 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

In this situation a business, possibly with an existing enterprise-wide SOAP-deployment, needs to integrate with another business using an app2app SOAP-based web service. The security model is typically fairly simple one - the applications trust each other and there are no n-tier issues involved. A common way to provide basic authentication is to setup some form of tunnel between the business-entities (eg an ipsec tunnel) TLS with user name and password is used. The use of anything other than HTTP-transport for SOAP is probably very uncommon in this situation.

The motivation for Kerberos in this situation may rely on cross-realm trust between the business-entities and the desire to use this infrastructure instead of setting up a separate trust-model (eg based on certificates or passwords). The main difference between this case and the previous one is the fact that for each pair of B2B relationship a very small number (typically) of web services are involved. This means that maintaining cross-realm trust must be perceived as a low barrier.

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.

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

B2C

Business-to-customer use-cases typically involve front-channel authentication. Most technologies involved in front-channel authentication (eg SAML WebSSO) uses passwords as the authentication mechanism even if other mechanisms are supported. The reason to use Kerberos might be to provide a better user-experience. Information Card in combination with Kerberos can 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. The challenges lie in identity provisioning and management - a user would typically need to obtain and negotiate the use of credentials from multiple identity providers (realms).

Credentials Delegation

Another use-case in this category is the use of credentials delegation (aka N-Tier) in the identity federation case. For instance consider the problem of providing access to a set of IMAP servers in separate administrative domains (all using GSS-API authentication) from a common web-based frontend which uses SAML WebSSO to provide (federated) authentication. The identity providers trusted by the web application could provide credentials for their own IMAP server(s) using a SAML attribute.

Level-of-Assurance transport

There are multi-tier cases (eg web-frontend with federated authentication with kerberied backend services) where policy restricts the way authentication to the backend services must be related to the front-channel authentication. Several examples stem from the US federal sector where there may be requirements that the authentication be based on the use of smartcard technology. There are currently no way to communicate information about then authentication (except in a few corner cases involving PK-INIT) was done from a kerberos-based IdP to a relying party service being invoked from a web portal. This example may seem convoluted but is in fact based on very concrete use-cases in the GRID community where large-scale deployments often use kerberos. The SAML authentication context probably fulfills the requirements of most of these use-cases but it is unspecified how the SAML AC fits into a kerberos deployment.

User Stories

General

Users want to assert different identity information in different contexts, but typical 
Kerberos application/client implementations do not support this gracefully

Users want to use untrusted hardware (eg. an airport internet kiosk) to access a web site 
without compromising her credentials.

Banking

Internet banks want to avoid phishing.

Customers of internet banks want simple authentication mechanisms.

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

Suggested Items of Work

This list is not prioritized.

Update the kerberos xml security token profile to support (eg) mutual authentication and channel bindings.
Promote the implementation of the (updated) kerberos token profile in common software frameworks, eg .NET, wss4j. Demonstrate interoperability.
Interoperability testing of Negotiate implementations.
Specify credentials-delegation for SAML-based SSO.
Promote implementation and interoperability testing of Kerberos authentication for Information Card.
Investigate the role of Kerberos in OAuth.
Document the ways in which Kerberos can be used in a web-context wit current technology (eg expand this document).
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.
Update Negotiate (in progress)

Recommendations for next steps