Digest challenge - realm fails with empty string

[camillo-toselli]

The issue is similar to #50283 but this time about realm key. For example:

	WWW-Authenticate : Digest realm="", nonce="NjBGRkMxNjUgY2FiN2YxZDM1MWM4ZDAyOTRiMmY2ZGVjOGMxMDY2Zjg=", algorithm="MD5", qop="auth"

will fail with error Nonce missing

RFC7616 says realm SHOULD contain al least the name of the server, but not MUST contain, so it doesn't exclude an empty realm

	This string should contain at least the name of the host performing the authentication
	and might additionally indicate the collection of users who might have access.

This lines of method Parse in class System.Net.Http.AuthenticationHelper.DigestResponse

	// Ensure value is valid.
	// Opaque and Domain can have empty string
	if (value == string.Empty &&
	   (!key.Equals(Opaque, StringComparison.OrdinalIgnoreCase) && !key.Equals(Domain, StringComparison.OrdinalIgnoreCase)))
	    break;

should be modified to allow empty Realm value

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

The issue is similar to #50283 but this time about realm key. For example:

WWW-Authenticate : Digest realm="", nonce="NjBGRkMxNjUgY2FiN2YxZDM1MWM4ZDAyOTRiMmY2ZGVjOGMxMDY2Zjg=", algorithm="MD5", qop="auth"

will fail with error Nonce missing

RFC7616 says realm SHOULD contain al least the name of the server, but not MUST contain, so it doesn't exclude an empty realm

This string should contain at least the name of the host performing the authentication
and might additionally indicate the collection of users who might have access.

This lines of method Parse in class System.Net.Http.AuthenticationHelper.DigestResponse

// Ensure value is valid.
// Opaque and Domain can have empty string
if (value == string.Empty &&
   (!key.Equals(Opaque, StringComparison.OrdinalIgnoreCase) && !key.Equals(Domain, StringComparison.OrdinalIgnoreCase)))
    break;

should be modified to allow empty Realm value

Author:	camillo-toselli
Assignees:	-
Labels:	area-System.Net, untriaged
Milestone:	-

[karelz]

Triage: Seems legit. Are you interested in submitting PR for it?
Otherwise, moving to 7.0. Should be fairly straightforward to fix.

[bompani]

Is it possible to backport this fix to release/5.0 branch too?

[karelz]

@bompani we could if there is enough demand. What is impact on you / your customers? How many are affected? How much? Why is it critical for your app?
Also note that 6.0 just released RC1 which is go-live license. Given that it is LTS and will be supported much longer than 5.0, is it an option for you to upgrade to 6.0?

[bompani]

Our app is a wab service that manages the telephony system of the University of Bologna. It's one of the biggest private telephony network based on asterisk, with about 10000 phone lines.
Without this fix the web service is not able to invoke the web API of some desktop phone models that require digest authentication with an empty realm.
The web service persistence layer is based on an Oracle database accessed through Entity Framework Core. We will not be able to upgrade to .NET 6.0 until Oracle will release the Oracle EF Core 6 provider.

[karelz]

@bompani so, you are making new deployment to new customer(s) where you found out in production that it does not work? Is that correct?
Or did it work earlier and stopped working suddenly? (What triggered it in that case?)
How many customers / Desktop phone models are directly impacted by this bug?

[bompani]

We upgraded our ws from dotnet core 3.1 to .net 5.0 but we will not be able to deploy the new ws in production until this issue will be resolved. This issue was not present in dotnet core 3.1.

[karelz]

Did you use have SocketsHttpHandler disabled on 3.1 by a chance? https://docs.microsoft.com/en-us/dotnet/api/system.net.http.socketshttphandler?view=net-5.0#remarks

[bompani]

I apologize because I reported a wrong information: the production version of out ws is developed with .NET Framework 4.5 not .Net core 3.1. Before the porting of our ws to .NET 5.0 we developed an intermediate version with .NET core 3.1 but I don't kwow if the digest authentication was working in that version.

[bompani]

Are there any chances that this fix will be merged into the 5.0 branch? Thanks

[karelz]

@bompani yes, there is still a chance -- I kicked off the servicing process in PR #61203

[karelz]

@bompani will you be able to validate on private (unsigned) binaries that the fix addresses your problem?

[bompani]

Yes I'm able to validate on private binaries. Can I download the PR buld or have I to build it myself?

[karelz]

Great!
Building it yourself is of course an option.

The PR has build artifacts - libraries_bin_* e.g.:

• Windows x64 Debug
• Windows x86 Release

Grab System.Net.Http.dll (in directory bin\runtime\net5.0-Windows_NT-Debug-x64 of the zip) and replace it in your local installation (tip: make a copy of the original file first). The debug build should work with locally-installed release build, but I am not 100% sure -- if you hit any problems, let me know (I would build binaries you need locally - I would need the OS/bitness info you need), or you can compile it yourself if you are set up to do that.
Run the repro before replacing the binary to make sure it repros and then after you replace the binary to make sure it works correctly with the new bits.

[bompani]

I can confirm that the PR build resolves our problem.
Thanks.

[karelz]

Thanks for validation @bompani!
Which OS / architecture did you validate? Did you use the build artifacts, or your local build?

[bompani]

I validated my local build of branch backport/pr-56455-to-release/5.0 on Windows10/x64

[karelz]

Thanks for confirmation @bompani!

[karelz]

The bug is fixed:

• in 6.0 (in PR accept empty realm for digest auth (#56369) #56455)
• in 5.0 servicing (in PR [release/5.0] accept empty realm for digest auth (#56369) #61203) - scheduled for release in 5.0.13 (rough ETA: mid-December)