TAXII 2 URLs and Mandatory Discovery URL

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Hi everyone. I raised these concerns on
Slack at the tail end of 2017, but thought i should send to the list as
everyone has probably forgotten about them at this point.

I am discovering some real implementation
issues with TAXII 2 as it is defined today - namely around two things

- The mandatory "/taxii" discovery
root
- The fact that we do not specify if
URLs can be relative, or if they must be absolute.

The issue is, the spec is written around
the idea that someone hosting a TAXII 2 server 

- Knows their host name and web root
- Has full control over the root web
server hosting TAXII
- The /taxii endpoint does not already
exist

None of these things are going to be
true for a lot of implementations, where one is trying to add TAXII 2 support
to an already existing product. 

For (a) and (b), these provisions make
it extremely difficult to implement a generic TAXII 2 support library vs.
a full blown server. I have run into this myself trying to port the MITRE
Medallion service to a library. If the library does not know where it is
running, then it can't construct the full URLs the spec is expecting to
be present in the discovery response

For (c), If you have https://my_api_gateway/taxiialready in use on your system for TAXII 1, then you actually can not implement
TAXII 2 unless you make your TAXII 2 API run on a totally different VHost...
something that is not always possible, *especially* for systems that are
not registered in DNS and thus can't use VHost tricks.

I very strongly think we need to revisit
some of this in TAXII 2.1. (c) to me is the biggest oversight we made and
IMO is not an option to change, because folks use "/taxii" everywhere.



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

"Things may come to those who wait, but only the things left by those
who hustle." - Unknown