From tomasz@fumu-no-kagomeko.kueea.info Sat Jan 25 18:59:56 2020 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1A212008D for ; Sat, 25 Jan 2020 18:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.665 X-Spam-Level: X-Spam-Status: No, score=0.665 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fumu-no-kagomeko.kueea.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brqR0Rj7eHQk for ; Sat, 25 Jan 2020 18:59:55 -0800 (PST) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0121C12001E for ; Sat, 25 Jan 2020 18:59:54 -0800 (PST) Received: from fumu-no-kagomeko.kueea.info (87-206-171-188.dynamic.chello.pl [87.206.171.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id DEABA1E0529 for ; Sun, 26 Jan 2020 02:59:53 +0000 (UTC) Received: from [192.168.0.2] (honden.fumu-no-kagomeko.kueea.info [192.168.0.2]) by fumu-no-kagomeko.kueea.info (Postfix) with ESMTPSA id 019BF50975 for ; Sun, 26 Jan 2020 03:59:28 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 fumu-no-kagomeko.kueea.info 019BF50975 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fumu-no-kagomeko.kueea.info; s=20170310; t=1580007569; bh=UgassathnmWiDTu7ZwvYUqv50QeTMOzViu76+DnGTiI=; h=To:From:Subject:Date; b=LMQk5wPC2AfH2M/RWfL+hri+wB08a0LB3XYtQl5IWZ00bOXl41u5w7XRPX1lL71cq PaRBJu/1dvU1RaCBhZ9d6KRaqz/uc9k1gFgiikAwPzYmZwD1xyJgFsDbvqMCSSrJWc udomsKTEQCW6+JcnR5/XGdGkC0F7D8AJ229CM0oCTrfmAavjUB9hvaK0F4g72YO7jO 30AuiKlxe10Ds7QMaiTMYegIptornirH89KDx/3qyKxig2ReBGqGZp4cR77Uigfa4t DrDCnXD41S6WU6XRX+TxKH4Y6ZT/zCtD5HdCLuuhaWmT6/3xXtHKRBGlVD0YkGQfWi g8wo4+UKu0KtQ== To: media-types@iana.org From: Tomasz Sobczyk Message-ID: Date: Sun, 26 Jan 2020 03:59:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (pechora6.dc.icann.org [192.0.46.72]); Sun, 26 Jan 2020 02:59:54 +0000 (UTC) Content-Language: en-US Archived-At: X-Mailman-Approved-At: Sun, 26 Jan 2020 09:24:39 -0800 Subject: [media-types] How about "filesystem/" types? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 03:03:13 -0000 Hello, I would like to propose and hear your opinions about a top-level type for all kinds of filesystem images. These would also include formats that are commonly referred to as "archives", because these "archives" are technically filesystem images where file data hassimply been compressed. These "archives" could be mounted, but that is unpractical due to the fact the compression method does not allow for random access and the formats are not suited for file editing. The term "archive" comes from their purpose - they are used for archival, the word has no connection to the format itself. I would like to propose it because of the following reasons: 1. There are quite a lot of filesystem formats used in transit,    most notably ZIP, RAR and ISO 9660 images. 2. There are common operations that one does on a filesystem,    namely filesystems can be browsed, mounted, one can add a file,    remove a file, extract a file from a filesystem, etc. 3. Filesystems are collections of various resources, which does not    necessarily need to have anything in common. Filesystems may contain    files that are completely unrelated to each other. 4. Personally, I think that there should be as less as possible subtypes    under "application", because every resource is meant for some kind of    application. "application" is basically "other" or "uncategorized".    Having a whole bunch of types there defeats the purpose of a top-level    type in my opinion. We might as well just use flat strings. My proposed top-level type name is "filesystem". All subtypes under this type would be required to define a structured syntax name suffix, maybe with a common prefix like "fs!". For example, given "filesystem/zip" would exists, there would be an "application/epub+fs!zip". An application which does not undersand "application/epub+fs!zip" could infer that its a (ZIP) filesystem and maybe present a filesystem browser to the user, for example. Generally, the resource could be passed to some external filesystem browser application that could support an arbitrary amount of filesystem images. The presence of "+fs!" would indicate that this browser might be able to work with it. What do you think? Tomasz From nobody Sun Jan 26 13:45:37 2020 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A0B120048 for ; Sun, 26 Jan 2020 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0yKqf0KdEy7 for ; Sun, 26 Jan 2020 13:45:32 -0800 (PST) Received: from pechora6.dc.icann.org (pechora6.icann.org [IPv6:2620:0:2830:201::1:72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93DD120043 for ; Sun, 26 Jan 2020 13:45:32 -0800 (PST) Received: from v-smtpout3.han.skanova.net (v-smtpout3.han.skanova.net [81.236.60.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id 91BB11E00FB for ; Sun, 26 Jan 2020 21:45:31 +0000 (UTC) Received: from [192.168.8.101] ([2.69.139.202]) by cmsmtp with ESMTPA id vpiNiEQpTHueqvpiNitKE9; Sun, 26 Jan 2020 22:45:09 +0100 To: Tomasz Sobczyk , media-types@iana.org References: From: Henrik Andersson Openpgp: preference=signencrypt Message-ID: <4a570279-9e2e-a75b-6178-6aadcf9a5a9e@henke37.cjb.net> Date: Sun, 26 Jan 2020 22:45:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfGOK/C30RouMl+jWQCq86cmun4Ly1Jyaj04Izn/3LuEih3Zj3zFIYcrgCFjMyTUDCyqvMQO81HHoNmyn1aruvbW0Z4BYpk8ft2tJ6UtaumDZsF0uiuuf S1u8VKFnJQ9hVonYfav+IsE6c1jhVf2oXAs29VNYJCyIHYZB0kVDnscUHIUPO4YMTRSdtaKbB9iJ/JHZosMd1mbnFeYZGxLbTb6WTfNWhL1wyAH86bJjs4st Archived-At: Subject: Re: [media-types] How about "filesystem/" types? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 21:45:34 -0000 Tomasz Sobczyk wrote: > Hello, > > I would like to propose and hear your opinions about a top-level type > for all kinds of filesystem images. These would also include formats > that are commonly referred to as "archives", because these "archives" are > technically filesystem images where file data hassimply been compressed. > > These "archives" could be mounted, but that is unpractical due to the > fact > the compression method does not allow for random access and the > formats are > not suited for file editing. The term "archive" comes from their > purpose - > they are used for archival, the word has no connection to the format > itself. > > I would like to propose it because of the following reasons: > > 1. There are quite a lot of filesystem formats used in transit, >    most notably ZIP, RAR and ISO 9660 images. > 2. There are common operations that one does on a filesystem, >    namely filesystems can be browsed, mounted, one can add a file, >    remove a file, extract a file from a filesystem, etc. > 3. Filesystems are collections of various resources, which does not >    necessarily need to have anything in common. Filesystems may contain >    files that are completely unrelated to each other. > 4. Personally, I think that there should be as less as possible subtypes >    under "application", because every resource is meant for some kind of >    application. "application" is basically "other" or "uncategorized". >    Having a whole bunch of types there defeats the purpose of a top-level >    type in my opinion. We might as well just use flat strings. > > My proposed top-level type name is "filesystem". All subtypes under > this type > would be required to define a structured syntax name suffix, maybe with > a common prefix like "fs!". For example, given "filesystem/zip" would > exists, > there would be an "application/epub+fs!zip". An application which does > not > undersand "application/epub+fs!zip" could infer that its a (ZIP) > filesystem > and maybe present a filesystem browser to the user, for example. > Generally, > the resource could be passed to some external filesystem browser > application > that could support an arbitrary amount of filesystem images. The > presence of > "+fs!" would indicate that this browser might be able to work with it. > > What do you think? > > Tomasz > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > > I think that you are several decades too late. From nobody Thu Jan 30 13:25:33 2020 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE6012006F for ; Thu, 30 Jan 2020 13:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oasis-open-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilrIFxPHjZe4 for ; Thu, 30 Jan 2020 13:25:27 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A2912001A for ; Thu, 30 Jan 2020 13:25:27 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id v28so5380394edw.12 for ; Thu, 30 Jan 2020 13:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oasis-open-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=K8lUDFOcDYKiwOBiGJ7Yxlbh8NeGXgexARSvj6rtpys=; b=Iu2HjjTe494ch5/4QgvwX82LRq3OCEfw3wEAOjMwxCSbVxE2aZxipFAFn6GWMMAA03 aB3uTK/PGhfRb6vXaC9raBA9rb0LEUuEXYrky9+O8E2yd3+Pb5W5rFtP+Ah27SP5FN5p GU63BnFWw8BY5t74p1YOqw6OpIrvjzJDDej/Ya8EhJ/cMU9ubgcFlqEla9IE4OSyhm3A r/Do4Xh8U69PR0Ky0W2XBDQb+7SuKkilgZbzgyDr7vBQooncHPRXTj6c430ul743SLyv AquaB+q64pc4J4sIhkMCQQe5z1K4ec1ElTK9prjkPQ0AzCuaJ/owPrIOIKGEMwZovHaE ga0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=K8lUDFOcDYKiwOBiGJ7Yxlbh8NeGXgexARSvj6rtpys=; b=RbIc82oJ9H8j7Daxh3+og+x+aW8nauT1W3UCkwWFkJfPdHnlpH0eFTQp2Vw/vF7gZD tFsd5WAR++ho244igF5464wFwhDFbAem+qRCG9xfpJKle/HJ1spH9Pg7ztC/etFQp9OM 8JlgnT9KniP3By/FDcw5GGRj63jMCl0Aa3J8pR1Lrn6gb3iAUUsMesVc0jB5hDpCdgr3 7av3MMGWaTmZMIFcBdfm6+6TfJOw266+inOPQLLEPdh6Ygs1TgWYlWO4qemVH1BPjZTN 5yysH8sMpcXFGmCDVD25Z0KXq+9eOgqS5DGJvf4hiPd1fa7F3jOA7PdmP+ZyAu07hCkI 90MA== X-Gm-Message-State: APjAAAXrAlq1v4UV4LLzENShywxCZTygLN9ybvUiu1n5NepXRWAaaSJ3 OxY+J5nQ3BXpjJ+KJbKh0cRJ1z8Ug9HcMn/1Eo6X1UxWfA== X-Google-Smtp-Source: APXvYqyiTUWn/7Z3gZ7ACLO16021lpR9EwDYyj39WUDnuRjACumqJdifp4uHINHi583+dl4DvqSPQpc5XH9cowF4oYs= X-Received: by 2002:aa7:c703:: with SMTP id i3mr5676481edq.295.1580419525265; Thu, 30 Jan 2020 13:25:25 -0800 (PST) MIME-Version: 1.0 From: Chet Ensign Date: Thu, 30 Jan 2020 16:25:14 -0500 Message-ID: To: media-types@ietf.org Cc: Bret Jordan Content-Type: multipart/alternative; boundary="000000000000665ed8059d62189b" Archived-At: Subject: [media-types] Update to media type registration: application/taxii+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 21:25:31 -0000 --000000000000665ed8059d62189b Content-Type: text/plain; charset="UTF-8" The members of the OASIS Cyber Threat Intelligence Technical Committee have approved TAXII Version 2.1 and wish to update the existing media type registration to reflect this change. This message contains the updated media-type registration from the IANA Considerations appendix of the spec ( https://docs.oasis-open.org/cti/taxii/v2.1/cs01/taxii-v2.1-cs01.html#_Toc31107565 ). This form contains only minor changes from the current registration: - A new paragraph has been added to the end of the Security considerations section. I have marked this paragraph with "[NEW]" - The Published specification has been updated to reference TAXII Version 2.1. - The 3 General Comments have been removed from the Additional information section Questions on the specification and this request can be submitted to Chet Ensign (chet.ensign@oasis-open.org) or, for technical details, to Bret Jordan (bret.jordan@broadcom.com), the specification's technical editor. --- Media type name: application Media subtype name: taxii+json Required parameters: None Optional parameters: version This parameter is used to designate the specification version of TAXII that is being used during HTTP content negotiation. Example: "application/taxii+json;version=2.1". The parameter value is of the form 'n.m', where n is the major version and m the minor version, both unsigned integer values. Encoding considerations: binary Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259]. Security considerations: These considerations are, in part, derived from Section 9 of the Resource-Oriented Lightweight Information Exchange [RFC8322]. This document defines a resource-oriented approach for exchanging cyber threat intelligence using HTTP [RFC7230] over TLS [RFC5246] and the JSON [RFC8259] Format. As such, implementers must understand the security considerations described in those specifications. Security considerations relating to the generation and consumption of TAXII messages are similar to application/json and are discussed in Section 12 of [RFC8259]. The discovery API contains one or multiple URLs, therefor the security considerations stated in Section 6 of [RFC1738] should be consulted especially in regard to parsing relative URLs and attempts of path traversal. Documents of "application/taxii+json" are simply request and response messages for an RPC like mechanism for searching, uploading and downloading Cyber Threat Intelligence (CTI) documents, most commonly STIX. The documents only contain metadata about the TAXII server, such as descriptions, versions of CTI or status response of the request. Documents do not contain active or executable content. Unicode is used to represent text such as descriptions in the format. The considerations documented by Unicode Technical Report #36: Unicode Security Considerations [UNICODE] should be taken into account. To protect the confidentiality of a given resource provided by a TAXII implementation, requests for retrieval of a resource need to be authenticated to prevent unauthorized users from accessing the resource. It can also be useful to log and audit access to sensitive resources to verify that proper access controls remain in place over time. Access control to content made available using TAXII should use mechanisms that are appropriate to the sensitivity of the information. While the primitive authentication mechanism of HTTP Basic Authentication [RFC7617] is mandatory to implement for base level interoperability it is rarely appropriate for sensitive information. A number of authentication schemes are defined in the "HTTP Authentication Schemes" registry at IANA [IANA AUTH]. Of these, HTTP Origin-Bound Authentication (HOBA) [RFC7486] and SCRAM-SHA-256 [RFC7804] ("SCRAM" stands for "Salted Challenge Response Authentication Mechanism") provide improved security properties over HTTP Basic [RFC7617] and Digest [RFC7616] authentication schemes. However, sharing communities that are engaged in sensitive collaborative analysis and/or operational response for indicators and incidents targeting high-value information systems should adopt a suitably stronger user authentication solution, such as a risk-based or multi-factor approach. Collaborating consortiums may benefit from the adoption of a federated identity solution, such as those based upon OAuth [RFC6749] with the JSON Web Token (JWT) [RFC7797], or SAML-core [SAML-core] ("SAML" stands for "Security Assertion Markup Language"), SAML-bind [SAML-bind], and SAML-prof [SAML-prof] for web-based authentication and cross-organizational single sign-on. Dependency on a trusted third-party identity provider implies that appropriate care must be exercised to sufficiently secure the identity provider. Any attacks on the federated identity system would present a risk to the consortium, as a relying party. Potential mitigations include deployment of a federation-aware identity provider that is under the control of the information-sharing consortium, with suitably stringent technical and management controls. It is recommended that all TAXII servers authenticate and authorize access to all collection data on a per-client basis using robust security methods. While this specification defines HTTP Basic as a minimum suggested authentication mechanism, more advanced security authentication methods are recommended when products or deployments require stronger authentication and authorization frameworks for accessing or posting data to the TAXII server. Authorization of resource representations is the responsibility of the source system, i.e., based on the authenticated user identity associated with an HTTP(S) request. The required authorization policies that are to be enforced must therefore be managed by the security administrators of the source system. Various authorization architectures would be suitable for this purpose, such as Role-Based Access Control (RBAC) [NIST RBAC] and/or Attribute-Based Access Control (ABAC), as embodied in the eXtensible Access Control Markup Language (XACML) [XACML]. In particular, implementers adopting XACML may benefit from the capability to represent their authorization policies in a standardized, interoperable format. Note that implementers are free to choose any suitable authorization mechanism that is capable of fulfilling the policy enforcement requirements relevant to their consortium and/or organization. While the authentication and confidentiality for the TAXII session is done at a lower level via the transport mechanism (HTTPS), this does not obviate the consumer (server or client) from validating the format and contents of the documents sent in a session. This validation should includes checking various limits, such as document size limits, to limit the risk of the other party attempting to attack the service. Additional security requirements such as enforcing message-level security at the destination system could supplement the security enforcements performed at the source system; however, these destination-provided policy enforcements are out of scope for this specification. Implementers requiring this capability should consider leveraging, for example, the element in the RID schema. Refer to Section 9 of [RFC6545] for more information. Additionally, the underlying JSON serialization used in the representation can offer encryption and message authentication capabilities. For example, JSON Web Encryption [RFC7516] and JSON Web Signature [RFC7515], can provide such mechanisms. TAXII Servers may manage response volume in different ways. Implementers should be aware that a search request may return more objects than is prudent to return in a single HTTP Response. To mitigate this, TAXII servers should consider implementing restrictions on the number of objects it will return in a single HTTP response. TAXII provides clients a rich set of filtering and query options to return specific results from repositories of CTI data. As such, TAXII servers should implement protections against queries that can potentially consume a significant amount of resources and prevent the server from functioning in a normal way. TAXII defines an optional error message that may contain sensitive application data. Implementers should ensure that they do not leak descriptive text or application return codes for things that a user may not have access to, for example leak info about existence of something, implementation of something, vs. just not having access. Note: Despite TAXII searching and returning STIX objects, this format does not encapsulate any CTI content. It is expected that CTI documents will be sent with the appropriate mime-type. For these, consult their own security consideration sections. [NEW] As the next URL parameter is a client provided property, care must be taken that it is not blindly trusted as the same value that the server returned as part of the TAXII Envelope. This means it MUST NOT be implicitly trusted, and the value MUST be reevaluated in the context of the provided query such that incorrect data (data that the client is not authorized to have or not part of the query set) is not returned. Privacy considerations These considerations are, in part, derived from Section 10 of the Resource-Oriented Lightweight Information Exchange [RFC8322]. The documents contain various descriptions and other text. There is no expectation that these will contain private information, but as some may be user provided, there is no guarantee that a user will not inadvertently include private data. It is expected that the client or server authenticate the other party through the transport mechanism before sending any possible private data. As the protocol is about sharing data, it is expected that the parties understand their obligations in keeping relevant data private. Adoption of the information-sharing approach described in this document will enable users to more easily perform correlations across separate, and potentially unrelated, cybersecurity information providers. A client may succeed in assembling a data set that would not have been permitted within the context of the authorization policies of either provider when considered individually. Thus, providers may face a risk of an attacker obtaining an access that constitutes an undetected separation of duties (SOD) violation. It is important to note that this risk is not unique to this specification, and a similar potential for abuse exists with any other cybersecurity information-sharing protocol. However, the wide availability of tools for HTTP clients implies that the resources and technical skills required for a successful exploit may be less than it was previously. This risk can be best mitigated through appropriate vetting of the client at the time of account provisioning. In addition, any increase in the risk of this type of abuse should be offset by the corresponding increase in effectiveness that this specification affords to the defenders. Overall, privacy concerns in TAXII can be mitigated by following security considerations and by the careful use of the content exchanged via TAXII. Interoperability considerations: The TAXII specification specifies the format of conforming messages and the interpretation thereof. In addition, the OASIS Cyber Threat Intelligence (CTI) Technical Committee has defined interoperability tests to ensure conforming products and solutions can exchange TAXII documents. Published specification: TAXII Version 2.1 OASIS Committee Specification 01 http://docs.oasis-open.org/cti/taxii/v2.1/cs01/taxii-v2.1-cs01.html Cited in the "OASIS Standards" document: https://www.oasis-open.org/standards#oasiscommiteespecs, from https://www.oasis-open.org/standards#taxii2.1 Applications which use this media: TAXII is an application layer protocol for the communication of cyber threat information including STIX in a simple and scalable manner. Fragment identifier considerations: None Restrictions on usage: None Additional information: 1. Deprecated alias names for this type: application/vnd.oasis.taxii+json 2. Magic number(s): n/a [RFC8259] 3. File extension(s): None 4. Macintosh file type code: TEXT [RFC8259] 5. Object Identifiers: None Person and email to contact for further information: Chet Ensign ( chet.ensign@oasis-open.org) Intended usage: COMMON Author: OASIS Cyber Threat Intelligence (CTI) Technical Committee; URI reference: https://www.oasis-open.org/committees/cti/. Change controller: OASIS Provisional registration: No -- /chet ---------------- Chet Ensign Chief Technical Community Steward OASIS: Advancing open source & open standards for the information society http://www.oasis-open.org Mobile: +1 201-341-1393 --000000000000665ed8059d62189b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The members of the OASIS Cyber Threat Intelligence Technic= al Committee have approved TAXII Version 2.1 and wish to update the existin= g media type registration to reflect this change.

This message conta= ins the updated media-type registration from the IANA Considerations append= ix of the spec (https://docs.oasis-open.org/cti/taxii/v2= .1/cs01/taxii-v2.1-cs01.html#_Toc31107565).

This form contains o= nly minor changes from the current registration:

- A new paragraph = has been added to the end of the Security considerations section. I have ma= rked this paragraph with "[NEW]"

- The Published specifica= tion has been updated to reference TAXII Version 2.1.

- The 3 Gener= al Comments have been removed from the Additional information section
Questions on the specification and this request can be submitted to Chet = Ensign (chet.ensign@oasis-ope= n.org) or, for technical details, to Bret Jordan (bret.jordan@broadcom.com), the specification'= ;s technical editor.

---

Media type name: =C2=A0application<= br>
Media subtype name: =C2=A0taxii+json

Required parameters: =C2= =A0None

Optional parameters: =C2=A0version

This parameter is = used to designate the specification version of TAXII that is being used dur= ing HTTP content negotiation. Example: "application/taxii+json;version= =3D2.1". The parameter value is of the form 'n.m', where n is = the major version and m the minor version, both unsigned integer values.
Encoding considerations: =C2=A0binary

Encoding considerations a= re identical to those specified for the "application/json" media = type. See [RFC8259].

Security considerations:

These considera= tions are, in part, derived from Section 9 of the Resource-Oriented Lightwe= ight Information Exchange [RFC8322].

This document defines a resourc= e-oriented approach for exchanging cyber threat intelligence using HTTP [RF= C7230] over TLS [RFC5246] and the JSON [RFC8259] Format.=C2=A0 As such, imp= lementers must understand the security considerations described in those sp= ecifications.

Security considerations relating to the generation and= consumption of TAXII messages are similar to application/json and are disc= ussed in Section 12 of [RFC8259].

The discovery API contains one or = multiple URLs, therefor the security considerations stated in Section 6 of = [RFC1738] should be consulted especially in regard to parsing relative URLs= and attempts of path traversal.

Documents of "application/taxi= i+json" are simply request and response messages for an RPC like mecha= nism for searching, uploading and downloading Cyber Threat Intelligence (CT= I) documents, most commonly STIX. The documents only contain metadata about= the TAXII server, such as descriptions, versions of CTI or status response= of the request. Documents do not contain active or executable content.
=
Unicode is used to represent text such as descriptions in the format. T= he considerations documented by Unicode Technical Report #36: Unicode Secur= ity Considerations [UNICODE] should be taken into account.

To protec= t the confidentiality of a given resource provided by a TAXII implementatio= n, requests for retrieval of a resource need to be authenticated to prevent= unauthorized users from accessing the resource. It can also be useful to l= og and audit access to sensitive resources to verify that proper access con= trols remain in place over time.

Access control to content made avai= lable using TAXII should use mechanisms that are appropriate to the sensiti= vity of the information. While the primitive authentication mechanism of HT= TP Basic Authentication [RFC7617] is mandatory to implement for base level = interoperability it is rarely appropriate for sensitive information.=C2=A0 = A number of authentication schemes are defined in the "HTTP Authentica= tion Schemes" registry at IANA [IANA AUTH].=C2=A0 Of these, HTTP Origi= n-Bound Authentication (HOBA) [RFC7486] and SCRAM-SHA-256 [RFC7804] ("= SCRAM" stands for "Salted Challenge Response Authentication Mecha= nism") provide improved security properties over HTTP Basic [RFC7617] = and Digest [RFC7616] authentication schemes. However, sharing communities t= hat are engaged in sensitive collaborative analysis and/or operational resp= onse for indicators and incidents targeting high-value information systems = should adopt a suitably stronger user authentication solution, such as a ri= sk-based or multi-factor approach.

Collaborating consortiums may ben= efit from the adoption of a federated identity solution, such as those base= d upon OAuth [RFC6749] with the JSON Web Token (JWT) [RFC7797], or SAML-cor= e [SAML-core] ("SAML" stands for "Security Assertion Markup = Language"), SAML-bind [SAML-bind], and SAML-prof [SAML-prof] for web-b= ased authentication and cross-organizational single sign-on.=C2=A0 Dependen= cy on a trusted third-party identity provider implies that appropriate care= must be exercised to sufficiently secure the identity provider.=C2=A0 Any = attacks on the federated identity system would present a risk to the consor= tium, as a relying party. Potential mitigations include deployment of a fed= eration-aware identity provider that is under the control of the informatio= n-sharing consortium, with suitably stringent technical and management cont= rols.

It is recommended that all TAXII servers authenticate and auth= orize access to all collection data on a per-client basis using robust secu= rity methods. While this specification defines HTTP Basic as a minimum sugg= ested authentication mechanism, more advanced security authentication metho= ds are recommended when products or deployments require stronger authentica= tion and authorization frameworks for accessing or posting data to the TAXI= I server.

Authorization of resource representations is the responsib= ility of the source system, i.e., based on the authenticated user identity = associated with an HTTP(S) request.=C2=A0 The required authorization polici= es that are to be enforced must therefore be managed by the security admini= strators of the source system.=C2=A0 Various authorization architectures wo= uld be suitable for this purpose, such as Role-Based Access Control (RBAC) = [NIST RBAC] and/or Attribute-Based Access Control (ABAC), as embodied in th= e eXtensible Access Control Markup Language (XACML) [XACML].=C2=A0 In parti= cular, implementers adopting XACML may benefit from the capability to repre= sent their authorization policies in a standardized, interoperable format.= =C2=A0 Note that implementers are free to choose any suitable authorization= mechanism that is capable of fulfilling the policy enforcement requirement= s relevant to their consortium and/or organization.

While the authen= tication and confidentiality for the TAXII session is done at a lower level= via the transport mechanism (HTTPS), this does not obviate the consumer (s= erver or client) from validating the format and contents of the documents s= ent in a session. This validation should includes checking various limits, = such as document size limits, to limit the risk of the other party attempti= ng to attack the service.

Additional security requirements such as e= nforcing message-level security at the destination system could supplement = the security enforcements performed at the source system; however, these de= stination-provided policy enforcements are out of scope for this specificat= ion. Implementers requiring this capability should consider leveraging, for= example, the <RIDPolicy> element in the RID schema. Refer to Section= 9 of [RFC6545] for more information. Additionally, the underlying JSON ser= ialization used in the representation can offer encryption and message auth= entication capabilities. For example, JSON Web Encryption [RFC7516] and JSO= N Web Signature [RFC7515], can provide such mechanisms.

TAXII Server= s may manage response volume in different ways. Implementers should be awar= e that a search request may return more objects than is prudent to return i= n a single HTTP Response. To mitigate this, TAXII servers should consider i= mplementing restrictions on the number of objects it will return in a singl= e HTTP response.

TAXII provides clients a rich set of filtering and = query options to return specific results from repositories of CTI data. As = such, TAXII servers should implement protections against queries that can p= otentially consume a significant amount of resources and prevent the server= from functioning in a normal way.

TAXII defines an optional error m= essage that may contain sensitive application data. Implementers should ens= ure that they do not leak descriptive text or application return codes for = things that a user may not have access to, for example leak info about exis= tence of something, implementation of something, vs. just not having access= .

Note: Despite TAXII searching and returning STIX objects, this for= mat does not encapsulate any CTI content. It is expected that CTI documents= will be sent with the appropriate mime-type. For these, consult their own = security consideration sections.

[NEW] As the next URL parameter is = a client provided property, care must be taken that it is not blindly trust= ed as the same value that the server returned as part of the TAXII Envelope= . This means it MUST NOT be implicitly trusted, and the value MUST be reeva= luated in the context of the provided query such that incorrect data (data = that the client is not authorized to have or not part of the query set) is = not returned.

Privacy considerations

These considerations are= , in part, derived from Section 10 of the Resource-Oriented Lightweight Inf= ormation Exchange [RFC8322].

The documents contain various descripti= ons and other text. There is no expectation that these will contain private= information, but as some may be user provided, there is no guarantee that = a user will not inadvertently include private data. It is expected that the= client or server authenticate the other party through the transport mechan= ism before sending any possible private data. As the protocol is about shar= ing data, it is expected that the parties understand their obligations in k= eeping relevant data private.

Adoption of the information-sharing ap= proach described in this document will enable users to more easily perform = correlations across separate, and potentially unrelated, cybersecurity info= rmation providers.=C2=A0 A client may succeed in assembling a data set that= would not have been permitted within the context of the authorization poli= cies of either provider when considered individually.=C2=A0 Thus, providers= may face a risk of an attacker obtaining an access that constitutes an und= etected separation of duties (SOD) violation. It is important to note that = this risk is not unique to this specification, and a similar potential for = abuse exists with any other cybersecurity information-sharing protocol.=C2= =A0 However, the wide availability of tools for HTTP clients implies that t= he resources and technical skills required for a successful exploit may be = less than it was previously.=C2=A0 This risk can be best mitigated through = appropriate vetting of the client at the time of account provisioning.=C2= =A0 In addition, any increase in the risk of this type of abuse should be o= ffset by the corresponding increase in effectiveness that this specificatio= n affords to the defenders.

Overall, privacy concerns in TAXII can b= e mitigated by following security considerations and by the careful use of = the content exchanged via TAXII.

Interoperability considerations:
The TAXII specification specifies the format of conforming messages an= d the interpretation thereof. In addition, the OASIS Cyber Threat Intellige= nce (CTI) Technical Committee has defined interoperability tests to ensure = conforming products and solutions can exchange TAXII documents.

Publ= ished specification:

TAXII Version 2.1 OASIS Committee Specification= 01

http://docs.oasis-open.org/cti/taxii/v2.1/cs01/taxii-v2.1-c= s01.html

Cited in the "OASIS Standards" document:
<= br>http= s://www.oasis-open.org/standards#oasiscommiteespecs, from

https://www.oasis-open.= org/standards#taxii2.1

Applications which use this media:
TAXII is an application layer protocol for the communication of cyber thre= at information including STIX in a simple and scalable manner.

Fragm= ent identifier considerations: =C2=A0None

Restrictions on usage: =C2= =A0None

Additional information:

1. Deprecated alias names for= this type: application/vnd.oasis.taxii+json

2. Magic number(s): n/a= [RFC8259]

3. File extension(s): None

4. Macintosh file type = code: TEXT [RFC8259]

5. Object Identifiers: None

Person and e= mail to contact for further information: =C2=A0Chet Ensign (chet.ensign@oasis-open.org)

Inten= ded usage: =C2=A0COMMON

Author:

OASIS Cyber Threat Intelligen= ce (CTI) Technical Committee;
URI reference: https://www.oasis-open.org/committees/cti/.=

Change controller: =C2=A0OASIS

Provisional registration: =C2= =A0No

--

/chet=C2=A0
---------= -------
Chet Ensign
Chief Technical Community Steward
OASIS= : Advancing open source & open standards for the information societyhttp://www.oasis-o= pen.org

Mobile: +1 201-341-1393=C2=A0
--000000000000665ed8059d62189b--