Intent to Ship: NTLMv2 on non-Windows Platforms

[Zentaro Kavanagh]

I was only recently made aware of the I2S process and it's a little unclear if this applies since it isn't really an API. But just for good measure here it is!

Short Version

• NTLMv1 is recommended to be disabled in Windows environments.
  
• Chromium on non-Windows can't be used in such secured environments because NTLMv2 isn't supported. Safari and Firefox both support NTLMv2 on non-Windows platforms.
• This change makes Chromium on non-Windows be consistent with all major browsers on Windows platform.
• This makes Chromium the only browser on non-Windows that supports EPA (Extended Protection for Authentication) aka Channel Binding for NTLM.

Long Version

Contact emails

zen...@google.com, asa...@google.com, dsk...@google.com

Explainer

NTLM is an authentication protocol used in Windows environments. NTLM has had several iterations/enhancements to increase the security of the protocol since it was first released. All Windows clients released after Windows 2003 support a new version of the protocol (NTLMv2) and current Microsoft guidance is to disable NTLMv1 on servers.

Chromium/Chrome is currently the only major browser that doesn’t support NTLMv2 (Feature Request) on non-Windows platforms which results in it being unable to be used in modern Windows enterprise environments. Additionally as part of the Chromad (Domain joined Chromebooks) project, support for NTLMv2 is required in Chrome OS.

This feature implements the new version of the protocol based on the official Microsoft specification and will allow Chrome on non-Windows platforms such as Mac, Linux, Chrome OS and Android to authenticate to NTLMv2 enabled web servers.

In addition to the minimal NTLMv2 support, two additional sub features - Extended Protection for Authentication (EPA) and Message Integrity Check (MIC) will also be implemented. The mechanism of authentication is the same as for NTLMv1 with a 3 message (Negotiate, Challenge, Authenticate) handshake, however the Authenticate message uses different algorithms and contains additional fields.

Specs

Official Microsoft Spec - https://msdn.microsoft.com/en-us/library/cc236621.aspx

Detailed Description of V1 vs V2 protocol Differences - https://docs.google.com/document/d/18kQ_TFQns2HZ9KGs4bGDfiiOIRmOhI12oJBttvUlYLY/edit

Additional NTLM Reference - http://davenport.sourceforge.net/ntlm.html

Additional EPA Reference - https://blogs.msdn.microsoft.com/openspecification/2013/03/26/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication/

Implementation - https://cs.chromium.org/chromium/src/net/ntlm/?q=ntlm&sq=package:chromium

Summary

Implement NTLMv2 on non-Windows platforms with Extended Protection for Authentication (EPA) support.

Original State - Chromium on non-Windows only supports NTLMv1.

Current State - Replacement implementation of NTLM landed with unit tests and fuzzers. New implementation supports NTLMv1, NTLMv2 and Extended Protection for Authentication. Currently NTLMv1 is still the default (ie. no behavior change)

Planned M63 - Add a flag that allows users to enable the new NTLMv2 behavior.

Planned Post M63 - Make NTLMv2 the default NTLM protocol version and allow users to set the flag to go back to the old (less secure) version.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The feature was already supported on Windows by virtue of system API’s. This adds support to all remaining platforms.

Demo link

N/A

Debuggability

NTLM messages are sent in HTTP headers. The headers can be viewed in the existing developer tools. The messages are base 64 encoded strings of a binary format (defined by MS-NLMP specification). There are no additional tools provided to introspect the content of the messages. This was the existing behavior for NTLMv1 and is consistent with other browsers and with Chrome on Windows.

Risks

Interoperability and Compatibility

Windows Firefox, Edge, IE, Safari, Chrome/Chromium - NTLMv2 already supported and default for many years. Using Windows system libraries.

Non-Windows Safari - Supports NTLMv2 but doesn’t support Extended Protection for Authentication (EPA). NTLMv2 is the default.

Non-Windows Firefox - Supports NTLMv2 but doesn’t support Extended Protection for Authentication (EPA). NTLMv2 is the default. A flag exists to optionally downgrade to NTLMv1.

Proposed Non-Windows Chromium - Support NTLMv2. NTLMv2 is the default protocol version. Supports Extended Protection for Authentication. This brings Chrome to feature parity with all Windows versions of all major browsers, and makes Chrome the only non-Windows browser to support EPA. We will provide a flag/policy to allow downgrading to NTLMv1.

Proposed Windows Chrome/Chromium - No changes are necessary. This is already supported.

Enabled Scenarios

• Chrome on non-Windows platforms can now be used in environments that disable NTLMv1 (Microsoft’s recommended configuration)

• Chrome on non-Windows platforms can be used in environments that additionally enable Extended Protection for Authentication (EPA). This is also relevant because EPA is enabled for both Kerberos and NTLM with the same setting. Chrome would be the only browser that can authenticate from a non-Windows platform with EPA enabled on the server.

