ONVIF Gurus: Is There A Valid Reason For Getsystemdate To Require Authentication?

I've been working on connecting to a few ONVIF cameras using netcat (don't ask why).

Not too many problems actually, but this one camera an Everfocus EAN-3220 model, is giving a SOAP Sender not authorized message right on the first GetSystemDateAndTime call. And therefore not returning a time for me to hash my nonces with. Even after resetting to defaults.

If I just ignore it and md5 with my local time and do GetCapabilities then it's ok, but I'm trying to understand what the point of the first rejection is. It's not a http 401 either.

Is there a valid use case for such behavior?


...maybe it's just so they can exclude any camera manufacturers who threaten to sue them over patent infringement from connecting via 'their' onvif? ; )

I think you must be joking or something?!? cuz that's ridiculous!

Look, if that were the actually case they would need to set the onDateRequest headers to request initiateLegalAction with temporaryInjunction bit flipped to true.

Which they didn't, but it doesn't surprise me either.

What are the odds that they've decided to protect an internet facing camera against a denial of service attack that attempts to exploit the GetSystemDateAndTime call?

Ok, but you would have to explain more about how it might work.

The function itself puts minimal load on the server since it only returns the system date. In addition when it fails, it ends up returning a much bigger object since it includes all these ONVIF required error headers. So one would think it puts more of a strain to fail.

The thing that's messed up about it is that I wouldn't give a crap about getting the date/time except that you need to do the encryption with a timestamp mashed together with the username password, and if the timestamp in the encryption is off by more than 5 seconds, the camera will reject it.

But still it's possible it's some sort of defense to something. Thanks for answering!

I think I remember reading somewhere that minimal GetSystemDateAndTime deltas are somehow necessary for PTZ control and other time critical functionality. Perhaps the Everfocus developers just decided that this should be a prerequisite for authentication. Wireshark packet analysis of an Everfocus NVR connecting to the camera may reveal some additional insight.

I'm not sure. I did wireshark it connecting to ONVIF Device Manager and was surprised when it connected. Looking in the trace I saw that it issued the GetDate command several times and got the same error I did, which was comforting.

But it just moved on to another request like GetCapabilities and that didn't need auth, and then it just went from there. So I did the same, but not really happy about coding one off BS like that.

Everfocus has some other peculiar behavior with their GetUri responses. They return with both invalidAfterConnect and invalidAfterReboot flags set to true, which ONVIF says should always be set to false. This means that you need to call GetUri for every snapshot you request, even though it returns the same uri. If you don't you get a 404.

GetSystemDateAndTime should not require authentication at all. See http://www.openipcam.com/files/ONVIF/ONVIF_WG-APG-Application_Programmer's_Guide.pdf

Agreed.

Usually it's the other way around, they don't flip the lock when they should, so I am thinking maybe there was some reason.

