idnits 2.17.1
draft-schaad-mile-iodef-plasma-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 11, 2014) is 3718 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-05) exists of
draft-schaad-plasma-cms-04
== Outdated reference: A later version (-05) exists of
draft-schaad-plasma-service-04
** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970)
== Outdated reference: A later version (-11) exists of
draft-freeman-plasma-requirements-08
-- Obsolete informational reference (is this intentional?): RFC 5751
(Obsoleted by RFC 8551)
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MILE J. Schaad
3 Internet-Draft Soaring Hawk Consulting
4 Intended status: Standards Track February 11, 2014
5 Expires: August 15, 2014
7 Plasma Protected IODEF
8 draft-schaad-mile-iodef-plasma-00.txt
10 Abstract
12 The Incident Object Description Exchange Format (IODEF) defines a XML
13 representation for information about computer security incidents.
14 The driver for the standardization effort for IODEF is the desire to
15 share the information as part of the cybersecurity response. As the
16 security considerations of RFC5070 notes, the data can be sensitive
17 and should only be disclosed to appropriate parties. This document
18 describes how to use the Plasma policy enforcement model to ensure
19 access to the IODEF data follows the appropriate policies in a
20 distributed environment and independent of the transports used to
21 share the information.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on August 15, 2014.
40 Copyright Notice
42 Copyright (c) 2014 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
58 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2.1. Cybersecurity Information Sharing . . . . . . . . . . . . 4
61 2.1.1. Actors . . . . . . . . . . . . . . . . . . . . . . . 4
62 2.1.2. Plasma and the Traffic Light Protocol . . . . . . . . 5
63 2.1.3. Topologies . . . . . . . . . . . . . . . . . . . . . 5
64 2.1.4. Requirements for Strong Policy Enforcement on
65 Cybersecurity Information . . . . . . . . . . . . . . 6
66 2.2. PoLicy enhAnced Secure eMAil (Plasma) . . . . . . . . . . 6
67 2.2.1. Benefits of Policy Enforcement on Cybersecurity
68 Information Sharing . . . . . . . . . . . . . . . . . 7
69 2.2.2. Plasma Policies and Decisions . . . . . . . . . . . . 8
70 2.3. Plasma and IODEF . . . . . . . . . . . . . . . . . . . . 8
71 2.4. Plasma and Layered Application Design . . . . . . . . . . 11
72 3. The Plasma Protected IODEF Data Model . . . . . . . . . . . . 12
73 3.1. PlasmaToken Class . . . . . . . . . . . . . . . . . . . . 12
74 3.1.1. EncryptedDataHashs Class . . . . . . . . . . . . . . 13
75 4. Plasma Service Request/Response Messages . . . . . . . . . . 14
76 4.1. Create IODEF Documents Request . . . . . . . . . . . . . 14
77 4.2. Create IODEF Document Response . . . . . . . . . . . . . 15
78 4.3. Read IODEF Document Request . . . . . . . . . . . . . . . 16
79 4.4. Read IODEF Document Response . . . . . . . . . . . . . . 17
80 5. Processing Rules for protected IODEF . . . . . . . . . . . . 18
81 5.1. Creating Protected IODEF data . . . . . . . . . . . . . . 18
82 5.2. Receiving Protected IODEF data . . . . . . . . . . . . . 18
83 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20
84 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 22
85 7.1. IODEF Document with encrypted classes . . . . . . . . . . 22
86 7.2. Plasma Token . . . . . . . . . . . . . . . . . . . . . . 23
87 8. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 25
88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
91 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
92 11.2. Informative References . . . . . . . . . . . . . . . . . 26
93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
95 1. Introduction
97 It has long been held that 'knowledge is power' and that getting the
98 right information in a timely manner to decision makers helps them
99 make well informed decisions. In cybersecurity, that information is
100 often spread across many stakeholders. Getting the right information
101 to the operational teams responding to cybersecurity incident helps
102 them reduce risks, deter attacks, mitigate exploits and enhance
103 resilience. The need for effective and timely information sharing
104 has been recognized by policymakers, executives and security
105 professionals alike.
107 At times, cybersecurity information will be sensitive e.g. because of
108 national security implications or due to potential commercial
109 business impact. Policy will require the information has to be
110 shared on a need-to-know basis which requires definition and
111 enforcement of some criteria to establish a subjects need to know the
112 information. The stakeholders need both confidence in the robustness
113 of the technical controls which implement the policy as well as a
114 means to demonstrate compliance with the policy as prerequisites to
115 entrusting their sensitive data to such a system.
117 The need for information sharing is a fundamental part of
118 collaborative endeavors. It can take many forms due to the context
119 of the collaboration. The policies governing the information sharing
120 also apply to the information regardless of which tool us used to
121 convey the information. Collaborative efforts have a rich and
122 diverse toolset for exchanging information and cybersecurity
123 collaboration is no exception. It is necessary for any policy
124 enforcement mechanism supporting information exchange such as IODEF
125 be part of a "bigger picture" so that the same policies can be
126 enforced on any cybersecurity information regardless of the tools
127 used to share that information.
129 1.1. Requirements Terminology
131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
133 document are to be interpreted as described in [RFC2119].
135 When the words appear in lower case, their natural language meaning
136 is used.
138 2. Background
139 2.1. Cybersecurity Information Sharing
141 Calls to enhance cybersecurity information sharing have been made
142 regularly over the past two decades. The need for cybersecurity
143 information sharing within private critical infrastructure sectors
144 and with the government has been identified as an important practice
145 to help better secure the increasingly cyber-dependent critical
146 infrastructure. Any policy controls also have to strike a balance
147 between reasonable and robust technical controls and legal
148 enforcement of contractual obligations.
150 2.1.1. Actors
152 There are a number of different actors involved in the cybersecurity
153 ecosystem who are each looking for and contributing different
154 information which requires control not only access to the data but
155 also use and onward publication of the information.
157 Governments are concerned about national economic and security
158 issues.
160 Enterprises are subject to cybercrime and cyberespionage and need
161 to protect their sensitive information such as customer data,
162 intellectual property and trade secrets.
164 IT companies who provide products and services to Governments and
165 enterprises are concerned about the security and integrity of
166 their offerings
168 IT security firms who offer security specific products and
169 services as well as cybersecurity information are concerned about
170 keeping their products and services current.
172 Researchers track incidents and find vulnerabilities in the
173 products and services from IT companies are looking for new events
174 and trends in the data.
176 Academia performs security research.
178 There are several types of cybersecurity information: incidents,
179 situational awareness, best practices, strategic analysis, threat,
180 vulnerability, and mitigation information. These various types of
181 information have different uses, and are often produced and utilized
182 for different purposes by the different actors. This is a similar
183 situation to health care where a health care practitioner and medical
184 statistician would both need access to a particular medical record
185 for totally different purpose, one where the identity of the patient
186 is part of the data set and one where the information forms part of
187 an anonymous data set. Similar consideration exist for cybersecurity
188 information so access control need to be flexible to enables
189 different forms of data use without compromising compliance.
191 2.1.2. Plasma and the Traffic Light Protocol
193 The Traffic Light Protocol (TLP) is a means for the originator of
194 data to indicate how widely they want the information shared. It is
195 an advisory notice and relies on the recipients being trusted to
196 understand and obey the rules of the protocol. The originator marks
197 the information with a hierarchical marking to indicate the scope of
198 the onward dissemination of the information. The markings are as
199 follows
201 RED Most restrictive, Very small community of interest. Admission
202 to the community strictly controlled. Typically named recipients
203 only.
205 AMBER Limited Disclosure. Moderate sized community of interest
206 within participating organizations. Reasonable need to know
207 admission test to community of interest. Typically named
208 organizations only.
210 GREEN Moderate Disclose. Large community of interest with
211 participating organizations and their partners. Minimal need to
212 know test for admission to community of interest.
214 WHITE Public Data
216 Plasma allow for the implementation of the TLP with more rigor where
217 the incident owner can better control the release of the information.
218 The incident owner can define specific kneed to know criteria it
219 deems appropriate for the incident and for the current TLP making to
220 be communicated to the recipient. As the incident transitions from
221 breaking news to ancient history, it allows the incident owner to
222 relax the policy accordingly without impacting the incident data held
223 across the ecosystem.
225 2.1.3. Topologies
227 Cybersecurity information sharing used an asynchronous message
228 paradigm. The Information sharing can follow all the standard
229 topology options
231 o Peer to Peer
233 o Mesh Topology
234 o Star Topology
236 Peer to peer offer the highest control and security but does not
237 scale and is the most fragile. The other topologies improve the
238 scalability and availability but at the cost of security and control.
239 Nodes in the more complex topologies would typically not be under the
240 control of the senders or recipients organizations. They may be
241 trusted to route messages between senders and recipients but do not
242 have a need to know the content of cybersecurity information. The
243 need to leverage services to enable high availability and resilience
244 without the need to also trust such services with sensitive data is
245 paramount. This is similar to email which has similar topologies
246 where users trust services to deliver email and be highly resilient
247 and available while not wanting them to have access to sensitive
248 content.
250 2.1.4. Requirements for Strong Policy Enforcement on Cybersecurity
251 Information
253 o For the ecosystem to enable the data sharing while enforcing the
254 policy considerations around the sensitivity and use of the data.
256 o For the actors, devising new ways to use the data so any policy
257 enforcement mechanism need to be flexible and extensible to adapt
258 to the changes.
260 o Public and private laws will continue to evolve and adapt so any
261 policy enforcement mechanism needs to be extensible and expressive
262 to ensure fidelity of the policy.
264 o For implementers, to have a mechanism which abstracts them as much
265 as possible from the details of the policy decisions. To have a
266 clear and concise set of requirements to enable the policy
267 decisions.
269 to do: more in data use and policy
271 2.2. PoLicy enhAnced Secure eMAil (Plasma)
273 Email remains one of the most wildly used tools for collaboration.
274 It has mature and widely deployed standards for security in S/MIME
275 [RFC5751] and PGP [RFC4880] which deliver basic security services
276 (confidentiality, integrity and data origin authentication). S/MIME
277 also has optional Enhanced Security Service [RFC5035] which can
278 deliver policy enforcement on S/MIME messages.
280 Despite all this, secure email is still the exception as a percentage
281 of the overall email traffic. It is used in communities of interest
282 including cybersecurity, but does not deliver robust policy
283 enforcement on the contents of the message. Plasma was an effort to
284 fundamentally rethink and update email security model to enable it to
285 align with other technologies and enable its broader use and deliver
286 strong policy enforcement on message continents. Though some of the
287 work was specific to S/MIME [I-D.schaad-plasma-cms], it was based on
288 a generic data model [I-D.freeman-plasma-requirements] and has a
289 generic decision request\response protocol
290 [I-D.schaad-plasma-service] which can support other types of data and
291 applications.
293 Plasma developed a generic data model for policy enforcement on
294 information. One of the objectives of the model is to enable
295 consistent policy enforcement on information for a broad set of
296 users, across a broad set of environments and applications. The
297 Plasma data model, leverages many of the developments in identity and
298 identity attributes. Plasma closely ties the meta-data of the
299 applicable policies to data in order to deliver consistent policy
300 enforcement for mobile data. It users a tamper proof binding so the
301 policy relationship reliably travels with the data. The model relies
302 on attributes about the subject requesting access, their system, the
303 data and their environments as inputs to the policy to deliver
304 Attribute Based Access Control (ABAC). The policy processing is
305 complex so the model does not require the rules to be distributed to
306 clients. The clients request decisions from a Policy Decision and
307 Enforcement Point (PDEP) service who render decisions for the
308 subjects. The PDEP's in turn, discover the necessary policy from
309 Policy Authoring Points.
311 2.2.1. Benefits of Policy Enforcement on Cybersecurity Information
312 Sharing
314 For the Actors, it incentivize the exchange of the very freshest and
315 interesting data, maximizes the way to derive intelligence from the
316 data while managing the risk of unexpected use or abuse of the
317 information.
319 For the regulators, and lawyers, it supports their policy needs in a
320 smarter, more business friendly way.
322 For implementers, it simplifies thief products by abstracting a wide
323 variety of issues to be policy decisions.
325 For the ecosystem, it supports new use cases at scale with reduced
326 compliance costs.
328 2.2.2. Plasma Policies and Decisions
330 Polices in Plasma are set of rules which render either a result
331 (permit, deny) or an error (indeterminate, and unknown) based on the
332 supplied attributes of a request. Decisions are logic gates where
333 one or more policies together with their logical relationship are
334 used together to render a policy decision (permit, deny) or an error
335 (indeterminate, and unknown). A single Plasma Token can contain one
336 or more decision logic gates making it possible to render multiple
337 decisions from a single request. The number of decisions within the
338 policy object is hidden by design from the client. Each decision is
339 enforced by a separate encryption key. A separate policy object
340 would only be required if a Plasma server was not trusted to make a
341 decision for all policies e.g. data being aggregated from different
342 communities.
344 Information may be shared under multiple policies, for examples an
345 organization may have specific cybersecurity information sharing
346 agreements with some organizations, and pre-existing non-disclosure
347 agreements with other organizations and an incident could be shared
348 providing one or other of the policies is met. Equally, information
349 from different organizations can be commingled e.g. where an IODEF
350 document contains incident's from different organizations, where each
351 organization would be asserting its policies on the incident data.
352 Both scenarios are supported by Plasma. The policy request and
353 evaluation process can be time consuming therefore content creators
354 should minimize the number of policy objects and policy decisions
355 where creating content for publication.
357 Full details of the Plasma data model can be found in Section 4 of
358 the Requirements for Message Access Control
359 [I-D.freeman-plasma-requirements]
361 2.3. Plasma and IODEF
363 XML encryption allows for very granular protection of sensitive data
364 in an XML document. It allows for protection of entire elements,
365 element content and arbitrary data in XML documents. XML encryption
366 can also be nested whereby part of the data being encrypted is
367 already encrypted (Super-Encryption). This allows the content
368 creator of an IODEF documents full control to protect any portion of
369 the document they need. Once the data has been encrypted, Plasma
370 allows the encryption key to be linked to a Plasma Decision via the
371 Plasma Token where one or more policies can be combined to reflect
372 the data governance requirements of the information. Cybersecurity
373 information in the IODEF document requiring different data
374 governance, can be combined in a single document and protected with
375 different keys linked to different decisions.
377 +-----------------+ +-----------------+
378 | Plasma Token | | IODEF Incident |
379 +-----------------+ +-----------------+
380 | Policy Decision |----------------| Encrypted Data |
381 | CEK ID ABCD | | CEK ID ABCD |
382 | CEK 2412 | | HASH 1234 |
383 +-----------------+ +-----------------+
384 | HASH 1234 |
385 +-----------------+
387 Figure 1: Single Plasma Policy Decision and Protected Incident
389 This is the simplest example with a single incident and a single
390 decision. The incident is encrypted with a single CEK. If a
391 recipient passes the policy decision check, the Plasma server would
392 release the CEK enabling the recipient to decrypt the incident.
394 +-----------------+ +-----------------+
395 | Plasma Token | | IODEF Incident |
396 +-----------------+ +-----------------+
397 | Policy Decision |----------------| Encrypted Data |
398 | CEK ID ABCD | | | CEK ID ABCD |
399 | CEK 2412 | | | HASH 1234 |
400 +-----------------+ | +-----------------+
401 | HASH 1234 | |
402 | 5678 | | +-----------------+
403 +-----------------+ | | IODEF Incident |
404 | +-----------------+
405 +--------| Encrypted Data |
406 | CEK ID ABCD |
407 | HASH 5678 |
408 +-----------------+
410 Figure 2: Single Plasma Policy Decision and Two Protected Incidents
411 with Same Policy Decision
413 When there are multiple incidents subject to the same decision, they
414 are encrypted using the same CEK. Again, a recipient passing the
415 policy decision check, will receive the CEK which enables them to
416 decrypt both incidents.
418 +-----------------+ +-----------------+
419 | Plasma Token | | IODEF Incident |
420 +-----------------+ +-----------------+
421 | Policy Decision |----------------| Encrypted Data |
422 | CEK ID ABCD | | | CEK ID ABCD |
423 | CEK 2412 | | | HASH 1234 |
424 | Policy Decision | | +-----------------+
425 + CEK ID A1B2 | |
426 | CEK F469 | |
427 +-----------------+ | +-----------------+
428 | HASH 1234 | | | IODEF Incident |
429 | 5678 | | +-----------------+
430 +-----------------+ +--------| Encrypted Data |
431 | CEK ID A1B2 |
432 | HASH 5678 |
433 +-----------------+
435 Figure 3: Single Plasma Policy Decision and Two Protected Incidents
436 with Two Policy Decision
438 When there are incidents subject to different policy decision, this
439 can still be accommodated within the same token and hence same
440 decision request. Each incident is encrypted with different CEK, one
441 CEK per decision. A recipient receives the CEK for every policy
442 check they pass.
444 +-----------------+ +-----------------+
445 | Plasma Token | | IODEF Incident |
446 +-----------------+ +-----------------+
447 | Policy Decision |---------| Encrypted Data |
448 | CEK ID ABCD | | CEK ID ABCD |
449 | CEK 2412 | | HASH 1234 |
450 | Policy Decision | +-----------------+
451 + CEK ID A1B2 | |
452 | CEK F469 | |
453 +-----------------+ | +-----------------+
454 | HASH 1234 | | | Assessment |
455 | 5678 | | +-----------------+
456 +-----------------+ +--------| Encrypted Data |
457 | CEK ID A1B2 |
458 | HASH 5678 |
459 +-----------------+
461 Figure 4: Single Plasma Policy Decision, a Protected Incidents with
462 child class with a different policy decision
464 The same approach can be applied when an incident has a child class
465 with a different policy to the parent. The child class is encrypted
466 with different CEK to the parent. A recipient receives the CEK for
467 every policy check they pass.
469 Question: Do we need to add a policy token consolidation request i.e.
470 if a client finds multiple tokens from the same server, submit to
471 server and ask for them to be merged into one.
473 2.4. Plasma and Layered Application Design
475 Today's applications are built using separate layers which group
476 components which discreet functions together into distinct layers.
477 These layers can be described as follows
479 o Presentation Layer: Components responsible for managing users
480 interaction with the application
482 o Business Layer: Components responsible for core business logic
484 o Data Layer: Components responsible for interacting with data
485 sources to enable the abstraction of the storage mechanism from
486 business layer.
488 +--------------------+
489 | Users |
490 +--------------------+
491 |
492 |
493 +--------------------+
494 | Presentation Layer |
495 +--------------------+
496 |
497 |
498 +--------------------+
499 | Business Layer |
500 +--------------------+
501 |
502 |
503 +--------------------+
504 | Data Layer |
505 +--------------------+
506 | |
507 | |
508 +--------------+ +--------------+
509 | Data Source | | Services |
510 +--------------+ +--------------+
512 Figure 5: Layered Application Model
514 The objective of the layers is to deliver the best maintainability,
515 extensibility and flexibility for the application. Plasma is part of
516 the security service which is a cross layer function which can
517 manifest in all layers. The layers are a logical separation which
518 allows for the different components to be deployed in different
519 physical combinations to respond to different sociability,
520 performance and security considerations without impacting the
521 underlying components.
523 The Plasma model fully supports the layered application model.
524 Access to data becomes a policy issue i.e. does the policy allow the
525 subject to access the data. For example if the business layer was
526 deployed on a server or local on the users client, it would change
527 the identity of the subject and (and the attributes) of the access
528 request, but providing the subject met the policy requirements,
529 either could be given access to the data.
531 3. The Plasma Protected IODEF Data Model
533 Note. Some harmonization work is in progress between this document
534 and [I-D.schaad-plasma-service] so XML schema names and types may
535 change as a result.
537 The Plasma protected IODEF model supports IODEF documents with
538 multiple Incident's. If all the incidents have the same security
539 policy, then the same Plasma server(s) can control access to all the
540 Incidents and a single instance of the Plasma Token containing a
541 single content encryption key (CEK) for all incidents can be used.
542 If incidents have different security polices, but the same Plasma
543 server is trusted to perform the access control decision for all the
544 policies, again a single instance of the Plasma Token with multiple
545 CEKs can be used (one for each decision). If the Incidents have
546 different security policies and the same Plasma server is not trusted
547 with all the decisions then multiple Plasma Tokens can be used.
549 3.1. PlasmaToken Class
551 The PlasmaToken class contains the Plasma meta-data that allows the
552 Plasma server to enforce policy decisions on the protected IODEF
553 data. This is an XML analog of the ASN.1 encoded Plasma token
554 structure defined in [I-D.schaad-plasma-cms]. The Plasma token
555 contains encrypted content defined in [I-D.schaad-plasma-cms] which
556 is processed by the Plasma server to convey policy requirements and
557 content encryption keys. The token is signed by the Plasma server
558 and the signature has signed elements to enable the receiving client
559 to process the Plasma Token. It has a signed element with one or
560 more URIs that identify the set of Plasma servers which can process
561 the Policy Token. It also has an element containing the hash(s) of
562 the encrypted content associated with the token to establish a
563 binding between the protected IODEF data and the specific Plasma
564 Token.
566 The PlasmaToken class uses the Class extension mechanism defined in
567 [RFC5070] Section 5.2.
569 +-------------------------+
570 | PlasmaToken |
571 +-------------------------+
572 | |<>----------[ EncryptedData ]
573 | |<>--(1..*)--[ ServerURI ]
574 | |<>----------[ EncryptedDataHashs ]
575 +-------------------------+
577 Figure 6: PlasmaToken Class
579 The aggregate classes in the Plasma Token are as follows:
581 EncryptedData One. The element defined in
582 [W3C.WD-xmlenc-core1-20101130] that contains the encrypted data used
583 by the Plasma server to process access requests to the protected
584 IODEF data. The encapsulated contents of this element are defined in
585 [I-D.schaad-plasma-cms]
587 ServerURI One or more. The URI of one or more Plasma servers which
588 can process decisions requests for the Plasma Token. The order of
589 URLs does not indicate any order of priority, it is a matter of local
590 client policy on the order to use. The URL defines both the
591 destination server and the protocol to be used. When the schema for
592 the URL is "plasma", then the protocol which MUST be used is
593 [I-D.schaad-plasma-service].
595 It is a matter of local policy of the IODEF recipient if it chooses
596 to contact one of the plasma servers identified by the ServerURI
597 based on their trust in the identity of the signer of the Plasma
598 Token.
600 3.1.1. EncryptedDataHashs Class
602 Todo, this might get wrapped into the re-factoring.
604 For privacy reasons, it is highly desirable that the recipient client
605 of an IODEF document can validate that the Plasma Token embedded in a
606 document, is associated with the encrypted data it is attached to
607 prior to contacting the Plasma server. For this reason, in addition
608 to the requirement that a recipient validate the signature of the
609 Plasma server over the token, a new element is defined which contains
610 one or more hashes of the encrypted content(s). These encrypted data
611 hashes constitute a detached signature of the encrypted content.
613 The EncryptedDataHashs class contains the hash values for the one or
614 more sets of encrypted data.
616 +--------------------------+
617 | EncryptedDataHashes |
618 +--------------------------+
619 | |<>----------[ DigestMethod ]
620 | |<>--(1..*)--[ DigestValue ]
621 +--------------------------+
623 Figure 7: EncryptedDataHashs Class
625 DigestMethod one. The element defined in
626 [W3C.WD-xmldsig-core2-20100831] that identifies the digest algorithm
627 to be applied to the encrypted protected data e.g. an encrypted
628 incident, associated with the Plasma Token.
630 DigestValue One or more. The element defined in
631 [W3C.WD-xmldsig-core2-20100831] that contains the encoded value of
632 the digest of the encrypted protected data. If the token has been
633 used to protect multiple elements e.g. multiple incidents, then there
634 will be multiple digest values.
636 4. Plasma Service Request/Response Messages
638 This specification uses the [I-D.schaad-plasma-service] specification
639 to process decision requests for IODEF protected data. This
640 specification defines new actions and token types.
642 4.1. Create IODEF Documents Request
644 The create document message request is built using the
645 Plasma:PlasmaRequest XML structure defined in
646 [I-D.schaad-plasma-service]. When building the request, follow
647 [I-D.schaad-plasma-service] with the following changes:
649 o The client MUST include an action attribute. The document defines
650 the GetXMLPlasmaToken action attribute.
652 o A message requesting a XML Plasma token looks like this:
654
655
656
657 Role Token goes here
658
659
660
661
662
663
664 GetXMLPlasmaToken
665
666
667
668
669
670
671
672
673 ... Label Tree for message ...
674
675
676 ... Hash algorithm and hash(s) of encrypted content ...
677
678
679 ... Content Encryption Key ...
680
681
682
683
684
685
686
688 4.2. Create IODEF Document Response
690 In response to a create document request, the Plasma server returns a
691 create document response message. The response messages uses the
692 plasma:PlasmaResponse XML structure. When the response message is
693 created, the following should be noted:
695 o The xacml:Decisions is always included in the response. If the
696 'Permit' value is returned then the Plasma:XMLToken element MUST
697 be present.
699 o The PlasmaReturnToken element with a Plasma:XMLToken content is
700 included with a permit response.
702 An example of a message returning the set of policy information is:
704
705
706
707 Permit
708
709
710
711 xxx token xxxx
712
713
715 4.3. Read IODEF Document Request
717 The client sends a request to the Plasma server that is identified in
718 the token. For the XML tokens, the address of the Plasma server to
719 use is located in the ServerURI element of the Plasma Token.
721 The request uses the plasma:PlasmaRequest XML structure. When
722 building the request, the following should be noted:
724 o The xacml:Request MUST be present in the first message of the
725 exchange.
727 o The action used to denote that a XML token should be decrypted is
728 "ParseXMLToken"
730 o The XML token to be cracked is identified by "XMLToken"
732 o If the client is using the XML Digital Signature element in this
733 message, then the client MUST include the cryptographic channel
734 binding token (Section 10.1.1) in the set of XACML attributes.
736 An example of a message returning the set of policy information is:
738
739 ...
740
741
742
743 ParsePlasmaToken />
744
745
746
747
748 XML Token
749
750
751
752
754 4.4. Read IODEF Document Response
756 In response to a parse token request, the Plasma server returns a
757 decrypted key in the response. The response uses the plasma:Plasma
758 XML structure. When a response message is create the following
759 should be noted:
761 o If the Plasma Token contained multiple decisions, a single
762 response can be used for all decisions.
764 o For each decision, if the value of xacml:Decision is Permit, then
765 response MUST include an Plasma:XMLKey element.
767 o For each decision, if the value of xacml:Decision is not Permit,
768 the plasma:XMLKey MUST be absent.
770 An example of a message returning the set of policy information is as
771 follows:
773
774
775
776 Permit
777
778
779
780 Label Text
781 hex based KEK
782
783
785 5. Processing Rules for protected IODEF
787 This is the set of processing steps that either a creator or receiver
788 of protected IODEF needs to follow. The order of the steps is not
789 normative.
791 5.1. Creating Protected IODEF data
793 These are the step that the creator of an protected IODEF message
794 needs to do.
796 1. The creating agent obtains the set of policies under which it can
797 create IODEF data.
799 2. The creating agent composes the IODEF content.
801 3. The creating agent determines the set of policies to be applied
802 to the IODEF content.
804 4. The creating agent selects the content encryption algorithm (with
805 input from the obligations of the policies chosen) and randomly
806 creates the CEK(s).
808 5. The creating agent encrypts the content with the CEK and computes
809 the encrypted hash value.
811 6. The creating agent transmits the CEK, the hash of the encrypted
812 content value(s) and the policy label(s) to the PLASMA server.
814 7. If the creating agents request passes the Plasma server policy
815 check, the Plasma server will return the Plasma Policy meta-data
816 to the creating agent. If the policy validation fails then the
817 creator cannot send the IODEF message under the requested policy
818 label.
820 8. The creating agent verifies the signature on the Plasma Policy
821 meta-data. If the Signature is current and passes cryptographic
822 processing the sender can add the policy meta-data to the
823 appropriate PolicyData element and sends the IODEF message.
825 5.2. Receiving Protected IODEF data
827 These are the steps that the recipient of a protected IODEF message
828 needs to follow. The order of the steps is not normative.
830 1. The Receiving Agent obtains the message from another IODEF agent.
832 2. The Receiving Agent recognizes that it is protected IODEF
833 content.
835 3. The Receiving Agent validates the PolicyData attribute. The
836 following steps need to be taken for validation.
838 A. The signature on the PolicyData structure is validated. If
839 the validation fails then processing ends.
841 B. The certificate used to validate the signature MUST contain
842 the XXXX value in the EKU extension. The certificate MUST
843 NOT contain the anyPolicy value in the EKU extension. Local
844 policy can dictate that content of the PlasmaURL attribute be
845 used in selecting trust anchors for the signing certificate.
847 C. If the PlasmaURL attribute is absent, then processing fails.
849 D. The URL value in the PlasmaURL attribute is checked against
850 local policy. If the check fails then processing fails.
851 This check is performed so that information about the user is
852 not given to a random Plasma server. The schema of the URL
853 MUST be one that the client implements. (For example the
854 "plasma" schema associated with RFC XXX
855 [I-D.schaad-plasma-service].) As discussed in Section 4.5 of
856 [I-D.freeman-plasma-requirements], policy can be enforced on
857 the edge of an enterprise, this means that if multiple URLs
858 are present in the Plasma URL attribute they all need to be
859 checked for policy and ability to use before this step fails.
861 E. The EncryptedHash attribute value is checked against the
862 encrypted content. If this attribute is absent then
863 processing fails. If the value does not matched the computed
864 value on the encrypted content then processing fails.
866 4. The recipient agent gathers the necessary identity and attribute
867 statements, usual certificates or SASL statements.
869 5. The recipient agent establishing a secure connection to the
870 Plasma server and passes in the identity and attribute statements
871 and receives back the CEK or a lock box to allow it to obtain the
872 CEK value.
874 6. the recipient agent uses the returned CEK to decrypt the
875 protected content and compares the generated Message
876 Authentication Code for the value in Authentication Tag and fail
877 if they don't match.
879 6. Examples
881 The following example is an IODEF document with 3 incidents. The
882 first is a public incident where all data is in the clear. The
883 second incident is a public incident with a private contact. The
884 third incident is private.
886
887
893
894
896
897
898
899
900
901
902
903
904
905
906 CERT-OUR-DOMAIN#111-2/>
908 2014-02-06T10:21:00+00:00 />
909
910
911
912
913
915
916 Plasma#1
917
918
919
920
921
922
923
924
925
927
928
929
930
931 XXXX Encrypted Incident XXXX />
932
933
934
935
936
937
938
939
940
942
944
945
947 XXXX Digest XXXX/>
948
949
950 XXXX Signature XXXX />
951
952 Put a certificate here
953
954
955
956
957 xxxxxxxxxx />
958
959
960
961 XXXXX#1
962 XXXXXX#2
963
964
965
966
967
968
969
970
972 7. XML Schema
974 This schema is the XML analogue of the CMS recipient info structure
975 defined in [I-D.schaad-plasma-cms]. It contains the encrypted data
976 used by the Plasma server. The encrypted data contains the policy
977 decision leaf structures and CEKs. It also has any other attributes
978 necessary for processing the request e.g. resource and audit
979 attributes. The Plasma token also has a number of signed elements
980 necessary for the client to process the token.
982 7.1. IODEF Document with encrypted classes
984 When a client wants to validate the XML schema of an IODEF document
985 containing encrypted classes prior to processing the contents, it
986 MUST use a modified schema which allows for the substitution of the
987 encrypted elements.
989 For example the current IODEF document class is as follows
991
992
993
994
996
997
998
999
1000
1001
1003 The modified class schema needs to be as follows:
1005
1006
1007
1008
1010
1011
1012
1013
1014
1015
1017
1018
1019 ref="iodef:Incident"/>
1020
1022
1023
1025 The choice between the encrypted and unencrypted class MUST be
1026 inserted in every class with a restriction attribute.
1028 7.2. Plasma Token
1029
1030
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1072 8. Mandatory Algorithms
1074 Clients MUST implement the mandatory algorithms defined for XML
1075 encryption [W3C.WD-xmlenc-core1-20101130] for the encryption of IODEF
1076 document contents. Clients SHOULD use AES128-GCM unless otherwise
1077 directed by a policy obligation. Other algorithms may be
1078 implemented.
1080 Clients MUST implement SHA-256 and SHA-512 as defined for message
1081 digest [W3C.WD-xmlenc-core1-20101130] for computation of the
1082 Encrypted Content Hash. Clients SHOULD use SHA-256 unless otherwise
1083 directed by a policy obligation. Other algorithms MAY be
1084 implemented.
1086 When verifying signatures on the Plasma Token, clients MUST be able
1087 to verify the RSA v1.5 signature algorithm with SHA-256 and SHA-512.
1088 Clients MUST also be able to verify the EC-DSA signature algorithm
1089 with SHA-256 and SHA-512 signature algorithm. Clients MAY be able to
1090 verify other signature algorithms.
1092 9. Security Considerations
1094 A malicious Plasma server can generate a Plasma token over any
1095 protected content i.e. there is no guarantee that the Plasma server
1096 knows the CEK of the protected data or if it is genuine data at all
1097 and free from malicious content. For example, it can generate a new
1098 Plasma token for some existing protected content with the hashes of
1099 the encrypted data. The fact that the signature of the Plasma token
1100 validates along with the hashes of the encrypted data is only a
1101 integrity check over the data set i.e. if it fails, processing should
1102 fail. The fact that the signature and associate data hashes
1103 validates MUST NOT be uses as any indication of trustworthiness of
1104 the Plasma Server.
1106 10. IANA Considerations
1108 Tbd
1110 11. References
1112 11.1. Normative References
1114 [I-D.schaad-plasma-cms]
1115 Schaad, J., "Plasma Service Cryptographic Message Syntax
1116 (CMS) Processing", draft-schaad-plasma-cms-04 (work in
1117 progress), March 2013.
1119 [I-D.schaad-plasma-service]
1120 Schaad, J., "Plasma Service Trust Processing", draft-
1121 schaad-plasma-service-04 (work in progress), January 2013.
1123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1124 Requirement Levels", BCP 14, RFC 2119, March 1997.
1126 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
1127 Object Description Exchange Format", RFC 5070, December
1128 2007.
1130 [W3C.WD-xmldsig-core2-20100831]
1131 Eastlake, D., Reagle, J., Solo, D., Yiu, K., Hirsch, F.,
1132 Roessler, T., and P. Datta, "XML Signature Syntax and
1133 Processing Version 2.0", World Wide Web Consortium WD WD-
1134 xmldsig-core2-20100831, August 2010,
1135 .
1137 [W3C.WD-xmlenc-core1-20101130]
1138 Roessler, T., Reagle, J., Hirsch, F., and D. Eastlake,
1139 "XML Encryption Syntax and Processing Version 1.1", World
1140 Wide Web Consortium LastCall WD-xmlenc-core1-20101130,
1141 November 2010,
1142 .
1144 11.2. Informative References
1146 [I-D.freeman-plasma-requirements]
1147 Freeman, T., Schaad, J., and P. Patterson, "Requirements
1148 for Message Access Control", draft-freeman-plasma-
1149 requirements-08 (work in progress), October 2013.
1151 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
1152 Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
1154 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
1155 Adding CertID Algorithm Agility", RFC 5035, August 2007.
1157 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
1158 Mail Extensions (S/MIME) Version 3.2 Message
1159 Specification", RFC 5751, January 2010.
1161 Author's Address
1163 Jim Schaad
1164 Soaring Hawk Consulting
1166 Email: ietf@augustcellars.com