Re: [cti-taxii] RE: Authentication

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

Hi Rutger - just to add some additional color here.

The reason why a "mandatory to implement" authentication scheme is so that any two random TAXII products can be ensured that they can communicate with each-other. This is actually not the case today with TAXII 1.X as authentication is not included in the standard. As such, there have been very real-world situations where two vendors have implemented TAXII in a compliant fashion, yet they could not share any data, because they didn't both support the same authentication schemes.

This in no way precludes vendors from optionally supporting other methods, for example Client SSL certificate, or Kerberos, or any other mechanism. All it states is "if you are following the TAXII standard, you MUST support these mechanism(s) at a minimum". This way anyone can get two pieces of software who say they "speak TAXII" and know they can talk to each-other without diving into the source code.

As for the HTTP Basic - the reason it was proposed is it was seen as "table stakes" for HTTP authentication and most tool-chains already have this built in. Combined with the fact that SSL would be mandatory, it is relatively secure.

If the concensus is that HTTP Basic is not required we can easily drop it as an MTI scheme.

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

Without data, all you are is just another person with an opinion - Unknown


"Davidson II, Mark S" ---10/08/2015 12:58:27 PM---Rutger, I'll try restating your comment in my own words to make sure I understand it: For TAXII Clie

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: Rutger Prins <rutger@eclecticiq.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 10/08/2015 12:58 PM
Subject: [cti-taxii] RE: Authentication
Sent by: <cti-taxii@lists.oasis-open.org>

---

Rutger,
 
I’ll try restating your comment in my own words to make sure I understand it: For TAXII Clients and Servers that want to use an alternative authentication method, they should be able to.
 
If that’s the case, I’ll say that I agree and I don’t think it impacts the proposal.
 
I look at it like this:

· The proposal requires that TAXII Clients & Servers support HTTPS + HTTP Basic + JWT
· The proposal does not preclude TAXII Clients & Servers from using/offering alternative/additional authentication methods.

IMO, it would be totally acceptable for a TAXII Client and Server to use something completely outside the proposed authentication method.
 
What do you think?
 
Thank you.
-Mark

From: Rutger Prins [mailto:rutger@eclecticiq.com]
Sent: Thursday, October 08, 2015 11:29 AM
To: Davidson II, Mark S <mdavidson@mitre.org>; Jordan, Bret <bret.jordan@bluecoat.com>; cti-taxii@lists.oasis-open.org
Subject: Re: Authentication

JSON Web Token is nice because it is symmetrically encrypted.
The secret for this could be shared by client and server out of band, allowing the client to generate its own token that the server can verify.
Or if you prefer password authentication, the secret could just be server-side and the user would get a token it would know nothing about.
Tokens can also expire and can contain a custom JSON payload.

I would leave out the HTTP Basic auth or at least leave it optional for the shared secret use-case.

Regards,

Rutger Prins

Intelworks


---

From: cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on behalf of Davidson II, Mark S <mdavidson@mitre.org>
Sent: 08 October 2015 13:52
To: Jordan, Bret; cti-taxii@lists.oasis-open.org
Subject: [cti-taxii] RE: Authentication

Under this idea, TAXII would be “HTTPS everywhere”.

As an additional point of context (and thank you to the slack channel for educating me on this) the JSON Web Token is similar to how your phone apps do authentication. You type in your username and password once when you want to connect and the app gets a token back, and the app discards your username and password. From then on, the token is refreshed and only under certain conditions (e.g., app reinstall) are you asked to put your username and password in again. Ideally (IMO), if we can apply this concept to TAXII, usernames and passwords will be sent across the wire very infrequently.

For me, the proposal is:

· HTTPS everywhere
· HTTPS + HTTP Basic + JWT is mandatory
· Extension point for additional authentication factors (the design of this is TBD)

Once we get an authentication concept in rough agreement on the list, I think we’ll have enough things worked out that we can start making interoperable prototypes.

Are there any comments on the proposed authentication design?

Thank you.
-Mark

From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Tuesday, October 06, 2015 12:52 PM
To: cti-taxii@lists.oasis-open.org
Subject: [cti-taxii] Authentication

We have had some discussion on the Slack channel over the past week about authentication and I mentioned at the end of last week that I would like to move that forward.

It has been proposed on the Slack channel that we use HTTP Basic with JWT (JSON Web Tokens) for the mandatory authentication in TAXII 2.0 with an extension point that is some how discoverable to allow for multi-factor authentication.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."