Re: [chromium-dev] Re: Intent to Implement: Kerberos for Chrome on Android

[Chris Bentzel]

+net...@chromium.org

On Wed, Apr 8, 2015 at 6:42 AM Anthony Berent <abe...@chromium.org> wrote:

Forgot to give contact information. Contacts are myself (abe...@chromium.org) and Bernhard Bauer (bau...@chromium.org)

On Wed, 8 Apr 2015 at 10:16 Anthony Berent <abe...@chromium.org> wrote:

Summary

A number of third parties have requested that we add Kerberos support to Chrome for Android. Kerberos is a widely used security mechanism used to control access to computing resources. In particular, is widely used in corporate environments to give access to corporate resources, so implementing it in Chrome for Android would let authorized users access such resources from their phones and tablets.

Kerberos is already supported on most other versions of Chrome.

Ongoing technical constraints

None

Tracking bug

http://crbug/474943

Design document

https://docs.google.com/a/chromium.org/document/d/1G7WAaYEKMzj16PTHT_cIYuKXJG6bBcrQ7QQBQ6ihOcQ/edit?usp=sharing

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Ryan Sleevi]

Two thoughts:
1) This doesn't seem to jive with the Android security model, at least as described. Any app with access to the Kerb account can get access to the TGT?
2) To get the TGT from the KDC, you need to have live connectivity to the KDC. This is extremely rare in most cases - it is why Kerberos as an authentication method is so flawed. I cannot see how Mobile makes this better, not worse.

There are plenty of alternatives for organizations to leverage alternative SSO solutions, both for PKINIT (use client auth) to password (pivot into OAuth 2.0/OpenID Connect/SAML). Organizations have been successfully deploying these solutions for (checks calendar) decades.

I'm not convinced that supporting a niche feature - a feature that will be nigh impossible to remove because it is impossible to gauge necessity of, and for which market economics will always make the remover the "bad person" due to taking away a feature - is a good thing.

Given the alternatives exist, given the very real issues that exist with Kerberos on mobile, I'd like to push back on this. Of course, my arguments are not one of technology - as we totally have the technology - but one of product direction and strategy.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAAuiYA-MxmsGLBvhLmjFpJYDOCwFqp7_sxBJgBKDXFZVm0ck%2Bg%40mail.gmail.com.

[Bernhard Bauer]

Hi Ryan,

On Wed, Apr 8, 2015 at 5:03 PM Ryan Sleevi <rsl...@chromium.org> wrote:

Two thoughts:
1) This doesn't seem to jive with the Android security model, at least as described. Any app with access to the Kerb account can get access to the TGT?

The app would get a service ticket, not the TGT. The TGT never leaves the authenticator. It's true that any app can call the API, but the authenticator can find out the calling application and decide whether to return a token, return an error, ask the user for permission, or something else. This is pretty much the same as for Google accounts, I think. 

2) To get the TGT from the KDC, you need to have live connectivity to the KDC. This is extremely rare in most cases - it is why Kerberos as an authentication method is so flawed. I cannot see how Mobile makes this better, not worse.

Why is this so rare? If you have connectivity to the HTTP server that requires Kerberos auth, why wouldn't you have connectivity to the KDC? 

There are plenty of alternatives for organizations to leverage alternative SSO solutions, both for PKINIT (use client auth) to password (pivot into OAuth 2.0/OpenID Connect/SAML). Organizations have been successfully deploying these solutions for (checks calendar) decades.

I'm not convinced that supporting a niche feature - a feature that will be nigh impossible to remove because it is impossible to gauge necessity of, and for which market economics will always make the remover the "bad person" due to taking away a feature - is a good thing.

Given the alternatives exist, given the very real issues that exist with Kerberos on mobile, I'd like to push back on this. Of course, my arguments are not one of technology - as we totally have the technology - but one of product direction and strategy.

This mailing list isn't the right place to discuss product direction and strategy though :-/ Happy to go into details on an internal list or in private, but I can say that we have had requests for Kerberos support on Android from several sides, so this is definitely not a niche feature. 