BTW, do they support HTTP-Digest for authentication (an alternative way that do not need timestamp)? Their ONVIF Feature List says no (Digest feature missed). It also says their ONVIF module is just set of CGI scripts (ex: http://192.168.0.126:80/cgi-bin/deviceMgmtOvf.cgi or http://192.168.0.126:80/cgi-bin/eventOvf.cgi) - so maybe this problem is just misprint.

No, ONVIF only allows for the SOAP digest authentication. Worse than that you still need to code for the HTTP digest because ONVIF allows the webserver to use it for httpd acl, so sometimes you need to do both. But you ALWAYS have to do the SOAP method, if the method requires auth.

>>But you ALWAYS have to do the SOAP method

Is it something from spec, or some experienced-based rule of thumb?

My understanding is a bit different (please refer to http://www.onvif.org/specs/core/ONVIF-Core-Specification-v261.pdf):

- from 5.12.1 there is a clear statement: "A client should not simultaneously supply authentication credentials on both the HTTP level and the WS level. If a server receives a web service request that contains authentication credentials on both the HTTP level and the WS level, it shall first validate the credentials provided on the HTTP layer. If this validation was successful, the server shall finally validate the authentication credentials provided on the WS layer." So, is client supply both - server will validate both (btw, they may be different), but in typical case client should not do so.

- from 5.12.2.3 we can peek definition of access classes. comparing with 5.12.2.4, where default access policy defined, and 8.3.6 (description of GetSystemDateAndTime) command, we can deduce that camera should not ask for credentials if it is using default access policy.

why it may actually asks:

- somebody changed access policy, via web interface or via SetAccessPolicy command (see 8.4.2). you may try reset it via web interface.

- code misprint on camera side (btw, not an issue from ONVIF conformance procedure, as it does not checking access levels).

- code misprint on client side: I seen combinations of clients and servers where client were supplying malformed credentials (like <wsse:Security/> with empty content) and servers treat this not as "no credentials" but "wrong credentials" (even for commands that do not need authentication).

"A client should not simultaneously supply authentication credentials on both the HTTP level and the WS level. If a server receives a web service request that contains authentication credentials on both the HTTP level and the WS level, it shall first validate the credentials provided on the HTTP layer. If this validation was successful, the server shall finally validate the authentication credentials provided on the WS layer"

And so what should a client do when it gets a straight-up 403 on the SOAP call, before ONVIF gets a chance to even look at it?

The ONVIF recommendation is just use HTTP Digest and omit WS-Security (can't find exact place in spec, sorry - will try tomorrow).

so, if device is forcing you to provide both (HTTP & SOAP) for commands that requires authorization - it is not conformant.

BTW, please refer to http://www.onvif.org/Portals/0/documents/testspecs/v15_06/ONVIF_Base_Test_Specification_15.06.pdf, 3.3.6 - this is the description of algorithm used by ONVIF Test Tool to deal with device during test procedure (the very beginning step - so called feature definition procedure).

Please also check test procedures described in 8.1 and 8.2. It look like device instance you are dealing with can't pass these tests. Maybe it is not conformant (this instance == hardware + firmware version).

The ONVIF recommendation is just use HTTP Digest and omit WS-Security (can't find exact place in spec, sorry - will try tomorrow).

For whom and when is that the recommendation? Are you saying that the server can be written without ws-security? Or that the client doesn't need to use it?

second. client should use only one digest. and if server wants HTTP-Digest - just give it.

please look into 3.3.6. in brief: try no credential for operation that need credential. server will reply either:

correct answer - server is not using authorization

401 - server expect HTTP-Digest

SOAP Fault - server expect WS-Security

and as server should not expect both - client can deduce, what kind of authorization it should use later.

from ProfileS perspective (see http://www.onvif.org/Portals/0/documents/op/ONVIF_Profile_%20S_Specification_v1-1.pdf, chapter 7.1), server should support at least WS-Security (may support HTTP-Digest), but client should support both - so client to define what server expect.

First, thanks Alexander for effort put into the posts, it's helped.

Though it is still incoherent to me. Why?

Because if the server MUST support WS-Security AND the client should NOT include dual digests (SOAP and HTTP), then I fail to see how the client would ever need to use HTTP Digest at all.

And if the server can return 401s and force the client to use http digest, couldn't it always due that and thereby avoid using the "mandatory" ws-security?

You are welcome!

The key point is here:

The server must SUPPORT WS-Security and the client must SUPPORT both. This does not mean they should use them in particular communication at all.

"Should support" for server mean that client should reasonably expect that server will ask for WS-Security and/or if client will provide WS-Security this brings no harm. look into opposite: server should support WS-Security - not a word for HTTP-Digest, which mean that if client will use HTTP-Digest there is a chance that server will return an error as it has the right not to support HTTP-Digest.

"Should support" for client mean that server can decide on it's own to use HTTP-Digest, WS-Security or nothing. And there client should fulfil server's expectations (see 3.3.6).

conclusion: should support != should use

Ok. But in a practical sense, since I know that the server MUST support SOAP Auth, and MAY NOT support HTTP digest, why not just use ws-security to reduce complexity and footprint?

As far as my "You always have to use SOAP Auth", I agree that this is not correct, and I would modify it to

"You always have to be able to use SOAP Auth."

But of course, this is just spec talk, and in reality I have found the need to use one or the other and both to actually talk to as many servers as possible.

So really, there is nothing that I won't try, because not connecting is not an option.