Bug 2128895

Summary: Ensure httpd mod_auth* modules send multiple challenges through separate WWW-Authenticate headers
Product: Red Hat Enterprise Linux 9 Reporter: Aaron Ogburn <aogburn>
Component: httpdAssignee: Luboš Uhliarik <luhliari>
Status: NEW --- QA Contact: rhel-cs-infra-services-qe <rhel-cs-infra-services-qe>
Severity: medium Docs Contact:
Priority: high    
Version: 9.4CC: luhliari, nbhumkar, trehiopa
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aaron Ogburn 2022-09-21 20:25:17 UTC
Description of problem:

Adding GssapiBasicAuth to mod_auth_gssapi results in multiple challenges in a single WWW-Authenticate header, for example:

WWW-Authenticate: Negotiate, Basic realm="Realm Name"


But that may not be handled by all client user agents.  For example firefox and curl are seen to no longer provide their kerberos ticket (https://curl.se/mail/lib-2020-01/0064.html) in this case.

A workaround can be to have mod_headers set the needed challenges in separate headers:

Header set WWW-Authenticate Negotiate
Header add WWW-Authenticate "Basic realm=\"Realm Name\""


I see by the HTTP spec, it is not wrong for a server to include multiple different challenges in WWW-Authenticate header as it is clearly allowed:

https://www.rfc-editor.org/rfc/rfc9110.html#name-www-authenticate
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate

"A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge. A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response. A proxy forwarding a response MUST NOT modify any WWW-Authenticate header fields in that response. User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters."


So it is genuinely a bug and limitation on the client side (the browser and curl) not properly supporting and handling such a WWW-Authenticate header.  The mod_header adjustment then works around any such problem client issue.  It seems clients failing to properly implement the spec in this regard and handle multiple different challenges in one WWW-Authenticate header is a more common client issue:

"Some user agents do not recognize this form, however. As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable."


So we should consider ensuring mod_auth_gssapi and other mod_auth* modules sends challenges through separate WWW-Authenticate headers as a more universally compatible option.


Version-Release number of selected component (if applicable):

 httpd-2.4.51-7.el9_0

Actual results:

Multiple challenges in a single WWW-Authenticate header may not be compatible with all client user agents


Expected results:

Multiple challenges are sent in separate WWW-Authenticate headers