KrbWeb Outline of Work - Revision history

=JeffH: /* Negotiate */ polish observations wrt Negotiate in 3d para

2008-10-29T23:15:13Z

‎Negotiate: polish observations wrt Negotiate in 3d para

=JeffH: /* Negotiate */ correcting title of rfc4559 and the authn scheme

2008-10-29T22:32:27Z

‎Negotiate: correcting title of rfc4559 and the authn scheme

=JeffH: overall edit for "use case" "user stor" and "end user*", plus a few other minor spelling, grammar fixes.

2008-10-29T21:31:29Z

overall edit for "use case*" "user stor*" and "end user*", plus a few other minor spelling, grammar fixes.

Show changes

=JeffH: moved rigor disclaimer to introduction

2008-10-29T20:48:45Z

moved rigor disclaimer to introduction

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

2008-10-29T20:40:51Z

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

=JeffH: /* Recommendation 1: Determine the overall strategic approach in consultation with relevant stakeholders */

2008-10-29T20:39:48Z

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

=JeffH: /* Use Cases */ updated front channel description

2008-10-29T17:27:02Z

‎Use Cases: updated front channel description

Rlbob: /* Application Environments & Libraries */

2008-10-29T16:24:32Z

‎Application Environments & Libraries

Leifj: /* Opportunities */

2008-10-29T16:15:29Z

‎Opportunities

Leifj: /* Security Protocol Overall Efficiency */

2008-10-29T16:05:09Z

‎Security Protocol Overall Efficiency

@@ Line 448: / Line 448: @@
 ====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, "HTTP Negotiate Authentication Scheme", defined in RFC 4559, ''SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows'', 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 448: / Line 448: @@
 ====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, 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.
 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).

@@ Line 9: / Line 9: @@
 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):
@@ Line 25: / Line 24: @@
 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.
 ==Acknowledgments==

@@ Line 1,138: / Line 1,138: @@
 ===Recommendation 2: Initiate activities to address those opportunities whose applicability is independent of strategic direction===
-There are two 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").
+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===

@@ Line 1,130: / Line 1,130: @@
 ===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 later is likely to yield faster results given the opportunity to leverage existing Web authentication systems and minimize alterations to the client.
+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.

@@ Line 247: / Line 247: @@
 * ''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).

← Older revision		Revision as of 16:24, 29 October 2008
Line 949:		Line 949:

	===Application Environments & Libraries===		===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====

@@ Line 416: / Line 416: @@
 |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. '''LJ: we need to mention that this has been tried before and has failed and why'''
+: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.

← Older revision		Revision as of 16:05, 29 October 2008
Line 362:		Line 362:
	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. -->		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 Protocol Overall Efficiency====
		+

	====Security Token Size====		====Security Token Size====