Sounds like something we for sure need to fix for 2.1.
All,
We have already identified a lot that we got right and a few things we got wrong in TAXII 2.0. Please, work with your implementation teams to identify any other problems so that we can fix all of them in TAXII 2.1.
As I have said before, I really want to see TAXII 2.1 be the production grade version that we can take to a full OASIS Standard. Yes, we will have some bumps in the road between now and then and we will have a few backwards/forward breaking changes, but
we can get there.
What I would like to ask this TC to do, is approve some of these big changes that we have already identified so we can release a CSD-01 for TAXII 2.1. This will give organizations something to start coding to so we can hopefully iron out any other problems.
Thanks for all you do. Please keep the questions, issues, and rational coming.
Bret
Sent from my Commodore 64
PGP
Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
On Jan 9, 2018, at 11:31 AM, Joep Gommers <
joep@eclecticiq.com > wrote:
On the subject of reversed proxies, did a quick scan across our customer and prospect base;
Of all CERTs/NCSCs we work with the vast majority has a proxy in front of their taxi server (especially when that server is embedded in a TIP
like ours) Of all national security environments this is pretty much all architectures. Special note towards the use of API gateways here in addition
to reversed proxies. Of all enterprises, just below half would use reversed proxies. Of all taxi servers we host on behalf of our customers, we use a reverse proxy.
Hope that’s helpful input.
J-
From: <
cti-taxii@lists.oasis-open.org > on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Date: Tuesday, 9 January 2018 at 13:17
To: John-Mark Gurney <
jmg@newcontext.com >
Cc: "
cti-taxii@lists.oasis-open.org " <
cti-taxii@lists.oasis-open.org >
Subject: Re: [cti-taxii] TAXII 2 URLs and Mandatory Discovery URL
The issue is it colliding *because* it is a mandatory path.
We define "/taxii" as a madatory path for TAXII 2, which means you can't use it for TAXII 1 (or anything else). So anyone who was already using "/taxii" for TAXII 1, can't implement TAXII 2 on the
same host/vhost. This can be a real problem for folks with products who can not make any use of VHost tricks to work around it.
-
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
From: John-Mark Gurney <
jmg@newcontext.com >
To: Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc:
cti-taxii@lists.oasis-open.org Date: 01/08/2018 09:30 PM
Subject: Re: [cti-taxii] TAXII 2 URLs and Mandatory Discovery URL
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://urldefense.proofpoint.com/v2/url?u=https-3A__my-5Fapi-5Fgateway_taxii&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=9fBCbDJDV9Hq2aAJ9CHKi2xx_y0aMvVgH_msJcBjLCQ&s=S2PuT8me-kKvmULKNmsIVAP3lZ3fTaVD9prqlO5AqR8&e= 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5785&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=9fBCbDJDV9Hq2aAJ9CHKi2xx_y0aMvVgH_msJcBjLCQ&s=Gban4ZMgCnh09viD_UllhwI1EHBvRR3R3yslO6n2apI&e= --
John-Mark