Secure Communications Working Group Meeting Two:
Our second Secure Working Group online meeting will be Wednesday, June 13 at:
11:00 am/US-Eastern
16:00 BST
17:00 CEST
8:00 am/US-Pacific
Please Reference Shawn Snider’s updated documentation (v1.3) here: MOS Security and Passive Mode via Web Sockets v1.3
Calendar file here.
Remote Participation:
Via Zoom: https://ap.zoom.us/j/589730143
Voice-only:
United States: +1 646 876 9923
United Kingdom: +44 (0) 20 3695 0088
Germany: +49 (0) 30 3080 6188
Other international numbers available:
https://zoom.us/u/dbWXRdlyd
Meeting ID: 589 730 143
Notes from Secure Communications Working Group Meeting One:
Via Zoom Teleconference
16 May 2018 — 11:00 am/US-Eastern Daylight
Participating:
Shawn Snider (Ross Video)
Mark Gilbert (Gallery)
Jim Stringer (Telescript West)
Mike Palmer (Masstech)
Warren Davis (Bitcentral)
Kai Uwe Kaup (SciSys)
Randall Meston (AP)
Bryan Girdler (AP)
Ryan Berg (AP)
Phil Avner (AP)
Mark Wilson (USV)
Greg Bouzianis (USV)
Sean Cullinan (USV)
Reviewing from MOS Group meeting at NAB 2018:
1. New version will be designated MOS 4.x.
Enables more clarity when deprecating MOS 2.x (no prefixes, suffixes, etc.).
2. Defer deprecation date for MOS 2.x.
Date to be determined after:
Adoption by the group.
Vendors release product that incorporates MOS 4.x.
There is building field deployment.
Passive Mode – Discussion
Recommendation has been made to force “PASSIVE” mode to be the default for MOS 4.x.
To accommodate firewall restrictions.
Both connections would be able to start on one side.
Makes cleaner for networking purposes.
No objections. Subject closed.
SSL Certificates – Discussion
There are valid reasons to support self-signed, as well as from established Certificate Authorities
Downside of CA-issued SSL certificates: The have an expiration date.
Proposal: All MOS devices and NCSes should support self-signed, as well as CA-issued SSL certificates.
There should be an option for an NCS user to disallow self-signed SSL certificates.
Would allow the user to determine how to operate – choose the desired level of security.
Would allow MOS to conform to RFP-style security standards.
Sean Cullinan: Some frameworks do not support self-signed certificates (or don’t support them well).
Problem seen most frequently when dealing with iOS devices.
May not be such an issue with server-to-server connections.
There is no way to be sure that the certificate is correctly identifying.
Shawn Snider (Ross Video): There is generally a way to work around this problem.
iOS device issues should not be important for server-to-server connection applications.
Sean Cullinan: Should devices be required to support “untrusted” certificates?
Buying a “real” CA-issued SSL certificate for every test situation could prove to be a financial hardship.
Mike Palmer (Masstech): There is a project to get free signed certs.
Available at: https://letsencrypt.org
Certificates have short lives, but can be auto-renewed.
There can be problems if auto-validation if if your DNS is behind a firewall
– or if you don’t own the root name of the URL.
Keep-Alive Messages – Discussion
Messages are required to keep a connection available where a firewall or other security barrier times out relatively quickly.
Proposal is for a “Keep-Alive” Layer – This is different from MOS heartbeats.
Shawn Snider: MOS Heartbeats get into the control chain. He has seen problems with them – especially with Heartbeat responses.
Keep-Alive message are especially important in Passive mode.
Proposes a very lightweight Keep-Alive message.
Keep-Alive messages should be constrained to the Transport-level – not command-level.
The Keep-Alive messages should not get into the MOS control stream.
Interval of Keep-Alive messages should be configurable – but generally in the range of 20-30 seconds.
Most networking stacks time out at about one minute.
Use of MOS Heartbeat messages would remain unchanged.
Sean Cullinan: SignalR has built-in Keep-Alive. Doesn’t know if other libraries includes that.
https://github.com/SignalR/SignalR/wiki/Configuring-SignalR
Excerpt:
KeepAlive
This setting represents the amount of time to wait before sending a keepalive packet over an idle connection. The default value is 10 seconds. This value must not be more than 1/3 of the DisconnectTimeout value.
If you want to set both DisconnectTimeout and KeepAlive, set KeepAlive after DisconnectTimeout. Otherwise your KeepAlive setting will be overwritten when DisconnectTimeout automatically sets KeepAlive to 1/3 of the timeout value.
If you want to disable keepalive functionality, set KeepAlive to null. Keepalive functionality is automatically disabled for the long polling transport.
KeepAlive – Representing the amount of time to wait before sending a keep alive packet over an idle connection. Set to null to disable keep alive.
This is set to 30 seconds by default. When this is on, the ConnectionTimeout will have no effect.
Shawn Snider: Keep-Alives are not necessarily part of other libraries.
What should be the format of Keep-Alive?
Should it be a simple string or a conforming, legal, XML block?
Shawn Snider: Advantage of simple string (i.e.: NOT XML), is that it force the message to be transport-level, rather than command-level message.
Sean Cullinan: SignalR will send a simple open-clurly-brace and close-curly-brace, unless something else is implemented.
Excerpt:
KeepAlive messages
KeepAlive messages are empty object JSON strings (i.e. {}) and can be used by SignalR clients to detect network problems. SignalR server will send keep alive messages at the configured time interval. If the client has not received any message (including a keep alive message) from the server within a certain period of time it will try to restart the connection. Note that not all the clients currently support restarting connection based on network activity (most notably it is not supported by the SignalR C++ Client). Sending keep alive messages by the server can be turned off by setting the KeepAlive server configuration property to null.
Keep-Alive is only sent by SignalR if no other traffic has moved across the channel – it keeps track.
Sean Cullinan: Does not like just sending the curly braces. The sender is not identified.
Shawn Snider: Should be a well-defined format that prevents Keep-Alives from getting passed to system’s MOS engines – where they need to be handled.
RE: XML: Shawn Snider is concerned that there could be too many variations of how a system would send what-should-be a well-defined Keep-Alive message – that can be trapped at the transport layer.
Example:
<KeepAlive/>
<KeepAlive></KeepAlive>
<KeepAlive />
Would all be XML-legal ways of saying the same thing.
A proper XML parser would understand any of them to be the same.
However… A simple character string parser would require if/or trapping.
Suggested specifying ONLY ONE of them as correct and legal as a MOS 4 Keep-Alive.
Mark Gilbert: Concern about sending MOS and something-other-than MOS down the same transport stream.
Would the MOS messages need to be wrapped to identify them as MOS to have them forwarded?
Wrap the Keep-alive differently?
Sean Cullinan: Make a keep-alive like a heartbeat, but don’t require a reply.
Mark Gilbert: Suggests making it more generic.
There could eventually be other additional non-MOS communication (ex: authentication or side-channel metadata) that should move in the same transport stream connection.
Build a messaging structure that accommodates MOS and other-than-MOS messages. Something that can carry more than just the single MOS protocol.
Either the MOS Protocol should include the keep-alive, or the transport should be well designed to carry messages of varying protocols.
Shawn Snider will look at the addition of a MOS KeepAlive message, which does not require a reply, as an option.
Authentication – Discussion
Kai Uwe Kaup (SciSys) previously contacted Shawn about Authentication
He commends these two posts:
https://stackoverflow.com/questions/2629222/are-querystring-parameters-secure-in-https-http-ssl
http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Shawn Snider: Intentionally did not describe Authentication schemes in his proposal – leave it up to implementing organizations to decide.
Shawn had suggested including authenticating arguments/credentials in the URI.
This is inherently secure – within the scope of how these messages are intended to be used.
Kai raised three issues:
1. URIs with concatenated credentials could be saved in browser history logs.
2. Can be intercepted within HTTP referrers.
3. Can be intercepted in server-side or proxy logs – if a proxy server is unwrapping and re-wrapping the HTTPS call.
Shawn Snider: First two issues are not relevant, because these call will not be used in a browser environment.
Server log vulnerability could be valid.
Credentials could be included in the HTTP header. Use standard HTTP header fields. Would require username and password, or token.
Mike Palmer: Hitting it with a browser would show a log-in prompt with a demand for credentials.
Not that anyone should be doing so, but it would too-easily expose the security strategy.
Sean Cullinan: JavaScript libraries do not support additional headers for WebSockets
https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api
Basic Authentication *does* work.
Mark Wilson: Organization for storing/managing credentials?
Concerned about too many different standards for an NCS vendor to support.
Shawn Snider: Would be dictated by each vendor.
Not part of the specification to dictate how NCS or MOS vendors would do so.
Kai: SciSys practice to is never store usernames and passwords in clear text in their systems.
Discussion of what is means of authentication username/password vs. token (ex: Kerberos)
Consensus vote decision to put authentication in HTTP header, rather than concatenated in URI.
Standard Public Library
Mark Gilbert (Gallery) raises subject of one vendor to write a cross-platform library that everyone could use (similar to NewTek and NDI) to expedite adoption in the marketplace. As opposed to SMTPE standards that are very slowly adopted.
Suggests that it could be Shawn Snider and Ross Video.
Shawn says it would not fly, from a business perspective, at Ross.
A properly designed and deployed MOS interface is a competitive business/sales advantage for a vendor.
Mark: Each vendor having to design its own will greatly slow adoption of the new MOS version.
Deprecating MOS Commands
Shawn Snider: Since MOS 4.x is a new version of MOS, should we formally remove support for some deprecated messages?
Sean Cullinan: Making any more changes (beyond transport) would only further delay time to market.
Shawn Snider: Will think about this and perhaps make a proposal.