Enterprise authentication tests are failing with PlatformNotSupportedException

[wfurt]

https://dnceng.visualstudio.com/public/_build/results?buildId=1730894&view=logs&j=47c231e8-52e2-5eb6-8574-66afcfcee82a&t=df5b78b1-c065-5bb1-4636-fc7a07ab8e6a

   Starting:    System.Net.Http.Enterprise.Tests (parallel test collections = on, max threads = 4)
      System.Net.Http.Enterprise.Tests.HttpClientAuthenticationTest.HttpClient_ValidAuthentication_Success(url: "http://apacheweb.linux.contoso.com/auth/kerberos/", useDomain: False, useAltPort: False) [STARTING]
  Unhandled exception. System.PlatformNotSupportedException: Requested protection level is not supported with the GSSAPI implementation currently installed.
     at System.Net.Security.NegotiateStreamPal.InitializeSecurityContext(SafeFreeCredentials& credentialsHandle, SafeDeleteContext& securityContext, String spn, ContextFlagsPal requestedContextFlags, Byte[] incomingBlob, ChannelBinding channelBinding, Byte[]& resultBlob, ContextFlagsPal& contextFlags) in /repo/src/libraries/Common/src/System/Net/Security/NegotiateStreamPal.Unix.cs:line 384
     at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatusPal& statusCode) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 215
     at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean thrownOnError) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 201
     at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 182
     at System.Net.Http.AuthenticationHelper.SendWithNtAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean isProxyAuth, HttpConnection connection, HttpConnectionPool connectionPool, CancellationToken cancellationToken) in /repo/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs:line 198
     at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken) in /repo/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs:line 1033
     at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationTo

This seems to be regression from #66879 @filipnavara. I look at the change again and nothing obvious pop up but I sync code just before the change and everything would pass.

It seems to fail on chat that confidentiality is set but was not requested. I don't know why that would matter but I would not expect behavior differences in Kerberos from the managed NTLM.

The test should runable again with #68311

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

https://dnceng.visualstudio.com/public/_build/results?buildId=1730894&view=logs&j=47c231e8-52e2-5eb6-8574-66afcfcee82a&t=df5b78b1-c065-5bb1-4636-fc7a07ab8e6a

   Starting:    System.Net.Http.Enterprise.Tests (parallel test collections = on, max threads = 4)
      System.Net.Http.Enterprise.Tests.HttpClientAuthenticationTest.HttpClient_ValidAuthentication_Success(url: "http://apacheweb.linux.contoso.com/auth/kerberos/", useDomain: False, useAltPort: False) [STARTING]
  Unhandled exception. System.PlatformNotSupportedException: Requested protection level is not supported with the GSSAPI implementation currently installed.
     at System.Net.Security.NegotiateStreamPal.InitializeSecurityContext(SafeFreeCredentials& credentialsHandle, SafeDeleteContext& securityContext, String spn, ContextFlagsPal requestedContextFlags, Byte[] incomingBlob, ChannelBinding channelBinding, Byte[]& resultBlob, ContextFlagsPal& contextFlags) in /repo/src/libraries/Common/src/System/Net/Security/NegotiateStreamPal.Unix.cs:line 384
     at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatusPal& statusCode) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 215
     at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean thrownOnError) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 201
     at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob) in /repo/src/libraries/Common/src/System/Net/NTAuthentication.Common.cs:line 182
     at System.Net.Http.AuthenticationHelper.SendWithNtAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean isProxyAuth, HttpConnection connection, HttpConnectionPool connectionPool, CancellationToken cancellationToken) in /repo/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs:line 198
     at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken) in /repo/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs:line 1033
     at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationTo

This seems to be regression from #66879 @filipnavara. I look at the change again and nothing obvious pop up but I sync code just before the change and everything would pass.

It seems to fail on chat that confidentiality is set but was not requested. I don't know why that would matter but I would not expect behavior differences in Kerberos from the managed NTLM.

The test should runable again with #68311

Author:	wfurt
Assignees:	-
Labels:	area-System.Net.Security
Milestone:	-

[filipnavara]

I will have a look, probably on Monday. The weird thing is that the PR should not change anything at all for Linux builds.

[filipnavara]

Ah, actually there's the change to verify the last token after successful authentication (in AuthenticationHelper.NtAuth.cs). That could be related.

[filipnavara]

FWIW here's the commit that added the check. It may have just never been run for the HTTP authentication because of the ignored last negotiation token. (Furthermore, it is totally valid and normal for NTLM to upgrade to confidentiality.)

[filipnavara]

I managed to reproduce this locally. Removing the extra check from 7fc2995, as done in #68700, does make the problem go away. I'll do some additional tracing to see what is happening.

The exception was thrown for these inputs:

  incomingBlob: A1143012A0030A0100A10B06092A864886F712010202
  outgoingBlob:
  requestedContextFlags: Connection, AcceptStream
  contextFlags: Confidentiality, AcceptStream

This is the MIC check added in #66879. The requestedContextFlags/contextFlags consistency check was previously never executed in the Negotiate scenario and most likely the flags never matched in the first place.

[filipnavara]

Part of the problem is that the CMake check for GSS_KRB5_CRED_NO_CI_FLAGS_X doesn't work. It is never used and the code doesn't even compile. Since the feature doesn't work in the native code it also fails the check in managed code that depends on it.

If I hack it to actually send GSS_KRB5_CRED_NO_CI_FLAGS_X to native API it does the right thing w.r.t. the context flags. I don't even know how to start fixing it though (CMake check is wrong; code needs to be fixed to be compilable with HAVE_GSS_KRB5_CRED_NO_CI_FLAGS_X; GSS_KRB5_CRED_NO_CI_FLAGS_X is sent even for NTLM where it always fails).

[wfurt]

I think it would be OK to have confidentiality on if we have reasonable confidence this is caused by the MIC calculation.
And we will have to anyway since the support is only in 1.14 and above.

[filipnavara]

I think it would be OK to have confidentiality on if we have reasonable confidence this is caused by the MIC calculation.

I don't know what was the original intention with the GSS_KRB5_CRED_NO_CI_FLAGS_X commit from 2016 (which never worked as intended). If it was up to me I would remove the check from the managed side. It's trying to outsmart the native libraries for Kerberos but the same case for NTLM is not checked, and NTLM also optionally upgrades integrity/confidentiality.

And we will have to anyway since the support is only in 1.14 and above.

Apparently the only supported platform with KRB5 older than 1.14 is RHEL7, and even there I am not entirely sure what the deal is. CentOS 7 ships 1.15 at least, and I cannot check if it was ever serviced in Red Hat or not.

[wfurt]

I think we build on Centos7 but I'm not sure how this would work on RHEL7 since we use same binaries.
cc: @tmds

[filipnavara]

I think we build on Centos7 but I'm not sure how this would work on RHEL7 since we use same binaries.

That's what I am seeing, actually. The builds use the runtime dlopen/dlsym shim for all the APIs. The two optional symbols don't exist on RHEL7 which is already tested on the CI. I modified to code in #70447 to support runtime detection of the APIs, as long as the compilation of the GSS shim is done with KRB5>1.14.