The spec recommends using HTTP Strict-Transport-Security (HSTS) according to RFC 6797.

Is there a guideline for what value of max-age to use?

Netsparker says:

It is recommended to set the max-age to a big value like 31536000 (12 months) or 63072000 (24 months).

Qualys says:

It is advisable to assign the max-age directive’s value to be greater than 10368000 seconds (120 days) and ideally to 31536000 (one year).

OWASP Cheat Sheet uses an example of one year:

Strict-Transport-Security: max-age=31536000; includeSubDomains

SCIP says:

A common recommendation for production sites is to set max-age to 31536000, which constitutes roughly a non-leap year. Lower values can be useful for testing purposes but increase the frequency a window of attack occurs due to the expiration of the header. It takes little effort to find examples of sites using values as low as one minute. This defeats the purpose of HSTS and does, worst case, convey a wrong sense of security because the site has – strictly technical – a valid HSTS header.

testssl.sh used in the AMWA NMOS Testing Tool implements the HSTS test as:

15552000 s (180 days) or more is recommended

But I don't know whether that guidance comes from any recognized body?

Currently the BCP-003-02 description of the x-nmos-api private claim has:

"x-nmos-api": {
  "name": "is-04",
  "version": ["1.0","1.1","1.2"]
}

Would it make sense to be consistent with other NMOS specifications (e.g. IS-04 Node /self resource "api" property), like so:

"x-nmos-api": {
  "name": "is-04",
  "versions": ["v1.0","v1.1","v1.2"]
}

I think it would be good to allow the option of passing access-tokens in the query parameters of the URL when initiating a WebSocket connection. This is due to the limitations of the Javascript API not allowing custom HTTP headers upon instantiation. Something along the lines of:

The Access Token SHOULD be passed in using the HTTP Header during the initial websocket handshake. When this is not feasible, the Access Token MAY be passed in using the URL parameters.

This is with the provision that HTTPS / WSS is always used. The only downside to this solution is that URL strings are sometimes cached, non-encrypted, in some proxy servers. Alternatives include using a ticketing system (https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api) however this would involve changes to the IS-04 API's which seems intrusive. Another option is for the access token to be passed in as the first message after a successful websocket connection, however this means a connection is set up implicitly before authorization has taken place.

Interesting article on Websockets and Authorizaiton;
http://lucumr.pocoo.org/2012/9/24/websockets-101/

Reminder:

The nmos-testing suite (BCP-003-01) requires the minimum max-age to be 15465600 seconds.
After having a chat with @garethsb-sony about this, it seems that there should exist a guideline for the HSTS header somewhere.

A reference to the mentioned guideline (once found :)) should be added to the docs (best-practice-secure-comms.md).

Regarding best-practice-tls-pki.md, the following items may need some discussion:

Line 226: Regarding self-signed certs, "This SHOULD NOT be used for large installations", I suspect implementers will ask "what does LARGE mean?" It might be good to instead suggest why this is a bad or unscalable idea.

Line 259: "Servers SHALL NOT accept or respond to plain HTTP requests." It might be good to add language to be clear we are not presenting HTTP web pages on a device (may be useful for Identification or other purposes), but the HTTP restriction is only for API implementations as per the scope of this document.

Line 270: "Servers SHALL validate all request payloads and reject those that are invalid
with HTTP response code xxx." I would suggest "with an appropriate 4xxx Client Error code" as there are a number of ways that an request payload could be invalid. For example 403 Forbidden, 405 Method Not Allowed, 406 Not Acceptable, perhaps even 402 Payment Required, or the generic 400 Bad Request. I'm not even sure if we should be specifying code 405 on line 265, as it should be an obvious HTTP/REST thing to do.

Line 413: "Creators of new AMWA Interface Specifcations SHOULD ensure that the recommendations of this document are included in the Specification itself." Do we really want Specification writers to copy/paste this document, or simply reference it in future Specifications?

-Thomas

Should BCP-003-01 TLS 1.2 Cipher Suites be explicit about overruling RFC 5246 Section 9. Mandatory Cipher Suites? I think it's OK, just might be worth a note.

Not sure where to note this, but one thing for implementers to bear in mind is that names returned from DNS-SD seem often to have the trailing '.' that indicates an FQDN (e.g. "mocks.testsuite.nmos.tv."), whereas certs are normally issued with CN/SANs that are DNS names without the (implied...) trailing '.' (e.g. "mocks.testsuite.nmos.tv"). Name matching needs to take this into account, although RFC 2818 does not make it clear.