Bernhard.  

[Ryan Sleevi]

On Wed, Apr 8, 2015 at 10:11 AM, Bernhard Bauer <bau...@chromium.org> wrote:

2) To get the TGT from the KDC, you need to have live connectivity to the KDC. This is extremely rare in most cases - it is why Kerberos as an authentication method is so flawed. I cannot see how Mobile makes this better, not worse.

Why is this so rare? If you have connectivity to the HTTP server that requires Kerberos auth, why wouldn't you have connectivity to the KDC? 

It's extremely rare. It's why Kerberos auth requires a VPN, because in virtually all common implementations, UDP 88 used. You rarely (never?) want to expose your KDC on the Internet.

That's why this is a fairly limited feature, that already has known issues. Kerberos, on the "internet", doesn't really work. On the Intranet, it only really works with VPNs.

 

This mailing list isn't the right place to discuss product direction and strategy though :-/ Happy to go into details on an internal list or in private, but I can say that we have had requests for Kerberos support on Android from several sides, so this is definitely not a niche feature. 

Well, yes and no, which is why I wanted to highlight this.

Exposing additional options or chrome flags isn't a technology discussion, it's a product direction/strategy question. Luckily, we have fairly good (and public) guidelines and rationale to refer people to.

Supporting HTTP for privileged features isn't so much a technology discussion, it's a product direction/strategy question. Luckily, we have fairly good (and public) discussions of privacy and security, and so we can use this to provide guidance to people.

We don't always have that for niche product features - and our metrics certainly show this is very much a niche feature, even when factoring in under-counting for enterprises that have disabled metrics. It's also something that, in terms of Chrome strategy, seems to be focused on developing solution for this decades problem, rather than those of the 1980s.

I wanted to highlight alternatives because that's how we go with a lot of intent to implement - that is, the "If not X, then what?". There are a number of good, well understood, well deployed, readily available "then what" answers for Kerberos today, so I think that bears relevance to the discussion. There's also ongoing work for improving things further - the work Mike West and W3C's WebAppSec are exploring in https://w3c.github.io/webappsec/specs/credentialmanagement/ - that can further improve things.

There's also a question of technical cost, what the success criteria are, what the failure criteria are, and I think those are all relevant to public discourse.

My hope is that as an open-source project, we can be as transparent as possible for product direction and strategy. When it comes to "Feature X vs Feature Y", having a public set of criteria or guidelines is immensely valuable.

[David Benjamin]

On Wed, Apr 8, 2015 at 1:11 PM Bernhard Bauer <bau...@chromium.org> wrote:

Hi Ryan,

On Wed, Apr 8, 2015 at 5:03 PM Ryan Sleevi <rsl...@chromium.org> wrote:

Two thoughts:
1) This doesn't seem to jive with the Android security model, at least as described. Any app with access to the Kerb account can get access to the TGT?

The app would get a service ticket, not the TGT. The TGT never leaves the authenticator. It's true that any app can call the API, but the authenticator can find out the calling application and decide whether to return a token, return an error, ask the user for permission, or something else. This is pretty much the same as for Google accounts, I think. 

CC'ing Ben Kaduk, a friend of mine at the MIT Kerberos Consortium. 

