Add support for HTTP Basic authentication over TLS-protected connections (RFC 7617)

[bsriramprasad]

Add support for HTTP Basic authentication only over TLS-protected connections (RFC 7617)

Motivation

As ONVIF devices increasingly operate in cloud-connected and TLS-only deployments, the current specification's exclusive reliance on HTTP Digest authentication creates friction for modern integration patterns:

• Cloud and proxy architectures: - Digest binds its response hash to the request URI, so it breaks whenever a gateway rewrites paths. A cloud service addressing cameras as /devices/cam-42/onvif/device_service and forwarding to /onvif/device_service invalidates every Digest response. The gateway must then authenticate to each device itself, which means storing an HA1 per device. Basic is stateless and path-independent, so it forwards unchanged. The trade-off is that it requires TLS with validated certificates.

• Regulatory direction: The EU Cyber Resilience Act and NIS2 push deployments toward encrypted-by-default transport, making TLS-everywhere a common baseline.

• Interoperability with standard HTTP clients and tooling: HTTP Basic works out of the box in every HTTP client library, browser, and automation tool. Digest needs custom handling and is missing from many stacks.

This change introduces HTTP Basic authentication as an optional, TLS-only feature with an explicit capability signal (HttpBasic).

Compatibility Analysis

Aspect	Impact
Backward compatible	A device supporting Basic shall also support digest and include a Digest challenge in every 401 response. Existing Digest-only clients see unchanged behaviour and need not be aware of Basic.
Capability signalling	HttpBasic is optional; per existing Core convention, an omitted capability indicates the device does not support it.
Profiles	No profile requirements change. HTTP digest remains mandatory wherever profile specifications require it; this PR does not amend any profile document.
Discovery	Clients negotiate via the WWW-Authenticate challenge as HTTP requires; the capability is for configuration and planning, not negotiation.
Schema	New optional HttpBasic boolean attribute in devicemgmt.wsdl (GetServiceCapabilities path).
Security Service	No changes. All edits are scoped to Core and the Device Management WSDL.

Normative Requirements

A device that supports HTTP Basic authentication shall signal the HttpBasic capability as true and shall:

1. accept a request carrying an Authorization header using the Basic scheme over a TLS-protected connection, even if no challenge was sent;
2. include a Basic challenge in the WWW-Authenticate header of each 401 response sent over a TLS-protected connection;
3. respond with 401 and a WWW-Authenticate header offering only digest authentication when Basic credentials are received over a connection that is not TLS-protected;
4. support digest authentication and include a Digest challenge in the WWW-Authenticate header of each 401 response.

Each requirement maps to a conformance assertion:

Requirement	A device fails it by
2	advertising a Basic challenge over plain HTTP
3	accepting Basic credentials over plain HTTP
4	supporting Basic without digest

Summary of Changes

doc/Core.xml

Section	Change
Normative references	Added RFC 7617
Authentication over HTTP and HTTPS	Added HTTP Basic over TLS-protected connections as an authentication exception alongside existing exceptions (WS-UsernameToken, TLS client auth, JWT)
Authentication over HTTP and HTTPS	Added four normative requirements for devices supporting Basic (see above)
Authentication over HTTP and HTTPS	Scoped the credential-management sentence to digest and HTTP Basic
Authentication over HTTP and HTTPS	Listed HTTP Basic over TLS-protected connections as an accepted authentication method for RTSP and HTTP methods
GetServiceCapabilities table	Added HttpBasic row to Security capabilities (updated morerows count)
Appendix (new)	HTTP Basic challenge-response example over a TLS-protected connection
Revision history	Added entry

wsdl/ver10/device/wsdl/devicemgmt.wsdl

Section	Change
SecurityCapabilities	Added HttpBasic boolean attribute

References

• RFC 7617 - The 'Basic' HTTP Authentication Scheme
• RFC 7616 - HTTP Digest Access Authentication (existing reference)
• RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication (existing reference)

[MariaYa0091]

Is HTTP Basic authentication really to be applicable for RTSP?

[bsriramprasad]

RTSP 1.0 mandates Basic

• https://datatracker.ietf.org/doc/html/rfc2326#appendix-D.2.2

RTSP2.0 does not mention Basic

• https://datatracker.ietf.org/doc/html/rfc7826#section-19.1

[bsriramprasad]

Additional clarification on usage of basic for RTSP

[MariaYa0091]

General note:

It could a bit of backward compatibility issue for clients. They could expect no HTTP digest for HTTPS connection (as it was required before).

Also for all currently existing profiles using of HTTP digest for HTTPS to be the expected behavior. There were no exceptions before.

[bsriramprasad]

General note:

It could a bit of backward compatibility issue for clients. They could expect no HTTP digest for HTTPS connection (as it was required before).

Also for all currently existing profiles using of HTTP digest for HTTPS to be the expected behavior. There were no exceptions before.

Latest changes addresses your concern.

[ocampana-videotec]

@bsriramprasad what problem are we trying to? I am not a fan of HTTP basic auth, de facto it is equivalent of removing the password. We already had issues in the past with profile Q, I have the feeling we are repeating the story here.

Small provocation: isn't certificate based client authentication enough?

Adding Basic Auth will imply that by mistake vendor will implement HTTP + Basic Auth, you can take this for granted.

