Secure Communications Working Group Meeting Three:
Our third Secure Working Group online meeting is in the process of being scheduled. Updates will be posted here, as soon as they are available.
The purpose of this meeting is for the sub-committee to report out the latest iteration (Version 1.4) of the Proposal for adoption at the MOS Group’s meeting at IBC 2018. See this latest iteration (Version 1.4) here.
Notes from Secure Communications Working Group Meeting Two:
Via Zoom Teleconference
13 June 2018 — 11:00 am/US-Eastern Daylight
Participating:
Shawn Snider (Ross Video)
Warren Davis (Bitcentral)
Randall Meston (AP)
Phil Avner (AP)
Bryan Girdler (AP)
Sean Cullinan (USV)
Mike Roscoe (BBC)
Review and discussion of the proposal document from Shawn Snider (Ross Video) “MOS Encryption And Security via Web Sockets & MOS Passive Mode” Revision 1.3
Mostly a cleanup of earlier versions, incorporating decisions of the Group from the previous conference call. Includes reworking of workflow diagrams.
Previous decision was that the version of MOS will be designated as MOS 4.
Discussion of whether this version will be called 4.8.x (following the numbering scheme of MOS 2.x) or 4.0 (to reflect a new baseline). Decision was made to designate it as 4.0.
Passive mode will be a required mandate going forward
It can be configured on the NCS or MOS side.
Implementation will be WebSockets over HTTPS.
SSL Certificates will be required.
They may be Self-signed or Untrusted.
A required part of the MOS header is a “Channel” identifier, as a reference to which legacy port the over which message would have moved (10540, 10541 or 10542).
Authentication will be HTTP Authorization headers using the “Basic” schema.
This keeps the authentication information out of the URL.
Every device must define an endpoint that will be used for communication with the device.
The format of the URL is up to the vendor.
The underlying “Two Ports/Four Sockets” topology remains intact.
The “KeepAlive” message (to keep firewall and other security barriers open, once authorized) is added to MOS Profile 0.
The message is maintained at the MOS “message” level.
It does not require an ACK or other reply.>
It does not require a MOS MessageID number.
This is the only change to the message structure from MOS 2.8.5.
There is no end-of-life date being set for MOS 2.x at this time.
About a dozen MOS messages which were deprecated in earlier MOS versions will not be a part of MOS 4.0 and beyond.
For reference only, the MOS Protocol document for version 4.0 will list the messages that are no longer supported as part of MOS 4. Each will be accompanied by an indication of what message has taken over its functionality.
Some vendors just want to write a “message forwarder” to onpass deprecated messages.
Concern (expectation?) that those NCS and MOS vendors will “migrate” to WebSockets for transport, but otherwise leave their MOS messages as-is. This would likely include some of those deprecated message types.
Vendors who are still on MOS 2.6 (after MOS 2.8 has been around for over a decade) may never be inclined to modernize unless customers demand it – Ex: for sending messages across the Internet.
In the MOS Protocol document, we need to make the language very firm.
Something like: “These messages are no longer in the specification. They are not to be used.”
Except for any essential clean-up, MOS 2.8.5 will be the last version of MOS 2.x.
Mike Roscoe: BBC looking at this in great detail
Next steps:
Shawn Snider has prepared one last write-through of the Proposal document. See it here.
We will have one more online call (early-mid July?) to review.
The Proposal document will be distributed and made available to all MOS Group members by early August.
An up-down vote on the Proposal will be conducted at the MOS Group’s meeting at IBC.
Following the anticipated approval at IBC, a full and complete MOS Protocol 4.0 specification will be written, incorporating all aspects of the adopted proposal.
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.