(I actually built something of this sort for my masters thesis, though my authenticator app was JS that postMessage'd the ticket over. It was slightly crazy.)

I believe returning a service ticket works to some degree, though Asanka and Ben are better people than me to review Kerberos minutia. The authenticator app is nominally out of scope for the Chrome half, but I think it's worth figuring out that behavior as that's where most of the security properties will come from.

The authenticator app's UI is probably going to be somewhat screwy. With Google accounts, the UI says things like "Can access your Google Documents" or "Can read your contacts" or whatever. A service ticket name doesn't necessarily say much useful. For instance, at MIT, moira/moira7.mit.edu lets you change all ACLs owned by that user. afs/athena.mit.edu lets you touch all the user's files. And krbtgt/REALM is literally a TGT.

Realistically, the authenticator app probably ought to whitelist the services which are allowed to participate. I suspect a fine-grained whitelist would be deployment specific, though just whitelisting HTTP/* is probably sufficient for HTTP Negotiate?

I believe HTTP Negotiate also has a ticket delegation mechanism? We have a AuthNegotiateDelegateWhitelist corp policy. If you were to support that one, it would not be just sending a service ticket to the app.

Another nuisance was that TGTs at MIT were only good for 24 hours. If you had a renewable ticket, they're good for a week, but it requires continuous connectivity to the KDC, as Ryan mentioned. You have to wake up to renew the ticket before your old ticket expires. If it expires, you have to enter your password again, which is especially a pain on mobile.

David

[Benjamin Kaduk]

On Wed, 8 Apr 2015, David Benjamin wrote:

> On Wed, Apr 8, 2015 at 1:11 PM Bernhard Bauer <bau...@chromium.org> wrote:
>
> > Hi Ryan,
> >
> > On Wed, Apr 8, 2015 at 5:03 PM Ryan Sleevi <rsl...@chromium.org> wrote:
> >
> >> Two thoughts:
> >> 1) This doesn't seem to jive with the Android security model, at least as
> >> described. Any app with access to the Kerb account can get access to the
> >> TGT?
> >>
> > The app would get a service ticket, not the TGT. The TGT never leaves the
> > authenticator. It's true that any app can call the API, but the
> > authenticator can find out the calling application and decide whether to
> > return a token, return an error, ask the user for permission, or something
> > else. This is pretty much the same as for Google accounts, I think.
> >
>
> CC'ing Ben Kaduk, a friend of mine at the MIT Kerberos Consortium.

Thanks. There are probably some other folks which would be interested in
this topic, both here at MIT and elsewhere, depending on the scope of the
desired functionality.

> (I actually built something of this sort for my masters thesis, though my
> authenticator app was JS that postMessage'd the ticket over. It was
> slightly crazy.)
>
> I believe returning a service ticket works to some degree, though Asanka
> and Ben are better people than me to review Kerberos minutia. The
> authenticator app is nominally out of scope for the Chrome half, but I
> think it's worth figuring out that behavior as that's where most of the
> security properties will come from.

Yes, the security properties definitely will depend on what the
authenticator app looks like; it is also probably worth considering
whether there might be multiple distinct implementations of the
authenticator app (or rather, the API it presents), since this is one of
the things that may affect who is interested.

So, backing up a bit, I am curious what exactly is meant by "Kerberos for
Chrome". I assume that it is intended to mean using Kerberos with
HTTP-Negotiate, which is wrapping Kerberos inside the SPNEGO GSS-API
mechanism, given the talk of AuthNegotiateDelegateWhitelist and such.
But, in this case, it is not *just* Kerberos which is possible, even if
that is what people are asking for. (It's also worth noting that
NTTP-Negotiate+SPNEGO is kind of a terrible hack; it violates both HTTP
semantics (connection-oriented instead of stateless) and syntax
(incompatible with WWW-Authenticate and Authorization header syntax).
However, it's what we've got.)

But, there are GSS-API mechanims other than Kerberos. In particular, Sam
Hartman and co. already have implemented a chrome plugin exposing GSS-API
support to javascript, with the main intent being to use the EAP GSS
mechanism. (Not using HTTP-Negotiate.) So, I think that some
consideration should be given to whether just Kerberos is to be supported,
or arbitrary GSS-API mechanisms. It would be a little sad/amusing if we
ended up making Chrome on Android leapfrog desktop Chrome in terms of
GSS-API support by going from no support to a fully-functional credentials
selector that allowed the user to control whether and which credentials
are used, though.

> The authenticator app's UI is probably going to be somewhat screwy. With
> Google accounts, the UI says things like "Can access your Google Documents"
> or "Can read your contacts" or whatever. A service ticket name doesn't
> necessarily say much useful. For instance, at MIT, moira/moira7.mit.edu
> lets you change all ACLs owned by that user. afs/athena.mit.edu lets you
> touch all the user's files. And krbtgt/REALM is literally a TGT.
>
> Realistically, the authenticator app probably ought to whitelist the
> services which are allowed to participate. I suspect a fine-grained
> whitelist would be deployment specific, though just whitelisting HTTP/* is
> probably sufficient for HTTP Negotiate?

For HTTP Negotiate, HTTP/* is probably fine. (This is also more easy to
represent using GSS name types, where it would be HTTP@<hostname> of name
type GSS_C_NT_HOSTBASED_PRINCIPAL, since Kerberos name types can in
principle be in more different forms.)

> I believe HTTP Negotiate also has a ticket delegation mechanism? We have
> a AuthNegotiateDelegateWhitelist corp policy. If you were to support that
> one, it would not be just sending a service ticket to the app.

Yes, HTTP Negotiate has a mechanism for delegation. (There are some
scenarios with certain softwares which involve getting a fresh TGT from
the KDC for each HTTP resource requested, when delegation is enabled, with
the expected result for performance.) The authenticator app might need to
have a BIG SCARY WARNING in that case (I assume that some of the requests
for Kerberos support involve this delegation), but UI is probably out of
scope at the moment.

> Another nuisance was that TGTs at MIT were only good for 24 hours. If you
> had a renewable ticket, they're good for a week, but it requires continuous
> connectivity to the KDC, as Ryan mentioned. You have to wake up to renew
> the ticket before your old ticket expires. If it expires, you have to enter
> your password again, which is especially a pain on mobile.

In my mental picture of how things work, the responsibility for renewal
would lie outside of Chrome; however, my mental model is shaped by some
previous work that has happened here at MIT.

In particular, a few years ago, the Kerberos Consortium spent some money
on a "Kerberos for Androide" project, essentially porting our Unix krb5
distribution to Android and providing a demo app implementing some
credential manager functionality and a proof-of-concept GSS client/server
pair. [0,1] One of my first tasks as a new hire was supposed to be to
finish off that work and produce a more polished credentials manager app;
unfortunately, some other higher priority tasks came up so I haven't
gotten to it yet. In this model, other android apps could act as
kerberos^WGSS-API clients by using an intent to get to the credentials
manager, which would give the user a dialog to approve the action (if not
already whitelisted).

In this model, the thing being referred to as the "authenticator app"
above (if I understand correctly) might be provided by a third party (such
as MIT or Painless Security (Sam Hartman's company), and not necessarily
bundled with Chrome.

Please comment on how my mental model differs from yours :)

> 2) To get the TGT from the KDC, you need to have live connectivity to the
> >> KDC. This is extremely rare in most cases - it is why Kerberos as an
> >> authentication method is so flawed. I cannot see how Mobile makes this
> >> better, not worse.
> >>
> > Why is this so rare? If you have connectivity to the HTTP server that
> > requires Kerberos auth, why wouldn't you have connectivity to the KDC?

In a different branch of the thread, Ryan says:

% It's extremely rare. It's why Kerberos auth requires a VPN, because in
% virtually all common implementations, UDP 88 used. You rarely (never?)
% want to expose your KDC on the Internet.

I feel obligated to note that the Kerberos protocol (port 88) is
explicitly designed to run over the public, untrusted, internet. Many
corporations may firewall the KDC hosts off, if (say) they are running
other services such as LDAP which are not necessarily trusted for the
public internet. From the protocol level, port 88 is fine to be open. I
am not entirely sure where the sense that it is not desirable to expose it
to the Internet is coming from, though; as far as I can tell, it is
not really a justifiable position.

> >> There are plenty of alternatives for organizations to leverage
> >> alternative SSO solutions, both for PKINIT (use client auth) to password
> >> (pivot into OAuth 2.0/OpenID Connect/SAML). Organizations have been
> >> successfully deploying these solutions for (checks calendar) decades.

I will let David share his opinions on client auth, but in some circles,
"SSO with password" means "the password does not leave the local device",
which OAuth 2.0/OpenID Connect/SAML are not really compatible with. Which
is not to say that the mode where the password is sent to the IdP does not
have widespread deployment, of course.

> >> I'm not convinced that supporting a niche feature - a feature that will
> >> be nigh impossible to remove because it is impossible to gauge necessity
> >> of, and for which market economics will always make the remover the "bad
> >> person" due to taking away a feature - is a good thing.

It would be nice to see some data on just how small (or big) that niche
is.

-Ben Kaduk


[0] https://github.com/cconlon/kerberos-java-gssapi
[1] https://github.com/cconlon/kerberos-android-ndk

[Bernhard Bauer]

Fair enough. I am in fact trying to keep this conversation as transparent as possible; in particular, things like the technical cost are exactly what I want to be discussed in public. Things like "does anyone actually want this?" can't be though, because not all of the data points that I have there are public.

You have a good point about alternatives, it's just that we seem to differ on what the problem is that we're trying to solve here. The problem is not "How do we solve SSO on the web", it's "How do we talk to a Kerberos server". There are existing organizations out there that have Kerberos installations, they want to use Chrome, and we want to make it possible for them to use Chrome with it.

To come back to the questions that we can discuss in public:The technical cost here is relatively low, because Negotiate support is already implemented and we just need to plumb calls through to an Android API. The part about success and failure criteria I didn't really understand; success would be people implementing authenticators and users using it, and failure the opposite?

Bernhard.

[Bernhard Bauer]

Hi Ben, 

Yes, there could be multiple implementations, and we'll ask the user to pick one of them in that case.

 

So, backing up a bit, I am curious what exactly is meant by "Kerberos for
Chrome".  I assume that it is intended to mean using Kerberos with
HTTP-Negotiate, which is wrapping Kerberos inside the SPNEGO GSS-API
mechanism, given the talk of AuthNegotiateDelegateWhitelist and such.
But, in this case, it is not *just* Kerberos which is possible, even if
that is what people are asking for.  (It's also worth noting that
NTTP-Negotiate+SPNEGO is kind of a terrible hack; it violates both HTTP
semantics (connection-oriented instead of stateless) and syntax
(incompatible with WWW-Authenticate and Authorization header syntax).
However, it's what we've got.)

Yes, this is really a general mechanism for HTTP-Negotiate; it's just that Kerberos is the primary use case we envision here. The one thing that is somewhat specific to Kerberos is the SPN generation (see https://www.chromium.org/developers/design-documents/http-authentication). That has already been implemented though and is used on desktop platforms.

 

But, there are GSS-API mechanims other than Kerberos.  In particular, Sam
Hartman and co. already have implemented a chrome plugin exposing GSS-API
support to javascript, with the main intent being to use the EAP GSS
mechanism.  (Not using HTTP-Negotiate.)  So, I think that some
consideration should be given to whether just Kerberos is to be supported,
or arbitrary GSS-API mechanisms.  It would be a little sad/amusing if we
ended up making Chrome on Android leapfrog desktop Chrome in terms of
GSS-API support by going from no support to a fully-functional credentials
selector that allowed the user to control whether and which credentials
are used, though.

We are not actually going to use GSSAPI, but essentially a very simple API that takes an SPN and returns a token to put into the HTTP header. We will get something like a credential selector though by virtue of the Android framework.

Yup, that's our idea as well :) The authenticator app would be implemented by a third party, and the existing Kerberos port(s?) would be an excellent starting point. 

Bernhard.

[Ryan Sleevi]

On Apr 8, 2015 2:55 PM, "Bernhard Bauer" <bau...@chromium.org> wrote:
>
> The problem is not "How do we solve SSO on the web", it's "How do we talk to a Kerberos server". There are existing organizations out there that have Kerberos installations, they want to use Chrome, and we want to make it possible for them to use Chrome with it.

I do think it is worth spending a little bit of time focusing on this. I wasn't answering "How do we solve SSO on the web", I was trying to challenge the "How do we talk" with "Should we?"

That is an intrinsic part of every discussion around features - If we do not solve the question in the way I see X wants, what alternatives are there, or what are the reasons for not doing this?

I still have fundamental concerns with the "should" portion - to some extent, we should apply the same criteria for all other features and bug requests.

As a perhaps cruel and unfounded example, you don't hear us asking "How do we help organizations use SHA-1 beyond 2017" - precisely because they shouldn't.

I don't mean that we should reject every request for features, just that we are transparent in asking "Is this the right thing?". For example, we don't want NTLM to continue to exist, but we support it now. We don't want it because it doesn't meet our security requirements and violates the transport layer semantics. But there are organizations that depend on NTLM and want it supported indefinitely - which we cannot and will not do.

> To come back to the questions that we can discuss in public:The technical cost here is relatively low, because Negotiate support is already implemented and we just need to plumb calls through to an Android API. The part about success and failure criteria I didn't really understand; success would be people implementing authenticators and users using it, and failure the opposite?

I have a different impression of the costs. You've seen some replies that detail the security costs (this is not as trivial as suggested if it is to be done securely), there are the integration costs (decoupling already complex code that is, by necessity of the feature, incredibly difficult to realistically test), the design costs (inherent to such a discussion), the API costs (coupling this to a Google-specific solution, when you can see there is clearly desire for an interoperable solution). It is a feature that doesn't have a well-defined time when we can remove it, which we eventually should want to do.

That is not to say we should block _experimenting_ with implementing and refining over time to see if it yields something valuable. However, I am concerned about this being the right technical solution to the problem, and I'm concerned that the upfront costs versus the value is worthwhile.

The question is "How much does this cost Chromium developers (to implement)" and " How much does this cost our users (in size costs, relative prioritization of other features, maintenance costs)" versus "How much does it cost these sites to adopt a solution that reliably works on the Web vs Kerveros". My gut is that the former outweighs the latter, which is why it bears asking whether there are alternative solutions that exist.

This is the same sort of question we ask when looking at all other features.

Again, I dont want to block implementing, just committing to it being the right solution or strategy for our users.

[Anthony Berent]

Ryan,

Are your concerns specific to Kerberos, or do you believe that we should not support HTTP Negotiate authentication at all? 

Although this work was motivated by requests for Kerberos support, in my current proposal everything I propose in Chrome, with possible exception of generating the SPN, could be applied to, and would be needed for, any use of the Negotiate protocol. In effect, all my proposal does to Chrome is provide a way for Negotiate authentication to use Android's token based authentication mechanisms. The actual Kerberos implementation (or other authentication mechanism) is in the third party authenticator.

[David Benjamin]

HTTP Negotiate's problems aren't limited to Kerberos. It requires that multiple HTTP requests go over the same socket with nothing else in between, which breaks every core assumption of our net stack. That's not to say we shouldn't support it (clearly there was a need on desktop, and I don't think we have imminent plans to drop the current code), but the protocol looks nothing like what a correctly-designed HTTP mechanism would look like.

[Ryan Sleevi]

On Thu, Apr 9, 2015 at 5:36 AM, Anthony Berent <abe...@chromium.org> wrote:

Ryan,

Are your concerns specific to Kerberos, or do you believe that we should not support HTTP Negotiate authentication at all? 

Supporting Kerberos on mobile is, to me, somewhat like supporting plugins on mobile. Yes, there may be people who ask for it, yes, it may be a good idea, but as a part of the Web platform, they're an antiquated, sometimes dangerous, generally complex technology with limited rewards and (generally) viable alternatives, even if those alternatives require work.

Promoting/encouraging Kerberos on the web, over techniques built on 'standard' (and yes, I'm aware HTTP Auth is a standard, but as David has noted, Negotiate/NTLM break as many of the requirements of the specs they're meant to extend as they can) technologies, seems to put it at a disadvantage for designing new devices and ways to access the Web.

On a strategic Chrome level, it's probably entirely possible. But is prolonging Kerberos on the Web a good thing? Probably not.

Those concerns can be somewhat ameliorated by some of the security concerns that David was talking about re: the app - that is, it's very easy to botch the app security, so it really should be part of the threat model for Chrome to support something if it's going to expose a new attack vector to the web. Requiring that the authentication only work with a set of administratively whitelisted origins - as we do(ish) for Desktop and want to do more of - seems minimally consistent. 

 

Although this work was motivated by requests for Kerberos support, in my current proposal everything I propose in Chrome, with possible exception of generating the SPN, could be applied to, and would be needed for, any use of the Negotiate protocol. In effect, all my proposal does to Chrome is provide a way for Negotiate authentication to use Android's token based authentication mechanisms. The actual Kerberos implementation (or other authentication mechanism) is in the third party authenticator.

Of course, I'm presuming that other authenticator apps can work? Or is this just for a Google Kerberos app? 

[Bernhard Bauer]

On Thu, Apr 9, 2015 at 7:04 PM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Apr 9, 2015 at 5:36 AM, Anthony Berent <abe...@chromium.org> wrote:

Ryan,

Are your concerns specific to Kerberos, or do you believe that we should not support HTTP Negotiate authentication at all? 

Supporting Kerberos on mobile is, to me, somewhat like supporting plugins on mobile. Yes, there may be people who ask for it, yes, it may be a good idea, but as a part of the Web platform, they're an antiquated, sometimes dangerous, generally complex technology with limited rewards and (generally) viable alternatives, even if those alternatives require work.

There is a huge difference in the technical cost though. Plugins are incredibly difficult to support and greatly increase the attack surface of the browser. All we are doing is taking the existing code for Negotiate auth and plumbing it through to Java instead of calling GSSAPI in C++.

 

Promoting/encouraging Kerberos on the web, over techniques built on 'standard' (and yes, I'm aware HTTP Auth is a standard, but as David has noted, Negotiate/NTLM break as many of the requirements of the specs they're meant to extend as they can) technologies, seems to put it at a disadvantage for designing new devices and ways to access the Web.

On a strategic Chrome level, it's probably entirely possible. But is prolonging Kerberos on the Web a good thing? Probably not.

Like you said, this is a question of product strategy, which should be discussed somewhere else.

 

Those concerns can be somewhat ameliorated by some of the security concerns that David was talking about re: the app - that is, it's very easy to botch the app security, so it really should be part of the threat model for Chrome to support something if it's going to expose a new attack vector to the web. Requiring that the authentication only work with a set of administratively whitelisted origins - as we do(ish) for Desktop and want to do more of - seems minimally consistent. 

 

Although this work was motivated by requests for Kerberos support, in my current proposal everything I propose in Chrome, with possible exception of generating the SPN, could be applied to, and would be needed for, any use of the Negotiate protocol. In effect, all my proposal does to Chrome is provide a way for Negotiate authentication to use Android's token based authentication mechanisms. The actual Kerberos implementation (or other authentication mechanism) is in the third party authenticator.

Of course, I'm presuming that other authenticator apps can work? Or is this just for a Google Kerberos app? 

The former is correct: this is designed to allow anyone to implement the authenticator app.

Bernhard. 

[Ryan Sleevi]

On Thu, Apr 9, 2015 at 11:44 AM, Bernhard Bauer <bau...@chromium.org> wrote:

There is a huge difference in the technical cost though. Plugins are incredibly difficult to support and greatly increase the attack surface of the browser. All we are doing is taking the existing code for Negotiate auth and plumbing it through to Java instead of calling GSSAPI in C++.

This isn't entirely true; that is, the attack surface is dictated by the authenticator app you're talking to and it's policies. There's definitely the possibility to do things right, but the default state is to botch things. I think that's at least relevant to the discussion - we're exposing native apps to web content and web content to native apps, so the security exposure is holistic. 

[Anthony Berent]

Following various discussions, particularly around security, I have now made some significant changes to the design document (https://docs.google.com/a/chromium.org/document/d/1G7WAaYEKMzj16PTHT_cIYuKXJG6bBcrQ7QQBQ6ihOcQ/edit?usp=sharing). If this interests you please take another look.