[bsriramprasad]

@ocampana-videotec — taking your points in turn.

Adding Basic Auth will imply that by mistake vendor will implement HTTP + Basic Auth, you can take this for granted.

Agreed, and that is why the constraint has to be testable rather than advisory. Profile Q's mitigation was deployment guidance. This one is normative and checkable. The requirements now in the PR:

1. Accept preemptive Basic credentials over a TLS-protected connection.
2. Include a Basic challenge only in 401 responses sent over a TLS-protected connection.
3. Respond 401 with a Digest-only challenge when Basic credentials arrive over a connection that is not TLS-protected.
4. Support digest authentication and include a Digest challenge in every 401 response.

Each maps to a conformance assertion:

Requirement	A device fails it by
2	advertising a Basic challenge over plain HTTP
3	accepting Basic credentials over plain HTTP
4	supporting Basic without digest

We can work with the tool vendor to test it well.

We already had issues in the past with profile Q, I have the feeling we are repeating the story here.

I would argue the comparison does not hold on the points that mattered. Profile Q mandated anonymous access to all commands in the factory default state, and because profile specifications cannot be amended without breaking interoperability, deprecation was the only remedy available. This is optional, capability-gated, requires the full credential rather than removing authentication, and sits in Core — revisable in any future release.

The lesson I do take from Profile Q is the one above: advisory mitigation is insufficient, so the constraint belongs in conformance testing.

de facto it is equivalent of removing the password

Core already permits JWT bearer tokens over HTTPS, and a bearer token is equally a plaintext credential in a header protected solely by the transport. The Security Service also specifies client_secret_basic — HTTP Basic in the Authorization header over TLS — as an accepted method for protecting the device's own OAuth 2.0 client secret. The security judgement for Basic-over-TLS is therefore already made in the specification; this applies it to the inbound direction, where TLS protects identically.

The one case where Basic is genuinely worse is a client that does not validate the server certificate: a MITM can present a Basic-only challenge and recover the password, where Digest would yield only a spent nonce. That is a real gap and I would propose closing it explicitly:

A client shall validate the server certificate before sending credentials using the Basic scheme.

Small provocation: isn't certificate based client authentication enough?

mTLS binds authentication to the TLS connection, so it survives only where TLS is passed through to the device. Any intermediary that terminates TLS breaks it — which is the deployment this addresses. It also carries per-client certificate issuance, renewal, and revocation overhead. It is already permitted in Core and has not displaced digest in practice.

what problem are we trying to [solve]?

Interoperability with TLS-only deployments and with architectures where digest cannot be forwarded. Digest binds its response hash to the request URI, so it survives an intermediary that preserves the path but breaks under path rewriting — which is how most multi-tenant cloud fleets are addressed. It also degrades in stateless environments such as autoscaled gateways and serverless invocations, where the nonce counter has nowhere to live.

Authentication mechanisms in ONVIF

Client → Device (inbound)

	WS-UsernameToken	HTTP Digest	X.509 / TLS client cert	JWT (Bearer)	HTTP Basic (proposed)
Capability	UsernameToken	HttpDigest	X.509Token	JsonWebToken	HttpBasic
ONVIF status	Legacy	Mandatory	Optional	Optional, HTTPS only	Optional, TLS only
Works for RTSP	No	Yes	Yes	Yes	Yes
Credential on wire	SHA-1 digest	MD5 or SHA-256 digest	Certificate	Signed token	Base64 password
Survives TLS termination at an intermediary	Yes	Yes	No	Yes	Yes
Survives path rewriting by an intermediary	Yes	No	n/a	Yes	Yes
External infrastructure	None	None	PKI + per-client lifecycle	OIDC authorization server	None
Identity managed by	SetUser	SetUser	Keystore + validation policy	SetJWTConfiguration + external issuer	SetUser

Device → Authorization Server (outbound)

Defined in the ONVIF Security Service Specification for OAuth 2.0 client registration:

Method	Credential	Reference
client_secret_basic	client_secret in HTTP Authorization header	RFC 6749
client_secret_post	client_secret in HTTP POST body	RFC 6749
client_secret_jwt	HMAC-signed JWT using client_secret	OpenID Connect Core
private_key_jwt	PKI-signed JWT using private key	OpenID Connect Core
tls_client_auth	mTLS with CA-issued X.509 certificate	RFC 8705
self_signed_tls_client_auth	mTLS with self-signed certificate	RFC 8705

Gap addressed by this proposal. No existing inbound mechanism survives both TLS termination and path rewriting at an intermediary without requiring external infrastructure:

• Digest needs no infrastructure but breaks under path rewriting; re-originating it at a gateway means storing HA1 — unsalted and password-equivalent — for every device.
• TLS client certificates need no external identity provider but do not survive TLS termination.
• JWT survives both but requires an OpenID Connect authorization server, client registration, and key distribution — reasonable for an enterprise VMS, disproportionate for a small integrator, a test harness, or a device being commissioned before identity infrastructure exists.
• WS-UsernameToken is SOAP-only and legacy.

Basic is the only mechanism that clears both conditions using device-local credentials with no external infrastructure. It is additive — digest remains mandatory in every 401 — so no existing deployment or client is affected.