HTTP Basic Authentication should be optional for TAXII servers

[johnwunder]

I'd like to propose making support for authentication (specifically HTTP Basic) optional in the TAXII specification. There are a couple reasons for this:

1. A lot of data feeds are completely open source, and so TAXII servers supporting these feeds do not need to support HTTP Basic authentication. Clients that support HTTP Basic will also interoperate with these servers.

2. Many other feeds will only support mutual TLS authentication (AIS), or some form of token-based authentication. In this case as well, TAXII servers do not need to support HTTP Basic authentication. If they do, the organizations will likely disable it.

The only real way that HTTP Basic increases interoperability, from the server perspective, is if organizations leave it on and configured by making a decision (one hopes) to allow HTTP Basic and set up accounts in it. But if they want to do that won't they just buy a product that supports HTTP Basic anyway?

The main impact of this is 8.2.2 number 5. IMO that should be moved to an optional feature.

[MarkDavidson]

FWIW, TAXII 1.x had optional authentication and it was considered to be a major pain point, which is why it's required in TAXII 2.0.

[gtback]

Is it worth distinguishing that TAXII server and client software/libraries MUST support HTTP Basic Authentication, but that individual instances of a running TAXII server are free to not support it? I think the latter will happen anyway.

[MarkDavidson]

What we intended to say in the spec is:

1. The software must support auth
2. The deployment can turn authentication off if they want

@gtback I think that matches your statement.

[johnwunder]

Yeah this specific request was to make it so that TAXII server software doesn't have to support HTTP Basic authentication at all....the spec currently says what @gtback said.

[varnerac]

So, I agree that this should be optional. I think some implementations will freely distribute their information without authentication. Others will always require client certificate authentication. To force these implementations to implement an authentication scheme that they will never use in production leads to them:

• not running the TAXII 2.0 preferred tests, increasing the risks of interop issues where it matters
• implementing and maintaining unused auth functionality

[emmanvg]

I agree with both @johnwunder and @varnerac on some organizations wanting to freely distribute their information without authentication AND the TAXII Server software not having to support HTTP Basic since it would be unused.

[allant0]

I understand the use case for unauthenticated services over HTTPS. Most web sites nowadays require HTTPS but do not require authentication of the user to provide that service.

But does every web server on the planet support the ability to switch on authentication if need be? I suspect yes.

Therefore for the purposes of specification we change the specification to a SHOULD.

We then mandate in the interop persona tests that all persona MUSt support basic-auth except for the one persona TXF (TAXII-Feed) that supports the use case identified by this request.

In summary, this provides spec consistency with interop and provides a realistic/recommended behavior for all vendors to adopt authenticated services. I'm sure most security companies will use authentication for protected the valuable information on the servers if the data is sensitive or needs protection.

[varnerac]

Some folks find Basic Authentication inadequate. If we require it to be in their TAXII stack in an organization that protects data with client certificate authentication and hardware security modules, we’re not doing them any favors. We can tell them “don’t enable that in your config.”

[allant0]

It's a compromise between not specifying any security at all vs 'something is better than nothing' security. There's a reason why there are more sophisticated security schemes but it is not this specification's role to define those as mandatory. Suggesting basic auth was considered sufficient to make the point which is 'you should implement HTTPS and authentication mechanisms sufficient to provide authenticated and authorized access' without mandating a higher bar. It also allows us to define what authentication mechanism is used for interop also.

[jmgnc]

I disagree [with the original comment]. It could be that the requirement be moved to certification (which is really all that matters anyway) per @allant0 's comment.

Both of John's point IMO are not valid reasons to not require Basic Auth. There is NOTHING that prevents servers that are used for those specific uses to either disable, or disallow basic auth.

The point of having the requirement is that random implementation A can know that they'll be able to communicate w/ random implementation B if necessary. Relaxing this requirement will mean that it's entirely possible that any combination of A and B will not work together. If a group requires a higher bar, that is the group's choice to limit what software may be used, but the goal at STIX and TAXII is that in general all the software can talk to all the other software at a basic level in a secure manner.

[jordan2175]

We discussed this on the working call on 2018-05-15. While no consensus was achieved, there was a slight preference for accepting this change so long as the interoperability documents continue to test for HTTP basic. We will bring this up again on a future working call.

[jordan2175]

We discussed this again on the working call today, 2018-05-22 and achieved consensus (7 for, 1 against, 1 abstain) with the caveat that the interop documents would still require HTTP Basic, but the specification would relax those requirements. The editors will look to make this change for WD03. The people that voted for this were Drew Varner, Bret Jordan, Jeff Mates, Emmanuelle Vargas-Conzalez, Allan Thomson, Nicholas Hayden, and John-Mark Gurney. The only person that voted against this was Mark Davidson. The person that abstained was Sarah Kelley.

[jordan2175]

I made proposed changes to 1.5.9 and 8.2.2 in suggest mode. Just waiting for final verification.

[jordan2175]

The next in 1.5.9 now says:

HTTP Basic authentication, as defined in [RFC7617] is the suggested authentication scheme in TAXII. As specified in sections 8.2.2 and 8.5.1, TAXII Servers are encouraged to implement support for HTTP Basic and Clients are required to implement support for HTTP Basic, though other authentication schemes can also be supported. Implementers can allow operators to disable the use of HTTP Basic in their operations.

If the TAXII Server receives a request for any Endpoint that requires authentication, regardless of HTTP method, and either an acceptable Authorization header that grants the client access to that object is not sent with the request or the TAXII Server does not determine via alternate means that the client is authorized to access the resource, then the TAXII Server will respond with an HTTP 401 (Unauthorized) status code and a WWW-Authenticate HTTP header.