[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Authentication
|
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]
JSON Web Token is nice because it is symmetrically encrypted. 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. 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> 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 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." |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]