CTI TAXII Subcommittee

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.   Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

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."   

On 08.10.2015 11:52:10, Davidson II, Mark S wrote: > > Under this idea, TAXII would be "HTTPS everywhere". > Assuming that TAXII 2.0 is REST-based, defining JWT as the MTI authentication mechanism is obvious. As for the notion of TAXII being "HTTPS everywhere", I'll just point out that key management is the hardest part of crypto. If I'm running an ISA{C,O}, obviously I'm going to opt for the strongest EV cert money can buy. But what about all the endpoint devices out there? Vendors (including Soltra, to be fair) use self-signed certs all over the place. Seems like there be dragons here... -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com Attachment: signature.asc Description: PGP signature

The nice thing about saying HTTPS everywhere is the decision as to what to do with self-signed certificates is rightly a matter of local policy. If I am in a high security, very limited distribution ISAC or C/F/N-TLA government agency, I am going to impose a very stringent X.509 policy, like your certificate must be signed by one of three root CA’s and I will pin your CA and if your root CA changes without you telling me, I will reject the connection. If I am in a public information distribution ISAO or D-TLA government agency where my remit is to publish information to the world, I will happily accept a self-signed certificate or accept a certificate that you claim to be ICBC (China) but your root CA is DoD (US). About the only thing we should say here is that implementors may wish to have their products support the appropriate certificate policies and if that policy is a promiscuous one, to PLEASE not pop up a modal dialog box saying someone is trying to connect with a self-signed certificate. > On Oct 12, 2015, at 4:30 AM, Trey Darley <trey@soltra.com> wrote: > > On 08.10.2015 11:52:10, Davidson II, Mark S wrote: >> >> Under this idea, TAXII would be "HTTPS everywhere". >> > > Assuming that TAXII 2.0 is REST-based, defining JWT as the MTI > authentication mechanism is obvious. > > As for the notion of TAXII being "HTTPS everywhere", I'll just point > out that key management is the hardest part of crypto. If I'm running > an ISA{C,O}, obviously I'm going to opt for the strongest EV cert > money can buy. > > But what about all the endpoint devices out there? Vendors (including > Soltra, to be fair) use self-signed certs all over the place. Seems > like there be dragons here... > > -- > Cheers, > Trey > -- > Trey Darley > Senior Security Engineer > 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 > Soltra An FS-ISAC & DTCC Company > www.soltra.com Attachment: smime.p7s Description: S/MIME cryptographic signature