idnits 2.17.1 draft-birkholz-attestation-terminology-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 02, 2018) is 2118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NIST SP-800-63-3' is mentioned on line 309, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-14 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational M. Wiseman 5 Expires: January 3, 2019 GE Global Research 6 H. Tschofenig 7 ARM Ltd. 8 July 02, 2018 10 Reference Terminology for Remote Attestation Procedures 11 draft-birkholz-attestation-terminology-02 13 Abstract 15 This document is intended to illustrate and remediate the impedance 16 mismatch of terms related to remote attestation procedures used in 17 different domains today. New terms defined by this document provide 18 a consolidated basis to support future work on attestation procedures 19 in the IETF and beyond. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 57 2. Basic Roles of RATS . . . . . . . . . . . . . . . . . . . . . 4 58 3. Computing Context . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Formal Semantic Relationships . . . . . . . . . . . . . . 5 60 3.2. Characteristics of a Computing Context . . . . . . . . . 6 61 4. Computing Context Identity . . . . . . . . . . . . . . . . . 7 62 5. Attestation Workflow . . . . . . . . . . . . . . . . . . . . 7 63 6. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. The Lying Endpoint Problem . . . . . . . . . . . . . . . 10 65 6.2. Who am I a talking to? . . . . . . . . . . . . . . . . . 11 66 7. Trustworthiness . . . . . . . . . . . . . . . . . . . . . . . 11 67 8. Remote Attestation . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Building Block Terms . . . . . . . . . . . . . . . . . . 12 69 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 13.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 During its evolution, the term Remote Attestation has been used in 81 multiple contexts and multiple scopes and in consequence accumulated 82 various connotations with slightly different semantic meaning. 83 Correspondingly, Remote Attestation Procedures (RATS) are employed in 84 various usage scenarios and different environments. 86 In order to better understand and grasp the intend and meaning of 87 specific RATS in the scope of the security area - including the 88 requirements that are addressed by them - this document provides an 89 overview of existing work, its background, and common terminology. 90 As the contribution, from that state-of-the-art a set of terms that 91 provides a stable basis for future work on RATS in the IETF is 92 derived. 94 The primary application of RATS is to increase the trust and 95 confidence in the integrity of the object characteristics and 96 properties of a system entity that is intended to interact and 97 exchange data with other system entities remotely. How an objects's 98 characteristics are attested remotely and which characteristics are 99 actually chosen to be attested varies with the requirements of the 100 use cases, or -- in essence -- depends on the risk that is intended 101 to be mitigated via RATS. Effectively, RATS are a vital tool to be 102 used to increase the confidence in the level of trust of a system 103 that is supposed to be a trusted system. 105 In the remainder of this document a system that is capable to provide 106 an appropriate amount of information about its integrity is 107 considered to be a trustworthy system - or simply trustworthy. 109 The primary characteristics of a trustworthy system are commonly 110 based on information about the integrity of its intended composition, 111 its enrolled and subsequently installed software components, and the 112 scope of known valid states that a trustworthy system is supposed to 113 operate in. 115 It is important to note that the activity of attestation itself in 116 principle only provides the evidence that proves the integrity of a 117 (subset) of a system's object characteristics. The provided evidence 118 is used as a basis for further activities. Specific RATS define the 119 higher semantic context about how the evidence is utilized and what 120 RATS actually can accomplish; and what they cannot accomplish, 121 correspondingly. Hence, this document is also intended to provide a 122 map of terms, concepts and applications that illustrate the ecosystem 123 of current applications of RATS. 125 In essence, a prerequisite for providing an adequate set of terms and 126 definitions in the domain of RATS is a general understanding and a 127 common definitions of "what" RATS can accomplish "how" RATS can to be 128 used. 130 Please note that this document is still missing multiple reference 131 and is considered "under construction". The majority of definitions 132 is still only originating from IETF work. Future iterations will 133 pull in more complementary definitions from other SDO (e.g. Global 134 Platform, TCG, etc.) and a general structure template to highlight 135 semantic relationships and capable of resolving potential 136 discrepancies will be introduced. A section of context awareness 137 will provide further insight on how attestation procedures are vital 138 to ongoing work in the IETF (e.g. I2NSF & tokbind). The definitions 139 in the section about RATS are still self-describing in this version. 140 Additional explanatory text will be added to provide more context and 141 coherence. 143 1.1. Requirements notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in RFC 148 2119, BCP 14 [RFC2119]. 150 2. Basic Roles of RATS 152 The use of the term Remote Attestation Procedures always implies the 153 involvement of at least two parties that each take on a specific role 154 in corresponding RATS - the Attestor role and the Verifier role. 155 Depending on the object characteristics attested and the nature of 156 the parties, information is exchanged via specific types of 157 Interconnects between them. The type of interconnect ranges from GIO 158 pins, to a bus component, to the Internet, or from a direct physical 159 connection, to a wireless association, to a world wide mesh of peers. 160 In other words, virtually every kind communication path 161 (Interconnect) can be used by system entities that take on the role 162 of Attestor and Verifier (in fact, a single party can take on both 163 roles at the same time, but there is only a limited use to this 164 architecture). 166 Attestor: The role that designates the subject of the remote 167 attestation. A system entity that is the provider of evidence 168 takes on the role of an Attestor. 170 Verifier: The role that designates the system entity that is the 171 appraiser of the evidence provided by the Attestor. A system 172 entity that is the consumer of evidence takes on the role of a 173 Verifier. 175 Interconnect: A channel of communication between Attestor and 176 Verifier that enables the appraisal of evidence created by the 177 Attestor by a remote Verifier. 179 3. Computing Context 181 This section introduces the term Computing Context in order to 182 simplify the definition of RATS terminology. 184 The number of approaches and solutions to create things that provide 185 the same capabilities as a "simple physical device" continuously 186 increases. Examples include but are not limited to: the 187 compartmentalization of physical resources, the separation of 188 software instances with different dependencies in dedicated 189 containers, and the nesting of virtual components via hardware-based 190 and software-based solutions. 192 System entities are composed of system entities. In essence, every 193 physical or logical device is a composite of system entities. In 194 consequence, a composite device also constitutes a system entity. 195 Every component in that composite is a potential Computing Context 196 capable of taking on the roles of Attestor or Verifier. The scope 197 and application of these roles can range from: 199 o continuous mutual attestation procedures of every system entity 200 inside a composite device, to 202 o sporadic remote attestation of unknown parties via heterogeneous 203 Interconnects. 205 Analogously, the increasing number of features and functions that 206 constitute components of a device start to blur the lines that are 207 required to categorize each solution and approach precisely. To 208 address this increasingly challenging categorization, the term 209 Computing Context defines the characteristics of the system entities 210 that can take on the role of an Attestor and/or the role of a 211 Verifier. This approach is intended to provide a stable basis of 212 definitions for future solutions that continuous to remain viable 213 long-term. 215 Computing Context : An umbrella term that combines the scope of the 216 definitions of endpoint [ref NEA], device [ref 1ar], and thing 217 [ref t2trg], including hardware-based and software-based sub- 218 contexts that constitute independent, isolated and distinguishable 219 slices of a Computing Context created by compartmentalization 220 mechanisms, such as Trusted Execution Environments (TEE), Hardware 221 Security Modules (HSM) or Virtual Network Function (VNF) contexts. 223 3.1. Formal Semantic Relationships 225 The formal semantic relationship of a Computing Context and the 226 definitions provided by RFC 4949 is a as follows. 228 The scope of the term computing context encompasses 230 o an information system, 232 o an object and in consequence a system component or a composite of 233 system sub-components, and 235 o a system entity or a composite of system entities. 237 Analogously, a sub-context is a subsystem and as with system 238 components, computing contexts can be nested and therefore be 239 physical system components or logical ("virtual") system 240 (sub-)components. 242 The formal semantic relationship is based on the following 243 definitions from RFC 4949. 245 (Information) System: An organized assembly of computing and 246 communication resources and procedures - i.e., equipment and 247 services, together with their supporting infrastructure, 248 facilities, and personnel - that create, collect, record, process, 249 store, transport, retrieve, display, disseminate, control, or 250 dispose of information to accomplish a specified set of functions. 252 Object: A system component that contains or receives information. 254 Subsystem: A collection of related system components that together 255 perform a system function or deliver a system service. 257 System Component: A collection of system resources that (a) forms a 258 physical or logical part of the system, (b) has specified 259 functions and interfaces, and (c) is treated (e.g., by policies or 260 specifications) as existing independently of other parts of the 261 system. (See: subsystem.) 263 An identifiable and self-contained part of a Target of Evaluation. 265 System Entity: An active part of a system - [...] (see: subsystem) - 266 that has a specific set of capabilities. 268 3.2. Characteristics of a Computing Context 270 While the semantic relationships highlighted above constitute the 271 fundamental basis to provide a define Computing Context, the 272 following list of object characteristics is intended to improve the 273 application of the term and provide a better understanding of its 274 meaning: 276 A computing context: 278 o provides its own independent environment in regard to executing 279 and running software, 281 o provides its own isolated control plane state (by potentially 282 interacting with other Computing 284 o Contexts) and may provide a dedicated management interface by 285 which control plane behavior can be effected, 287 o can be identified uniquely and therefore reliably differentiated 288 in a given scope, and 290 o does not necessarily has to include a network interface with 291 associated network addresses (as required, e.g. by the definition 292 of an endpoint) - although it is very likely to have (access to) 293 one. 295 In contrast, a docker [ref docker, find a more general term here] 296 context is not a distinguishable isolated slice of an information 297 system and therefore is not an independent Computing Context. [more 298 feedback on this statement is required as the capabilities of docker- 299 like functions evolve continuously] 301 Examples include: a smart phone, a nested virtual machine, a 302 virtualized firewall function running distributed on a cluster of 303 physical and virtual nodes, or a trust-zone. 305 4. Computing Context Identity 307 The identity of a Computing Context provides the basis for creating 308 evidence about data origin authenticity. Confidence in the identity 309 assurance level [NIST SP-800-63-3] or the assurance levels for 310 identity authentication [RFC4949] impacts the confidence in the 311 evidence an Attestor provides. 313 5. Attestation Workflow 315 This section introduces terms and definitions that are required to 316 illustrate the scope and the granularity of RATS workflows in the 317 domain of security automation. Terms defined in the following 318 sections will be based on this workflow-related definitions. 320 In general, RATS are composed of iterative activities that can be 321 conducted in intervals. It is neither a generic set of actions nor 322 simply a task, because the actual actions to be conducted by RATS can 323 vary significantly depending on the protocols employed and types of 324 Computing Contexts involved. 326 Activity: A sequence of actions conducted by Computing Contexts that 327 compose a remote attestation procedure. The actual composition of 328 actions can vary, depending on the characteristics of the 329 Computing Context they are conducted by/in and the protocols used 330 to utilize an Interconnect. A single activity provides only a 331 minimal amount of semantic context, e.g.defined by the activity's 332 requirements imposed on the Computing Context, or via the set of 333 actions it is composed of. Example: The conveyance of 334 cryptographic evidence or the appraisal of evidence via imperative 335 guidance. 337 Task: "A piece of work to be done or undertaken." 339 In the scope of RATS, a task is a procedure to be conducted. 340 Example: A Verifier can be tasked with the appraisal of evidence 341 originating from a specific type of Computing Contexts providing 342 appropriate identities. 344 Action: "The accomplishment of a thing usually over a period of 345 time, in stages, or with the possibility of repetition." 347 In the scope of RATS, an action is the execution of an operation 348 or function in the scope of an activity conducted by a Computing 349 Context. A single action provides no semantic context by itself, 350 although it can limit potential semantic contexts of RATS to a 351 specific scope. Example: Signing an existing public key via a 352 specific openssl library, transmitting data, or receiving data are 353 actions. 355 Procedure: "A series of actions that are done in a certain way or 356 order." 358 In the scope of RATS, a procedure is a composition of activities 359 (sequences of actions) that is intended to create a well specified 360 result with a well established semantic context. Example: The 361 activities of attestation, conveyance and verification compose a 362 remote attestation procedure. 364 6. Reference Use Cases 366 This document provides NNN prominent examples of use cases 367 attestation procedures are intended to address: 369 o Verification of the source integrity of a computing context via 370 data integrity proofing of installed software instances that are 371 executed, and 373 o Verification of the identity proofing of a computing context. 375 These use case summary highlighted above is based in the following 376 terms defined in RFC4949 and complementary sources of terminology: 378 Assurance: An attribute of an information system that provides 379 grounds for having confidence that the system operates such that 380 the system's security policy is enforced [RFC4949] (see Trusted 381 System below). 383 In common criteria, assurance is the basis for the metric level of 384 assurance, which represents the "confidence that a system's 385 principal security features are reliably implemented". 387 The NIST Handbook [get ref from 4949] notes that the levels of 388 assurance defined in Common Criteria represent "a degree of 389 confidence, not a true measure of how secure the system actually 390 is. This distinction is necessary because it is extremely 391 difficult-and in many cases, virtually impossible-to know exactly 392 how secure a system is." 394 Historically, assurance was well-defined in the Orange Book 395 [http://csrc.nist.gov/publications/history/dod85.pdf] as 396 "guaranteeing or providing confidence that the security policy has 397 been implemented correctly and that the protection-relevant 398 elements of the system do, indeed, accurately mediate and enforce 399 the intent of that policy. By extension, assurance must include a 400 guarantee that the trusted portion of the system works only as 401 intended." 403 Confidence: The definition of correctness integrity in [RFC4949] 404 notes that "source integrity refers to confidence in data values". 405 Hence, confidence in an attestation procedure is referring to the 406 degree of trustworthiness of an attestation activity that produces 407 evidence (Attestor), of an conveyance activity that transfers 408 evidence (interconnect), and of a verification activity that 409 appraises evidence (Verifier), in respect to correctness 410 integrity. 412 Identity: Defined by [RFC4949] as the collective aspect of a set of 413 attribute values (i.e., a set of characteristics) by which a 414 system user or other system entity is recognizable or known. 415 (See: authenticate, registration. Compare: identifier.) 417 There are different scopes an identity can apply to: 419 Singular identity: An identity that is registered for an entity 420 that is one person or one process. 422 Shared identity: An identity that is registered for an entity that 423 is a set of singular entities in which each member is authorized 424 to assume the identity individually, and for which the registering 425 system maintains a record of the singular entities that comprise 426 the set. In this case, we would expect each member entity to be 427 registered with a singular identity before becoming associated 428 with the shared identity. 430 Group identity: An identity that is registered for an entity that 431 is a set of entities (2) for which the registering system does not 432 maintain a record of singular entities that comprise the set. 434 Identity Proofing: A process that vets and verifies the information 435 that is used to establish the identity of a system entity. 437 Source Integrity: The property that data is trustworthy (i.e., 438 worthy of reliance or trust), based on the trustworthiness of its 439 sources and the trustworthiness of any procedures used for 440 handling data in the system. 442 Data Integrity: (a) The property that data has not been changed, 443 destroyed, or lost in an unauthorized or accidental manner. (See: 444 data integrity service. Compare: correctness integrity, source 445 integrity.) 447 (b) The property that information has not been modified or 448 destroyed in an unauthorized manner. 450 Correctness: The property of a system that is guaranteed as the 451 result of formal verification activities. 453 Correctness integrity: The property that the information represented 454 by data is accurate and consistent. 456 Verification: (a) The process of examining information to establish 457 the truth of a claimed fact or value. 459 (b) The process of comparing two levels of system specification 460 for proper correspondence, such as comparing a security model with 461 a top-level specification, a top-level specification with source 462 code, or source code with object code. 464 Forward Authenticity (FA): A property of secure communication 465 protocols, in which later compromise of the long-term keys of a 466 data origin does not compromise past authentication of data from 467 that origin. FA is achieved by timely recording of assessments of 468 the authenticity from entities (via "audit logs" during "audit 469 sessions") that are authorized for this purpose, in a time frame 470 much shorter than that expected for the compromise of the long- 471 term keys. 473 6.1. The Lying Endpoint Problem 475 A very prominent goal of attestation procedures - and therefore a 476 suitable example used as reference in this document - is to address 477 the "lying endpoint problem". 479 Information created, relayed, or, in essence, emitted by a computing 480 context does not have to be correct. There can be multiple reasons 481 why that is the case and the "lying endpoint problem" represents a 482 scenario, in which the reason is the compromization of computing 483 contexts with malicious intend. A compromised computing context 484 could try to "pretend" to be integer, while actually feeding 485 manipulated information into a security domain, therefore 486 compromising the effectiveness of automated security functions. 487 Attestation - and remote attestation procedures specifically - is an 488 approach intended to identify compromised software instances in 489 computing contexts. 491 Per definition, a "lying endpoint" cannot be "trusted system". 493 Trusted System: A system that operates as expected, according to 494 design and policy, doing what is required - despite environmental 495 disruption, human user and operator errors, and attacks by hostile 496 parties - and not doing other things. 498 Remote attestation procedures are intended to enable the consumer of 499 information emitted by an computing context to assess the validity 500 and integrity of the information transferred. The approach is based 501 on the assumption that if evidence can be provided in order to prove 502 the integrity of every software instance installed involved in the 503 activity of creating the emitted information in question, the emitted 504 information can be considered valid and integer. 506 In contrast, such evidence has to be impossible to create if the 507 software instances used in a computing context are compromised. 508 Attestation activities that are intended to create this evidence 509 therefore also to also provide guarantees about the validity of the 510 evidence they can create. 512 6.2. Who am I a talking to? 514 [working title, write up use case here, ref teep requirements] 516 7. Trustworthiness 518 A "lying endpoint" is not trustworthy. 520 Trusted System: A system that operates as expected, according to 521 design and policy, doing what is required - despite environmental 522 disruption, human user and operator errors, and attacks by hostile 523 parties - and not doing other things. 525 Trustworthy: pull in text here 527 8. Remote Attestation 529 Attestation: An object integrity authentication facilitated via the 530 creation of a claim about the properties of an Attestor, such that 531 the claim can be used as evidence. 533 Conveyance: The transfer of evidence from the Attestor to the 534 Verifier. 536 Verification: The appraisal of evidence by evaluating it against 537 declarative guidance. 539 Remote Attestation: A procedure composed of the activities 540 attestation, conveyance and verification. 542 8.1. Building Block Terms 544 [working title, pulled from various sources, vital] 546 Attestation Identity Key (AIK): A special purpose signature 547 (therefore asymmetric) key that supports identity related 548 operations. The private portion of the key pair is maintained 549 confidential to the computing context via appropriate measures 550 (that have a direct impact on the level of confidence). The 551 public portion of the key pair may be included in AIK credentials 552 that provide a claim about the computing context. 554 Claim: A piece of information asserted about a subject. A claim is 555 represented as a name/value pair consisting of a Claim Name and a 556 Claim Value [RFC7519] 558 In the context of SACM, a claim is also specialized as an 559 attribute/value pair that is intended to be related to a statement 560 [I-D.ietf-sacm-terminology]. 562 Computing Context Characteristics: The composition, configuration 563 and state of a computing context. 565 Evidence: A trustworthy set of claims about an computing context's 566 characteristics. 568 Identity: A set of claims that is intended to be related to an 569 entity. [merge with RFC4949 defintion above] 571 Integrity Measurements: Metrics of computing context characteristics 572 (i.e. composition, configuration and state) that affect the 573 confidence in the trustworthiness of a computing context. Digests 574 of integrity measurements can be stored in shielded locations 575 (e.g. a PCR of a TPM). 577 Reference Integrity Measurements: Signed measurements about a 578 computing context's characteristics that are provided by a vendor 579 or manufacturer and are intended to be used as declarative 580 guidannce [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID). 582 Trustworthiness: The qualities of computing context characteristics 583 that guarantee a specific behavior specified by declarative 584 guidance. Trustworthiness is not an absolute property but defined 585 with respect to a computing context, corresponding declarative 586 guidance, and has a scope of confidence. A trusted system is 587 trustworthy. [refactor defintion with RFC4949 terms] 589 Trustworthy Computing Context: a computing context that guarantees 590 trustworthy behavior and/or composition (with respect to certain 591 declarative guidance and a scope of confideence). A trustworthy 592 computing context is a trusted system. 594 Trustworthy Statement: evidence that trustworthy conveyed by a 595 computing context that is not necessarily trustworthy. [update 596 with tamper related terms] 598 9. IANA considerations 600 This document will include requests to IANA: 602 o first item 604 o second item 606 10. Security Considerations 608 There are always some. 610 11. Acknowledgements 612 Maybe. 614 12. Change Log 616 No changes yet. 618 13. References 620 13.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 628 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 629 . 631 13.2. Informative References 633 [I-D.ietf-sacm-terminology] 634 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 635 A. Montville, "Security Automation and Continuous 636 Monitoring (SACM) Terminology", draft-ietf-sacm- 637 terminology-14 (work in progress), December 2017. 639 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 640 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 641 . 643 Authors' Addresses 645 Henk Birkholz 646 Fraunhofer SIT 647 Rheinstrasse 75 648 Darmstadt 64295 649 Germany 651 Email: henk.birkholz@sit.fraunhofer.de 653 Monty Wiseman 654 GE Global Research 655 USA 657 Email: monty.wiseman@ge.com 658 Hannes Tschofenig 659 ARM Ltd. 660 110 Fulbourn Rd 661 Cambridge CB1 9NJ 662 UK 664 Email: hannes.tschofenig@gmx.net