Since the protocol version in NTLM is not negotiated, both client and server are configured at the machine level as to which version they send and which version they accept. Current defaults and recommendation in Windows machines are that Servers only accept NTLMv2 (hence current Chrome clients can’t authenticate) and that clients send NTLMv2 (Chrome would start sending NTLMv2 by default after this change).

Implementation Sequence

• Replace existing NTLMv1 implementation. The current code was copied from Firefox and has no tests. Verify with unit tests that the implementations are compatible. DONE.

• Add a new NTLMv2 implementation (but leave it disabled). DONE.

• Add a flag that allows enabling NTLMv2. Planned for M63

• Change the flag default so that NTLMv2 is the default. Planned post M63.

User Impact

• If a server only supports NTLMv1, a browser that sends NTLMv2 will not be able to authenticate. This would be a behavior change for Chrome on non-Windows, but it would make it consistent with Chrome on Windows and all other major browsers. Chrome will provide a flag/policy to downgrade to the previous behavior. All supported versions of Windows and Samba support NTLMv2 so this case should be limited.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

No web platform tests. Implementation is unit tested and has fuzzers running against both versions of the protocol.

Entry on the feature dashboard

TODO;

[Chris Harrelson]

Hi,

Thanks for sending a note about this feature. Please forgive any naive questions I may have, I am not at all an expert in this area. :)

As best as I can tell, this protocol is not observable from a web page via any web APIs. Is that correct? (Just being visible in devtools doesn't count, because devtools has some superpowers.) If so, then I don't think it needs to be processed through the Blink Intent process.

Thanks,

Chris

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

[David Benjamin]

cbentzel can correct me if I'm out of date, but I think we've typically used the Blink process for network-level changes, even though they don't lead to API changes per se.

It's not the exact same scenario---usually IETF, not W3C, so TAG review isn't applicable, and the network has different considerations across the board than what you all typically deal with---but I've personally found it to be quite valuable. You all are a great sounding board when it comes to risk, and just the exercise of writing things up under Blink templates is useful. (And, of course, the process with the feature dashboard and friends makes sure information shows up in the right places ultimately.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABO%2BUTqq%3DQ4Gr63bPL0rcf6uha-5tjinSfU2WjuGdbBkhHtTFA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qovVAm75rhwVXFOjRf34D02j1MDYOLrd%3DhSX3CCSyjw%40mail.gmail.com.

[Zentaro Kavanagh]

cbentzel@ suggested it would not hurt to do this.

This change may also be unusual in the sense that it isn't really adding anything new, it's just bringing feature parity to other browsers/platforms.

I'm not that familiar with the process so I'm not sure how much of it really applies here. Worst case this is just an FYI :)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABO%2BUTqq%3DQ4Gr63bPL0rcf6uha-5tjinSfU2WjuGdbBkhHtTFA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Chris Bentzel]

This would be visible to servers but not DOM necessarily. As David has said, we have still been following blink process for externally visible network changes, and this falls under that bucket.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABO%2BUTqq%3DQ4Gr63bPL0rcf6uha-5tjinSfU2WjuGdbBkhHtTFA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Chris Harrelson]

I agree with that ("externally visible network changes through the Blink API process"). As stated, my comments were over-broad, sorry about that.

However, I do get the feeling that this particular protocol is somewhat special, because of its restriction to authentication in Microsoft networks (intranet-specific I presume?). I will follow up off-thread to learn more.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABO%2BUTqq%3DQ4Gr63bPL0rcf6uha-5tjinSfU2WjuGdbBkhHtTFA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qovVAm75rhwVXFOjRf34D02j1MDYOLrd%3DhSX3CCSyjw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAuiYA__A2gET%2BGdOY3t7cjvvh8a-541RjGs%2Bu1ZOft60943mQ%40mail.gmail.com.

[Ryan Sleevi]

Hi Chris (H)

This isn't Microsoft-specific - a number of cross-platform implementations exist, particularly in the SSO-space :) And it's Web-visible through a sense of RFC 4559 (and, indirectly, things like Fetch and XHR, which can pass on credentials which would then use the appropriate mechanisms). So while the support for NTLMv2 isn't DOM-visible, it's DOM-reachable via such APIs.

Note that NTLM (and Negotiate) also bring on their own behaviours - because they're connection-based auth methods (a violation of the HTTP RFCs that was shipped early in the Microsoft days), support for them has brought along its own set of concerns. It's why the Fetch spec has to consider connection groups and credentials - because a socket may be imbued with ambient authority if it was previously used for these authentication methods, even if the Fetch request itself is no-credentials :)

So, to some extent, this does have a host of interoperability concerns. In particular, this will grant Chrome on non-Windows platforms the ability to talk to servers (both Windows and non-Windows) that are configured to require NTLMv2 (the Microsoft-recommend configuration), and brings us in closer alignment with both Safari and Firefox (which both support NTLMv2).

Hope that captures some of the salient details :)

[Chris Harrelson]

I discussed offline with Zentaro and now understand better what is going on. Thanks for your patience. I also appreciate the positive comments regarding the usefulness of the Blink API owners process. :)

