Re: [cti-taxii] TAXII 2 URLs and Mandatory Discovery URL

[John-Mark Gurney <jmg@newcontext.com>]

Jason Keirstead wrote this message on Wed, Jan 03, 2018 at 09:15 -0400:
> 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

Is this an issue w/ colliding? or just that there is a mandatory path?

The reason I asked, is that I voiced concern over this, and suggested
that we register, and use the .well-known RFC5785[1] mechanism, and
wonders if that would solve your problem?

> - The fact that we do not specify if URLs can be relative, or if they must 
> be absolute.

Yes, this needs to be clarified, and looking at various web definitions
doesn't make it clear with out we use the various terms.

> 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

Yes, this is a big problem w/ reverse proxies, which are common these
days...

> 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/taxii already 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.

Hmm... I thought that it was possible that you could run both at the same
time as there was not a collision of names under /taxii, but I could be
misremembering.

[1] https://tools.ietf.org/html/rfc5785

-- 
John-Mark