('transferred' from AMWA-TV/nmos-testing#207)

IS-10 made the token client_id optional for compatibility reasons, but this is depended upon by BCP-003-02. Either adding azp claim support or using the sub may be ways around this.

In addition, the text in BCP-003-02 needs to be clearer that any sub-resources of a Node which a registered/updated/deleted need to be checked against the client_id which was used for the initial Node registration.

The links to footnotes in https://github.com/AMWA-TV/nmos-api-security/blob/v1.0-dev/best-practice-authorisation.md don't seem to do anything, and nor are the footnotes themselves rendered. Not sure that GitHub-flavour markdown supports footnotes out of the box?

It would be useful if this repo could follow the branch naming conventions from https://github.com/amwa-tv/nmos/wiki/GitHub-Workflow, otherwise the test suite will fail to load it correctly. As I'd guess there's the potential for the two BCPs to move forward at different rates with respect to versioning, it may be that ultimately there need to be two repositories used instead.

Log a list of possible TODO items as an issue for prosperity as they have been removed from BCP-003-03 ready for its publication:

TODO:

• - Consider mandating that a new private key is generated for certificate renewals, for security and preventing issues with EST servers re-issuing existing certs if CSR is un-changed
• - Issues could arise when renewing certificate if the EST client is unable to replace the TLS certificate without causing system disruption - group needs to come up with recommendation on best practices for this. Perhaps a /renew-certs endpoint for use to trigger process when it is safe to do so
• Consider using using TLS Client Certificates when using NMOS API, for use with BCP-003-02 OAuth
• Consider including unique information in the manufacturer client certificate, such as MAC address, so the EST Server can validate that the client certificate presented was for the device in question (eg. the firmware has not been loaded onto a fake device)
• Use of 802.1AR - secure device identity for a distinct PKI for client Auth
• Define the use of Root CA Key Update, for Root CA rollover/renewal
• Possible extensions to EST RFC
  • Add method to signal certificate profile, eg. TLS Client Auth or TLS Server Auth
  • Add method to signal profile for server side key generation, digital signature algorithm
  • Discovery of EST API

Feedback from several vendors is that they see certificate deployment and automatic renewal before expiry as a big blocker to adoption of secure communications (HTTPS/WSS) with NMOS APIs.

Simon's BBC Whitepaper 338 covers several possibilities for certificate provisioning, including SCEP with NDES, which is pragmatically covered well here: https://blogs.technet.microsoft.com/jeffbutte/2016/12/16/236/.

Offering guidance to the industry on this topic could encourage adoption of secure communications with NMOS.

BCP-003-01 gives TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as the REQUIRED cipher suite for TLS v1.2.

We have implemented BCP-003-01 with a switchable secure comms implementation, and I now realise that on Windows, when using the Microsoft HTTP Server API (http.sys), that cipher suite is not supported on any test system.

This would appear to be because Windows Secure Channel (Schannel) does not implement that cipher suite. The list and default order of supported cipher suites depends on the version of Windows, but even on recent Windows 10, no AES-CCM cipher suites are provided.

This can be confirmed in the Schannel documentation at Cipher Suites in TLS/SSL (updated 31-May-2018, retrieved 30-Apr-2019).

While it is possible to use other server back-ends on Windows to support TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, is it reasonable for BCP-003-01 to prohibit Microsoft-based server implementations?

Note that Schannel does support other cipher suites on the BCP-003-01 TLS v1.2 recommended list including the next four highest priority:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

To finish off dd52cee, it might be appropriate to rename best-practice-authorisation.md to best-practice-authorization.md... or best-practice-auth.md 😉

Currently we don't have schemas associated with the access token, i.e. invalid elements could end up being used.

Followings are a number of issues found in the access token:

1. JWS is signed with RS256, not RS512. JWS MUST be signed with RSASSA-PKCS1-v1_5 using SHA-512.
2. "alg" in header shall be RS512 (details as shown in 1 above).
3. should "scope" in payload be set the same as x-nmos-api's "name".
4. should "aud" in payload constains the fully resolved domain name of the intended recipient.
5. when Bearer token is reserved via the Password flow, will it be better to use the same scope style as the access token's scope (is-04, is-05)?

Following is an exanple which was reserved via the Authorization Code Grant flow:

HEADER:

{
  "alg": "RS256", 
  "typ": "JWT"
}

PAYLOAD:

{
  "sub": "amwa",
  "exp": 1560945966,
  "scope": null,
  "iss": "http://rd.bbc.co.uk/x-nmos/auth/v1.0/",
  "iat": 1560945906,
  "x-nmos-api": {
    "access": null,
    "name": null
  },
  "nbf": 1560945906,
  "aud": null
}

Chris from Matrox believes there will be a need for server side key generation, for low power devices.
This should be added to the certificate provisioning document.