LGTM1 to ship, as this is an extension of a de facto and widely deployed authentication standard to all platforms, and also leads to increased interoperability between browsers. It also improves security through the new version of the protocol plus additional protection features.

Please don't forget to create a chromestatus.com entry for this feature.

----

My personal summary below. Most of this is contained above, but perhaps repeating it makes it more clear for more folks.

NTLM:

 - is an authentication mechanism for users to access controlled content (e.g. access-controlled intranet sites). It's an alternative to other mechanisms like Kerberos. In general any web server has the potential to use NTLM for authentication, though it seems to be generally Microsoft servers which do so.

 - has a spec (linked to by Zentaro in the original email), and is a de facto standard in that it is supported by all major browsers, and also has some references from elsewhere, such as RFC 4559. The spec does not have a lot of update churn on it, and it is technically controlled/updated by Microsoft and no other parties.

 - is widely used in Windows intranet and other Windows-dominant areas.

 - NTLMv2 is an updated version of NTLMv1, which has significantly improved security against attacks. The additional EPA (aka channel binding) and MIC features (see original email) proposed to be implemented provide additional security protections, especially against man-in-the-middle attacks.

 - No other browser currently implements the EPA and MIC features on non-Windows platforms, though we anticipate this being done in the future. All browser, including Chrome, already implement v2 plus EPA and MIC on Windows.

[Dimitri Glazkov]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABO%2BUTqq%3DQ4Gr63bPL0rcf6uha-5tjinSfU2WjuGdbBkhHtTFA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qovVAm75rhwVXFOjRf34D02j1MDYOLrd%3DhSX3CCSyjw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAuiYA__A2gET%2BGdOY3t7cjvvh8a-541RjGs%2Bu1ZOft60943mQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-SKXym7WjYcOPkweAP7YGutxScudPvB5XL7%2BUZPWb%2Bfw%40mail.gmail.com.

[Philip Jägenstedt]

LGTM3 (skimmed and looked at chrishtr@'s remarks)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx4k5-CHLFJT0i96UGMYiwL2AwMAMqR1vHrcFB9A83Lq8g%40mail.gmail.com.

[Matt Blumberg]

Seems like folks are OK with the write up-  who is taking lead on the chromestatus.com piece as well as external comms? I'd like to stay connected and relay enterprise feedback to that person.

Thanks

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABO%2BUTqq%3DQ4Gr63bPL0rcf6uha-5tjinSfU2WjuGdbBkhHtTFA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qovVAm75rhwVXFOjRf34D02j1MDYOLrd%3DhSX3CCSyjw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAuiYA__A2gET%2BGdOY3t7cjvvh8a-541RjGs%2Bu1ZOft60943mQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-SKXym7WjYcOPkweAP7YGutxScudPvB5XL7%2BUZPWb%2Bfw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[David Benjamin]

I believe usually the person who sends the Intent mail fills in the chromestatus.com entry before sending it. Zentaro?

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABO%2BUTqq%3DQ4Gr63bPL0rcf6uha-5tjinSfU2WjuGdbBkhHtTFA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qovVAm75rhwVXFOjRf34D02j1MDYOLrd%3DhSX3CCSyjw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAuiYA__A2gET%2BGdOY3t7cjvvh8a-541RjGs%2Bu1ZOft60943mQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-SKXym7WjYcOPkweAP7YGutxScudPvB5XL7%2BUZPWb%2Bfw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Daniel Vogelheim]

On Tue, Oct 10, 2017 at 7:02 PM, 'Ryan Sleevi' via blink-dev <blin...@chromium.org> wrote:

Note that NTLM (and Negotiate) also bring on their own behaviours - because they're connection-based auth methods (a violation of the HTTP RFCs that was shipped early in the Microsoft days), support for them has brought along its own set of concerns. It's why the Fetch spec has to consider connection groups and credentials - because a socket may be imbued with ambient authority if it was previously used for these authentication methods, even if the Fetch request itself is no-credentials :)

Thanks for the explanation; the mix-up of connection-level authentication with the browser's per-request model is indeed a bit concerning.

Zentaro, have you added tests that verify whether connection groups for NTLMv2 indeed segregate requests with/without credentials and different cookie settings (e.g. 3rd-party cookie blocking)?

[Ryan Sleevi]

Zentaro's CL does not change the behaviour from NTLMv1 here; this applies to both NTLM and Negotiate-level auth, and they won't function without that behaviour. The broader question - of whether auth credentials are segregated - is handled by the higher level of the stack, and is also unchanged. That is, this changes what the tokens return, but does not change the overall authentication handling flow of Chromium, which already covers those behaviours.

[Zentaro Kavanagh]

I created the feature on chrome status.

https://www.chromestatus.com/feature/5726380163596288

[Mike West]

I read this as saying "Yes, we have tests that authenticated connections in general are segregated from non-authenticated connections, and NTLM's particulars are sufficiently covered.", in which case I'm happy. :)

-mike