idnits 2.17.1 draft-voit-rats-trustworthy-path-routing-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 448 has weird spacing: '...sh-algo ide...' == Line 524 has weird spacing: '...sh-algo ide...' == Line 541 has weird spacing: '...gnature bin...' -- The document date (September 07, 2021) is 961 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 (-22) exists of draft-ietf-rats-architecture-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'RATS-Arch') ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group E. Voit 3 Internet-Draft C. Gaddam 4 Intended status: Standards Track Cisco 5 Expires: March 11, 2022 G. Fedorkow 6 Juniper 7 H. Birkholz 8 Fraunhofer SIT 9 September 07, 2021 11 Trusted Path Routing 12 draft-voit-rats-trustworthy-path-routing-04 14 Abstract 16 There are end-users who believe encryption technologies like IPSec 17 alone are insufficient to protect the confidentiality of their highly 18 sensitive traffic flows. These end-users want their flows to 19 traverse devices which have been freshly appraised and verified for 20 trustworthiness. This specification describes Trusted Path Routing. 21 Trusted Path Routing protects sensitive flows as they transit a 22 network by forwarding traffic to/from sensitive subnets across 23 network devices recently appraised as trustworthy. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 11, 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 63 3. Implementation Prerequisites . . . . . . . . . . . . . . . . 4 64 4. End-to-end Solution . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Network Topology Assembly . . . . . . . . . . . . . . . . 5 66 4.2. Attestation Information Flows . . . . . . . . . . . . . . 6 67 4.2.1. Step 1 . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2.2. Step 2 . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.3. Step 3 . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.2.4. Step 4 . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2.5. Step 5 . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.2.6. Step 6 . . . . . . . . . . . . . . . . . . . . . . . 16 73 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 27 77 7.2. Informative References . . . . . . . . . . . . . . . . . 28 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 79 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 29 80 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 30 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 83 1. Introduction 85 There are end-users who believe encryption technologies like IPSec 86 alone are insufficient to protect the confidentiality of their highly 87 sensitive traffic flows. These customers want their highly sensitive 88 flows to be transported over only network devices recently verified 89 as trustworthy. 91 By using a router's embedded TPM based cryptoprocessors in 92 conjunction with the Remote Attestation context established by 93 [attestation-results], a network provider can identify potentially 94 compromised devices as well as potentially exploitable (or even 95 exploited) vulnerabilities. Using this knowledge, it is then 96 possible to redirect sensitive flows around these devices while other 97 remediations are potentially considered by Network Operations. 99 Trusted Path Routing allows the establishing Trusted Topologies which 100 only include trust-verified network devices. Membership in a Trusted 101 Topology is established and maintained via an exchange of Stamped 102 Passports at the link layer between peering network devices. As 103 links to Attesting Devices are appraised as meeting at least a 104 minimum set of formally defined Trustworthiness Claims, the links are 105 then included as members of this Trusted Topology. Routing protocols 106 are then used to propagate topology state throughout a network. 108 IP Packets to and from end-user designated Sensitive Subnets are then 109 forwarded into this Trusted Topology at each network boundary. This 110 is done by an end user identifying sensitive IP subnets where flows 111 with applications using these IP subnets need enhanced privacy 112 guarantees. Trusted Path Routing passes flows to/from these 113 Sensitive Subnets over a Trusted Topology able to meet these 114 guarantees. The Trusted Topology itself consists of the 115 interconnection of network devices where each potentially transited 116 device has been verified as achieving a specific set of 117 Trustworthiness Claims during its most recent trustworthiness 118 appraisal. Interesting sets of Trustworthiness Claims might be 119 marketed to end-users in the following ways: 121 o all transited devices have booted with known hardware and firmware 123 o all transited devices are from a specific set of vendors and are 124 running known software containing the latest patches 126 o no guarantees provided 128 2. Terminology 130 2.1. Terms 132 The following terms are imported from [RATS-Arch]: Attester, 133 Evidence, Passport, Relying Party, and Verifier. 135 The following terms are impored from [attestation-results]: 136 Trustworthiness Claim, Trustworthiness Vector, AR-augmented Evidence 138 Newly defined terms for this document: 140 Attested Device - a network connected Attester where a Verifier's 141 most recent appraisal of Evidence has returned a Trustworthiness 142 Vector. 144 Stamped Passport - AR-augmented Evidence which can take two forms. 145 First if the Attester uses a TPM2, the the Verifier Proof-of- 146 Freshness includes the , , 147 and objects from a recent TPM2 quote made by that Attester, 148 and the Relying Party Proof-of-Freshness is returned along with 149 the timeticks as objects embedded within the most recent TPM quote 150 signed by the same TPM2. Second, if the Attester uses a TPM1.2: 151 the Verifier Proof-of-Freshness includes a global timestamp from 152 that Verifier, and the Relying Party Proof-of-Freshness is 153 embedded within a more recent TPM quote signed by the same TPM 154 Attesting Environment. 156 Sensitive Subnet - an IP address range where IP packets to or from 157 that range desire confidentially guarantees beyond those of non- 158 identified subnets. In practice, flows to or from a Sensitive 159 Subnet must only have their IP headers and encapsulated payloads 160 accessible/visible only by Attested Devices supporting one or more 161 Trustworthiness Vectors. 163 Transparently-Transited Device - a network device within an network 164 domain where any packets originally passed into that network 165 domain are completely opaque on that network device at Layer 3 and 166 above. 168 Trusted Topology - a topology which includes only Attested Devices 169 and Transparently-Transited Devices. 171 2.2. Requirements Notation 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in 176 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 3. Implementation Prerequisites 181 The specification is a valid instance of [attestation-results]. This 182 specification works under the following protocol and preconfiguration 183 prerequisite assumptions: 185 o All Attested Devices support the TPM remote attestation profile as 186 laid out in [RATS-Device], and include either [TPM2.0] or 187 [TPM1.2]. 189 o One or more Verifier A's as defined in [attestation-results] 190 'Interaction Model' continuously appraise each of the Attested 191 Devices in a network domain, and these Verifiers return the 192 Attestation Results back to each originating Attested Device. 194 o The Attested Devices are connected via link layer protocols such 195 as [MACSEC] or [IEEE-802.1X]. 197 o Each Attester can pass a Stamped Passport to a Relying Party / 198 Verifier B as defined in [attestation-results] 'Interaction Model' 199 within [RFC3748] over that link layer protocol. 201 o A Trusted Topology such as [I-D.ietf-lsr-flex-algo] exists in an 202 IGP domain for the forwarding of Sensitive Subnet traffic. This 203 Topology will carry traffic across a set of Attested Devices which 204 currently meet at a defined set of Trustworthiness Vectors. 206 o A Relying Party is able to use mechanisms such as 207 [I-D.ietf-lsr-flex-algo]'s affinity to include/exclude links as 208 part of the Trusted Topology based on the appraisal of a Stamped 209 Passport. 211 o Customer designated Sensitive Subnets and their requested 212 Trustworthiness Vectors have been identified and associated with 213 external interfaces to/from Attested Devices at the edge of a 214 network. Traffic to a Sensitive Subnet can be passed into the 215 Trusted Topology by the Attested Device. 217 o Relying Party/Verifier B trusts information signed by Verifier A. 218 Verifier B has also been pre-provisioned with certificates or 219 public keys necessary to confirm that Stamped Passports came from 220 Verifier A. 222 4. End-to-end Solution 224 4.1. Network Topology Assembly 226 To be included in a Trusted Topology, Stamped Passports are shared 227 between Attested Devices (such as routers). Upon receiving and 228 appraising the Stamped Passport as part of link layer authentication, 229 the Relying Party Attested Device decides if this link should be 230 added as an active adjacency for a particular Trusted Topology. In 231 Figure 1 below, this might be done by applying an Appraisal Policy 232 for Attestation Results which requires any Attesting Device be most 233 recently appraised with the Trustworthiness Claim 'hw-authentic'. If 234 Attested Device 'x' has been appraised with 'hw-verification-fail' is 235 would not become part of the Trustworthy Topology. 237 When enough links have been successfully added, the Trusted Topology 238 will support edge-to-edge forwarding as routing protocols flood the 239 adjacency information across the network domain. 241 .------------. .----------. 242 | Attested | | Edge | 243 .----------. | Device 'x' | | Attested | 244 | Attested | | | | Device | 245 | Device | | | | | 246 | | | trust>-----------------====================| | 309 | time(RG) | 310 |<------Attestation Results-(2) | 311 ~ ~ ~ 312 time(VG')? | | 313 ~ ~ ~ 314 |<------nonce---------------------------------(3)time(NS') 315 | | | 316 time(EG')(4)------Stamped Passport---------------------->| 317 | | time(RG',RA')(5) 318 (6) 319 ~ 320 time(RX') 322 Figure 2: Trusted Path Timing 324 To summarize Figure 2 above, Evidence about a specific Attester is 325 generated. Some subset of this evidence will be in the form of PCR 326 quotes which are signed by a TPM that exists as the Attester's 327 Attesting Environment. This Evidence will be delibered to and 328 appraised by Verifier A. Verifier A will then appraise the Attester 329 and give it a Trustworthiness Vector. This Trustworthiness Vector is 330 then signed by Verifier A and be returned as Attestation Results to 331 the Attester. Later, when a request comes in from a Relying Party, 332 the Attester assembles and returns a Stamped Passport. The Stamped 333 Passport contains all the information necessary for Verifier B to 334 appraise the most recent Trustworthiness Vector of the Attester. 335 Based on the Verifier B appraisal, the link will be included or not 336 in a Trusted Topology maintained on the Relying Party. 338 More details on the mechanisms used in the construction, 339 verification, and transmitting of the Stamped Passport are listed 340 below. These numbers match to both the numbered steps of Figure 2 341 and numbered steps described in Section 3 of [attestation-results]: 343 4.2.1. Step 1 345 Evidence about and Attester is generated. A portion of this Evidence 346 will include a PCR quote signed by a TPM private LDevID key that 347 exists within the Attester's TPM based Attesting Environment. The 348 Attester sends a signed TPM Quote which includes PCR measurements to 349 Verifier A at time(EG). 351 There are two alternatives for Verifier A to acquire this signed 352 Evidence: 354 o Subscription to the stream defined in 355 [stream-subscription]. Note: this method is recommended as it 356 will minimize the interval between when a PCR change is made in a 357 TPM, and when the PCR change appraisal is incorporated within a 358 subsequent Stamped Passport. 360 o Periodic polling of RPC or 361 the RPC which are defined 362 in [RATS-YANG]. 364 4.2.2. Step 2 366 Verifier A appraises the Evidence from Step 1. A portion of this 367 appraisal process will follow the appraisal process flow described 368 below. This appraisal process MUST be able to set at least the 369 following set of Trustworthiness Claims from [attestation-results]: 370 'hardware', 'instance-identity', and 'executables'. The 371 establishment of a Trustworthiness Vector uses the following Figure 3 372 logic on the Verifier: 374 Start: TPM Quote Received, log received, or appraisal timer expired 375 for the the Attesting network device. 377 Appraisal 0: set Trustworthiness Vector = Null 379 Appraisal 1: Is there sufficient fresh signed evidence to appraise? 380 (yes) - No Action 381 (no) - Goto End 383 Appraisal 2: Appraise Hardware Integrity PCRs 384 if (hardware NOT "0") - push onto vector 385 if (hardware NOT affirming or warning), go to End 387 Appraisal 3: Appraise Attesting Environment identity 388 if (instance-identity <> "0") - push onto vector 390 Appraisal 4: Appraise executable loaded and filesystem integrity 391 if (executables NOT "0") - push onto vector 392 if (executables NOT affirming or warning), go to End 394 Appraisal 5: Appraise all remaining Trustworthiness Claims 395 Independently and set as appropriate. 397 End 399 Figure 3: Verifier A Appraisal Flow 401 After the appraisal and generation of the Trustworthiness Vector, the 402 following are assembled as the set of Attestation Results from this 403 particular appraisal cycle: 405 (2.1) the Public Attestation Key which was used to validate the TPM 406 Quote of Step 1. This is encoded by , , and . 409 (2.2) the appraised Trustworthiness Vector of the Attester as 410 calculated in Figure 3 412 (2.3) the PCR state information from the TPM Quote of (1) plus the 413 time information associated with the TPM Quote of (1). Specifically 414 if the Attester has a TPM2, then the values of the TPM PCRs are 415 included (i.e., , , and ), 416 as are the timing counters from the TPM (i.e., , , , and ). Likewise if the Attester 418 has a TPM1.2, the TPM PCR values of the and 419 are included. Timing information comes from the Verifier itself via 420 the object. 422 (2.4) a Verifier A signature across (2.1) though (2.3). This 423 signature is encoded by , , and . 426 Immediately subsequent to each Verifier appraisal cycle of an 427 Attester, these Attestation Results MUST be pushed to the Attesting 428 Router. This is done via a daatstore write to the following YANG 429 model on the Attester. A YANG tree showing the relevant YANG objects 430 is below. The YANG model describing each of these objects is 431 described later in the document. Note however that although the YANG 432 model shows the specific objects which are needed, the specific set 433 of objects needs to be encoded in CDDL. This makes the payload going 434 over TLS more efficient. Look for this encoding in a new version of 435 the draft which is coming shortly. 437 module: ietf-trustworthiness-claims 438 +--rw attestation-results! 439 +--rw (tpm-specification-version)? 440 +--:(tpm20-attestation-results-cddl) {taa:tpm20}? 441 | +--rw tpm20-attestation-results-cddl 442 | +--rw trustworthiness-vector 443 | | +--rw hardware? hardware 444 | | +--rw instance-identity? instance-identity 445 | | +--rw executables? executables 446 | | +--rw configuration? configuration 447 | +--rw tpm20-pcr-selection* [tpm20-hash-algo] 448 | | +--rw tpm20-hash-algo identityref 449 | | +--rw pcr-index* tpm:pcr 450 | +--rw TPM2B_DIGEST binary 451 | +--rw clock uint64 452 | +--rw reset-counter uint32 453 | +--rw restart-counter uint32 454 | +--rw safe boolean 455 | +--rw attester-certificate-name 456 | | tpm:certificate-name-ref 457 | +--rw appraisal-timestamp 458 | | yang:date-and-time 459 | +--rw verifier-algorithm-type identityref 460 | +--rw verifier-signature binary 461 | +--rw verifier-certificate-keystore-ref 462 | tpm:certificate-name-ref 463 +--:(tpm12-attestation-results-cddl) {taa:tpm12}? 464 +--rw tpm12-attestation-results-cddl 465 +--rw trustworthiness-vector 466 | +--rw hardware? hardware 467 | +--rw instance-identity? instance-identity 468 | +--rw executables? executables 469 | +--rw configuration? configuration 470 +--rw pcr-index* pcr 471 +--rw tpm12-pcr-value* binary 472 +--rw tpm12-hash-algo identityref 473 +--rw TPM12-quote-timestamp 474 | yang:date-and-time 475 +--rw attester-certificate-name 476 | tpm:certificate-name-ref 477 +--rw appraisal-timestamp 478 | yang:date-and-time 479 +--rw verifier-algorithm-type identityref 480 +--rw verifier-signature binary 481 +--rw verifier-certificate-keystore-ref 482 tpm:certificate-name-ref 484 Figure 4: Attestation Results Tree 486 4.2.3. Step 3 488 At time(NS') some form of time-based freshness (such as a nonce or 489 Epoch Handle [RATS-Interactions]) will be generated in a way which 490 makes it available to the Relying Party. Soon after time(NS'), a 491 Relying Party will make a Link Layer authentication request to an 492 Attester via a either [MACSEC] or [IEEE-802.1X]. This connection 493 request MUST expect the return of [RFC3748] credentials from the 494 Attester. 496 4.2.4. Step 4 498 Upon receipt of the Link Layer request from Step 3, a Stamped 499 Passport is generated and sent to the Relying Party. The Stamped 500 Passport MUST include the following: 502 (4.1) The Attestation Results from Step 2 504 (4.2) New signed, verifiably fresh PCR measurements based on a TPM 505 quote at time(EG') which incorporates the freshness information known 506 by the Relying Party from Step 3. If it is a nonce, the freshness 507 information will have been delivered as part of the link layer 508 connection request in Steps 3. 510 Stamped Passports contain following objects, defined in this document 511 via YANG. A subsequent draft will convert the objects below into 512 CDDL format so that the objects can efficiently be passed over EAP. 514 If an Attester includes a TPM2, these YANG objects are: 516 +---n tpm20-stamped-passport 517 +--ro attestation-results 518 | +--ro trustworthiness-vector 519 | | +--ro hardware? hardware 520 | | +--ro instance-identity? instance-identity 521 | | +--ro executables? executables 522 | | +--ro configuration? configuration 523 | +--ro tpm20-pcr-selection* [tpm20-hash-algo] 524 | | +--ro tpm20-hash-algo identityref 525 | | +--ro pcr-index* tpm:pcr 526 | +--ro TPM2B_DIGEST binary 527 | +--ro clock uint64 528 | +--ro reset-counter uint32 529 | +--ro restart-counter uint32 530 | +--ro safe boolean 531 | +--ro attester-certificate-name 532 | | tpm:certificate-name-ref 533 | +--ro appraisal-timestamp 534 | | yang:date-and-time 535 | +--ro verifier-algorithm-type identityref 536 | +--ro verifier-signature binary 537 | +--ro verifier-certificate-keystore-ref 538 | tpm:certificate-name-ref 539 +--ro tpm20-quote 540 +--ro TPMS_QUOTE_INFO binary 541 +--ro quote-signature binary 543 Figure 5: YANG Tree for a TPM2 Stamped Passport 545 Note that where a TPM2.0 is used, the PCR numbers and hash algorithms 546 quoted in Step 1 MUST match the PCR numbers and hash algorithms 547 quoted in this step. 549 And if the Attester is a TPM1.2, the YANG object are: 551 +---n tpm12-stamped-passport 552 +--ro attestation-results 553 | +--ro trustworthiness-vector 554 | | +--ro hardware? hardware 555 | | +--ro instance-identity? instance-identity 556 | | +--ro executables? executables 557 | | +--ro configuration? configuration 558 | +--ro pcr-index* pcr 559 | +--ro tpm12-pcr-value* binary 560 | +--ro tpm12-hash-algo identityref 561 | +--ro TPM12-quote-timestamp 562 | | yang:date-and-time 563 | +--ro attester-certificate-name 564 | | tpm:certificate-name-ref 565 | +--ro appraisal-timestamp 566 | | yang:date-and-time 567 | +--ro verifier-algorithm-type identityref 568 | +--ro verifier-signature binary 569 | +--ro verifier-certificate-keystore-ref 570 | tpm:certificate-name-ref 571 +--ro tpm12-quote 572 +--ro TPM_QUOTE2? binary 574 Figure 6: YANG Tree for a TPM1.2 Stamped Passport 576 With either of these passport formats, if the TPM quote is verifiably 577 fresh, then the state of the Attester can be appraised by a network 578 peer. 580 Note that with [MACSEC] or [IEEE-802.1X], Step 3 plus Step 4 will 581 repeat periodically independently of any subsequent iteration Steps 1 582 and Step 2. This allows for periodic reauthentication of the link 583 layer in a way not bound to the updating of Verifier A's Attestation 584 Results. 586 4.2.5. Step 5 588 Upon receipt of the Stamped Passport generated in Step 4, the Relying 589 Party appraises this Stamped Passport as per its Appraisal Policy for 590 Attestation Results. The result of this application will determine 591 how the Stamped Passport will impact adjacencies within a Trusted 592 Topology. The decision process is as follows: 594 (5.1) Verify that (4.2) includes the freshness context from Step 3. 596 (5.2) Use a local certificate to validate the signature (4.1). 598 (5.3) Verify that the hash from (4.2) matches (4.1) 599 (5.4) Use the identity of (2.1) to validate the signature of (4.2). 601 (5.5) Failure of any steps (5.1) through (5.4) means the link does 602 not meet minimum validation criteria, therefore appraise the link as 603 having a null Verifier B Trustworthiness Vector. Jump to Step 6. 605 (5.6) Compare the time(EG) TPM state to the time(EG') TPM state 607 o If TPM2.0 609 1. If the , , and 610 are equal between the Attestation Results and the TPM 611 Quote at time(EG') then Relying Party can accept (2.1) as the 612 link's Trustworthiness Vector. Jump to Step 6. 614 2. If the , and are equal 615 between the Attestation Results and the TPM Quote at 616 time(EG'), and the object from time(EG') has not 617 incremented by an unacceptable number of seconds since the 618 Attestation Result, then Relying Party can accept (2.1) as the 619 link's Trustworthiness Vector. Jump to Step 6.) 621 3. Assign the link a null Trustworthiness Vector. 623 o If TPM1.2 625 1. If the 's and 's are equal between 626 the Attestation Results and the TPM Quote at time(EG'), then 627 Relying Party can accept (2.1) as the link's Trustworthiness 628 Vector. Jump to step (6). 630 2. If the time hasn't incremented an unacceptable number of 631 seconds from the Attestation Results and the 632 system clock of the Relying Party, then Relying Party can 633 accept (2.1) as the link's Trustworthiness Vector. Jump to 634 step 6.) 636 3. Assign the link a null Trustworthiness Vector. 638 (5.7) Assemble the Verifier B Trustworthiness Vector 640 1. Copy Verifier A Trustworthiness Vector to Verifier B 641 Trustworthiness Vector 643 2. Prune any Trustworthiness Claims the Relying Party doesn't accept 644 from this Verifier. 646 4.2.6. Step 6 648 After the Trustworthiness Vector has been validated or reset, based 649 on the link's Trustworthiness Vector, the Relying Party adjusts the 650 link affinity of the corresponding ISIS [I-D.ietf-lsr-flex-algo] 651 topology. ISIS will then replicate the link state across the IGP 652 domain. Traffic will then avoid links which do not have a qualifying 653 Trustworthiness Vector. 655 5. YANG Module 657 This YANG module imports modules from [RATS-YANG], [crypto-types] and 658 [RFC6021]. 660 ietf-trustworthiness-claims@2021-09-03.yang 661 module ietf-trustworthiness-claims { 662 yang-version 1.1; 663 namespace 664 "urn:ietf:params:xml:ns:yang:ietf-trustworthiness-claims"; 665 prefix tc; 667 import ietf-yang-types { 668 prefix yang; 669 } 670 import ietf-tcg-algs { 671 prefix taa; 672 reference 673 "draft-ietf-rats-yang-tpm-charra"; 674 } 675 import ietf-tpm-remote-attestation { 676 prefix tpm; 677 reference 678 "draft-ietf-rats-yang-tpm-charra"; 679 } 681 organization "IETF"; 682 contact 683 "WG Web: 684 WG List: 686 Editor: Eric Voit 687 "; 689 description 690 "This module contains conceptual YANG specifications for 691 subscribing to attestation streams being generated from TPM chips. 693 Copyright (c) 2020 IETF Trust and the persons identified as 694 authors of the code. All rights reserved. 696 Redistribution and use in source and binary forms, with or without 697 modification, is permitted pursuant to, and subject to the license 698 terms contained in, the Simplified BSD License set forth in 699 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 700 Documents (https://trustee.ietf.org/license-info). 702 This version of this YANG module is part of RFC XXXX; see the RFC 703 itself for full legal notices."; 705 revision 2021-09-03 { 706 description 707 "Initial version."; 708 reference 709 "draft-voit-rats-trustworthy-path-routing"; 710 } 712 /* 713 * TYPEDEF 714 */ 716 typedef trustworthiness-claim { 717 type int8; 718 description 719 "A Verifier asserted value designed to enable a common 720 understanding of a Verifier trustworthiness appraisal. The 721 value assignments for this 8 bit signed integer will follow 722 these guidelines: 724 Affirming: The Verifier affirms the Attester support for this 725 aspect of trustworthiness 726 - Values 1 to 31: A standards enumerated reason for affirming. 727 - Values -2 to -32: A non-standard reason for affirming. 729 Warning: The Verifier warns about this aspect of trustworthiness. 730 - Values 32 to 63: A standards enumerated reason for the 731 warning. 732 - Values -33 to -64: A non-standard reason for the warning. 734 Contraindicated: The Verifier asserts the Attester is explicitly 735 untrustworthy in regard to this aspect. 736 - Values 64 to 127: A standards enumerated reason for the 737 contraindication. 738 - Values -65 to -128: A non-standard reason for the 739 contraindication. 741 None: The Verifier makes no assertions about this Trustworthiness 742 Claim. The following values are reserved with the following 743 meanings across all instances of trustworthiness-claim. 744 - Value 0: Note: this should always be always treated 745 equivalently by the Relying Party as no claim being made. 746 I.e., the RP's Appraisal Policy for Attestation Results 747 SHOULD NOT make any distinction between a Trustworthiness 748 Claim with enumeration '0', and no Trustworthiness Claim 749 being provided. 750 - Value -1: An unexpected error occurred during the Verifier's 751 appraisal processing. Note: while no claim is being made, the 752 Relying Party MAY make a distinction between a 753 Trustworthiness Claim with enumeration '-1', and no 754 Trustworthiness Claim being provided."; 755 } 757 typedef hardware { 758 type trustworthiness-claim; 759 description 760 "A Verifier has appraised any Attester hardware and firmware 761 which are able to expose fingerprints of their identity and 762 running code. 764 The following are specific reserved values of hardware and 765 the meanings of these reserved values: 767 0: No assertion 769 1: An Attester has passed its hardware and/or firmware 770 verifications needed to demonstrate that these are 771 genuine/supported. 773 32:An Attester contains only genuine/supported hardware and/or 774 firmware, but there are known security vulnerabilities. 776 64:Attester hardware and/or firmware is recognized, but its 777 trustworthiness is contraindicated. 779 65:A Verifier does not recognize an Attester's hardware or 780 firmware, but it should be recognized. 782 -1:Unexpected error."; 783 } 785 typedef instance-identity { 786 type trustworthiness-claim; 787 description 788 "A Verifier has appraised an Attesting Environment's unique 789 identity based upon private key signed Evidence which can be 790 correlated to a unique instantiated instance of the Attester. 791 (Note: this Trustworthiness Claim should only be generated if 792 the Verifier actually expects to recognize the unique identity 793 of the Attester.) 795 The following are specific reserved values of instance-identity 796 and the meanings of these reserved values: 798 0: No assertion 800 1: The Attesting Environment is recognized, and the associated 801 instance of the Attester is not known to be compromised. 803 64:The Attesting Environment is recognized, and but its unique 804 private key indicates a device which is not trustworthy. 806 65:The Attesting Environment is not recognized; however the 807 Verifier believes it should be. 809 -1:Unexpected error."; 810 } 812 typedef executables { 813 type trustworthiness-claim; 814 description 815 "A Verifier has appraised and evaluated relevant runtime files, 816 scripts, and/or other objects which have been loaded into the 817 Target environment's memory. 819 The following are specific reserved values of executables and 820 the meanings of these reserved values: 822 0: No assertion 824 1: Only a recognized genuine set of approved executables, 825 scripts, files, and/or objects have been loaded during 826 and after the boot process. 828 2: Only a recognized genuine set of approved executables have 829 been loaded during the boot process. 831 32:Only a recognized genuine set of executables, scripts, files, 832 and/or objects have been loaded. However the Verifier cannot 833 vouch for a subset of these due to known bugs or other known 834 vulnerabilities. 836 33:Runtime memory includes executables, scripts, files, and/or 837 objects which are not recognized. 839 64:Runtime memory includes executables, scripts, files, and/or 840 object which are contraindicated. 842 -1:Unexpected error."; 843 } 845 typedef configuration { 846 type trustworthiness-claim; 847 description 848 "A Verifier has appraised an Attester's configuration, and is 849 able to make conclusions regarding the exposure of known 850 vulnerabilities. 852 The following are specific reserved values of configuration and 853 the meanings of these reserved values: 855 0: No assertion 857 1: The configuration is a known and approved config 859 2: The configuration includes or exposes no known vulnerabilities 861 32:The configuration includes or exposes known vulnerabilities 863 64:The configuration is unsupportable as it exposes unacceptable 864 security vulnerabilities. 866 -1:Unexpected error."; 867 } 869 /* 870 * GROUPINGS 871 */ 873 grouping trustworthiness-vector { 874 description 875 "Allows the inclusion of a Trustworthiness Vector into 876 other constructs."; 877 container trustworthiness-vector { 878 description 879 "One or more Trustworthiness Claims assigned which expose the 880 Verifiers evaluation of the Evidence associated with the 881 AIK which signed as associated TPM Quote."; 882 leaf hardware { 883 type hardware; 884 description 885 "An 8 bit signed integter encoded per the typedef."; 886 } 887 leaf instance-identity { 888 type instance-identity; 889 description 890 "An 8 bit signed integter encoded per the typedef."; 891 } 892 leaf executables { 893 type executables; 894 description 895 "An 8 bit signed integter encoded per the typedef."; 896 } 897 leaf configuration { 898 type configuration; 899 description 900 "An 8 bit signed integter encoded per the typedef."; 901 } 902 } 903 } 905 grouping verifier-evidence { 906 description 907 "Evidence generated by the Verifier."; 908 leaf appraisal-timestamp { 909 type yang:date-and-time; 910 mandatory true; 911 description 912 "The timestamp of the Verifier's appraisal. This can be used 913 by a Relying Party to determine the freshness of the 914 attestation results."; 915 } 916 leaf verifier-algorithm-type { 917 type identityref { 918 base taa:asymmetric; 919 } 920 mandatory true; 921 description 922 "Platform asymmetric algorithm used in the Verifier signature 923 process."; 924 } 925 leaf verifier-signature { 926 type binary; 927 mandatory true; 928 description 929 "Signature of the Verifier across all the current objects in 930 the attestation-results container except for 'verifier- 931 signature' and 'verifier-certificate-keystore-ref'. 933 This assumes CDDL encoding of the objects in the current 934 order of this YANG model."; 935 } 936 leaf verifier-certificate-keystore-ref { 937 type tpm:certificate-name-ref; 938 mandatory true; 939 description 940 "A reference to a specific certificate to an asymmetric key 941 in the Keystore for the Verifier which can be used to validate 942 the 'verifier-signature'. Note that the 943 'name' reference must be globally unique so that it can be 944 read by the Relying Party in a way which identifies a 945 specific Verifier."; 946 } 947 } 949 grouping tpm20-cddl-attestation-results { 950 description 951 "Elements combined into a CDDL representation for TPM2.0."; 952 uses trustworthiness-vector; 953 list tpm20-pcr-selection { 954 key "tpm20-hash-algo"; 955 description 956 "Specifies the list of PCRs and Hash Algorithms used by the 957 Verifier."; 958 reference 959 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 960 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; 961 uses tpm:tpm20-hash-algo; 962 leaf-list pcr-index { 963 type tpm:pcr; 964 description 965 "The numbers of the PCRs associated with the TPM2B_DIGEST."; 966 } 967 } 968 leaf TPM2B_DIGEST { 969 mandatory true; 970 type binary; 971 description 972 "A hash of the latest PCR values (and the hash algorithm used) 973 which have been returned from a Verifier for the selected PCRs 974 identified within TPML_PCR_SELECTION."; 975 reference 976 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 977 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 978 } 979 leaf clock { 980 mandatory true; 981 type uint64; 982 description 983 "Clock is a monotonically increasing counter that advances 984 whenever power is applied to a TPM2. The value of Clock is 985 incremented each millisecond."; 986 reference 987 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 988 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.2"; 989 } 990 leaf reset-counter { 991 mandatory true; 992 type uint32; 993 description 994 "This counter increments on each TPM Reset. The most common 995 TPM Reset would be due to a hardware power cycle."; 996 reference 997 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 998 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.3"; 999 } 1000 leaf restart-counter { 1001 mandatory true; 1002 type uint32; 1003 description 1004 "This counter shall increment by one for each TPM Restart or 1005 TPM Resume. The restartCount shall be reset to zero on a TPM 1006 Reset."; 1007 reference 1008 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1009 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.4"; 1010 } 1011 leaf safe { 1012 mandatory true; 1013 type boolean; 1014 description 1015 "This parameter is set to YES when the value reported in Clock 1016 is guaranteed to be unique for the current Owner. It is set to 1017 NO when the value of Clock may have been reported in a previous 1018 attestation or access."; 1019 reference 1020 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1021 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.5"; 1022 } 1023 leaf attester-certificate-name { 1024 mandatory true; 1025 description 1026 "The Attester is associated with these results."; 1027 type tpm:certificate-name-ref; 1028 } 1029 uses verifier-evidence; 1030 } 1032 grouping tpm12-cddl-attestation-results { 1033 description 1034 "Elements combined into a CDDL representation for TPM1.2."; 1035 uses trustworthiness-vector; 1036 uses tpm:tpm12-pcr-selection; 1037 leaf-list tpm12-pcr-value { 1038 type binary; 1039 description 1040 "The list of TPM_PCRVALUEs from each PCR selected in sequence 1041 of tpm12-pcr-selection."; 1042 reference 1043 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1044 TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf 1045 Section 10.9.7"; 1046 } 1047 uses tpm:tpm12-hash-algo { 1048 refine "tpm12-hash-algo" { 1049 mandatory true; 1050 } 1051 } 1052 leaf TPM12-quote-timestamp { 1053 type yang:date-and-time; 1054 mandatory true; 1055 description 1056 "The timestamp for when the indicator of freshness (such as a 1057 nonce) was generated. This is the indicator of freshness 1058 which was used in the generation of the TPM1.2 quote. This 1059 timestamp can be used by a Relying Party to determine the 1060 freshness of the attestation results."; 1061 } 1062 leaf attester-certificate-name { 1063 mandatory true; 1064 description 1065 "The Attester is associated with these results."; 1066 type tpm:certificate-name-ref; 1067 } 1068 uses verifier-evidence; 1069 } 1071 /* 1072 * NOTIFICATIONS 1073 */ 1075 notification tpm20-stamped-passport { 1076 description 1077 "The augmentation of the most recent Attestation Results 1078 delivered from a Verifier with a TPM2.0 Quote."; 1079 container attestation-results { 1080 description 1081 "The latest Verifier delivered Attestation Results."; 1082 uses tpm20-cddl-attestation-results; 1083 } 1084 container tpm20-quote { 1085 description 1086 "The TPM2.0 quote delivered in response to a connectivity 1087 request."; 1088 leaf TPMS_QUOTE_INFO { 1089 type binary; 1090 mandatory true; 1091 description 1092 "A hash of the latest PCR values (and the hash algorithm 1093 used) which have been returned from a Verifier for the 1094 selected PCRs and Hash Algorithms."; 1095 reference 1096 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1097 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 1098 } 1099 leaf quote-signature { 1100 type binary; 1101 mandatory true; 1102 description 1103 "Quote signature returned by TPM Quote. The signature was 1104 generated using the key associated with the 1105 certificate 'name'."; 1106 reference 1107 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1108 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 11.2.1"; 1109 } 1110 } 1111 } 1113 notification tpm12-stamped-passport { 1114 description 1115 "The augmentation of the most recent Attestation Results 1116 delivered from a Verifier with a TPM1.2 Quote."; 1117 container attestation-results { 1118 description 1119 "The latest Verifier delivered Attestation Results."; 1120 uses tpm12-cddl-attestation-results; 1121 } 1122 container tpm12-quote { 1123 description 1124 "The TPM1.2 quote delivered in response to a connectivity 1125 request."; 1126 leaf TPM_QUOTE2 { 1127 type binary; 1128 description 1129 "Result of a TPM1.2 Quote2 operation. This includes PCRs, 1130 signatures, locality, the provided nonce and other data which 1131 can be further parsed to appraise the Attester."; 1132 reference 1133 "TPM1.2 commands rev116 July 2007, Section 16.5"; 1134 } 1135 } 1136 } 1138 /* 1139 * DATA NODES 1140 */ 1142 container attestation-results { 1143 presence 1144 "Indicates that Verifier has appraised the security posture of 1145 the Attester, and returned the results within this container."; 1146 description 1147 "Retains the most recent Attestation Results for this Attester. 1148 It must only be written by a Verfier which is to be trusted by a 1149 Relying Party."; 1151 choice tpm-specification-version { 1152 description 1153 "Identifies the cryptoprocessor API set which drove the 1154 Attestation Results."; 1155 case tpm20-attestation-results-cddl { 1156 if-feature "taa:tpm20"; 1157 description 1158 "Attestation Results which are returned from the 1159 evaluation of Evidence which includes a TPM2 quote."; 1160 container tpm20-attestation-results-cddl { 1161 description 1162 "Attestation Results which are returned from the 1163 evaluation of Evidence which includes a TPM2 quote."; 1164 uses tpm20-cddl-attestation-results; 1165 } 1166 } 1167 case tpm12-attestation-results-cddl { 1168 if-feature "taa:tpm12"; 1169 description 1170 "Attestation Results which are returned from the 1171 evaluation of Evidence which includes a TPM1.2 quote."; 1172 container tpm12-attestation-results-cddl { 1173 description 1174 "Attestation Results which are returned from the 1175 evaluation of Evidence which includes a TPM1.2 quote."; 1176 uses tpm12-cddl-attestation-results; 1177 } 1178 } 1179 } 1180 } 1181 } 1182 1184 6. Security Considerations 1186 Verifiers are limited to the Evidence available for appraisal from a 1187 Router. Although the state of the art is improving, some exploits 1188 may not be visible via Evidence. 1190 Only security measurements which are placed into PCRs are capable of 1191 being exposed via TPM Quote at time(EG'). 1193 Successful attacks on an Verifier have the potential of affecting 1194 traffic on the Trusted Topology. 1196 For Trusted Path Routing, links which are part of the FlexAlgo are 1197 visible across the entire IGP domain. Therefore a compromised device 1198 will know when it is being bypassed. 1200 Access control for the objects in Figure 4 should be tightly 1201 controlled so that it becomes difficult for the Stamped Passport to 1202 become a denial of service vector. 1204 7. References 1206 7.1. Normative References 1208 [attestation-results] 1209 "Attestation Results for Connectivity", April 2021, 1210 . 1213 [crypto-types] 1214 "Common YANG Data Types for Cryptography", May 2020, 1215 . 1218 [RATS-Arch] 1219 "Remote Attestation Procedures Architecture", March 2020, 1220 . 1223 [RATS-YANG] 1224 "A YANG Data Model for Challenge-Response-based Remote 1225 Attestation Procedures using TPMs", June 2020, 1226 . 1229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1230 Requirement Levels", BCP 14, RFC 2119, 1231 DOI 10.17487/RFC2119, March 1997, 1232 . 1234 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 1235 RFC 6021, DOI 10.17487/RFC6021, October 2010, 1236 . 1238 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1239 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1240 May 2017, . 1242 [TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003, 1243 . 1246 [TPM2.0] TCG, ., "TPM 2.0 Library Specification", March 2013, 1247 . 1250 7.2. Informative References 1252 [I-D.ietf-lsr-flex-algo] 1253 Cisco Systems, Juniper Networks, Cisco Systems, Cisco 1254 Systems, and Edward Jones, "IGP Flexible Algorithm", 1255 draft-ietf-lsr-flex-algo-17 (work in progress), July 2021. 1257 [IEEE-802.1X] 1258 Parsons, G., "802.1AE: MAC Security (MACsec)", January 1259 2020, 1260 . 1262 [MACSEC] Seaman, M., "802.1AE: MAC Security (MACsec)", January 1263 2006, . 1265 [RATS-Device] 1266 "Network Device Remote Integrity Verification", n.d., 1267 . 1270 [RATS-Interactions] 1271 "Reference Interaction Models for Remote Attestation 1272 Procedures", June 2020, . 1276 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1277 Levkowetz, Ed., "Extensible Authentication Protocol 1278 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1279 . 1281 [stream-subscription] 1282 "Attestation Event Stream Subscription", June 2020, 1283 . 1286 Appendix A. Acknowledgements 1288 Peter Psenak, Shwetha Bhandari, Adwaith Gautham, Annu Singh, Sujal 1289 Sheth, Nancy Cam Winget, and Ned Smith. 1291 Appendix B. Change Log 1293 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 1295 v03-v04 1297 o Moved in concert with draft-voit-rats-attestation-results as 1298 Trustworthiness Claims became 8 bit signed integers. 1300 v02-v03 1302 o Integrated [attestation-results] as prerequisite context. 1304 o Totally rearranged content. But there were not meaningful process 1305 changes. 1307 o Redid YANG model, and highlighted CDDL needs. 1309 v01-v02 1311 o Minor tweaks such as renaming and removal of a few 1312 trustworthiness-claims 1314 v00-v01 1316 o Minor tweaks 1318 v02-v00 of draft-voit-rats-trustworthy-path-routing-00 1320 o file rename was due to an IETF tool submission glitch 1322 o The Attester's AIK is included within the Stamped Passport. This 1323 eliminates the need to provision to AIK certificate on the Relying 1324 Party. 1326 o Removed Centralized variant 1328 o Added timing diagram, and moved content around to match 1330 v01-v02 of draft-voit-rats-trusted-path-routing 1332 o Extracted the attestation stream, and placed into draft-birkholz- 1333 rats-network-device-subscription 1335 o Introduced the Trustworthiness Vector 1337 v00-v01 of draft-voit-rats-trusted-path-routing 1339 o Move all FlexAlgo terminology to allow passport definition to be 1340 more generic. 1342 o Edited Figure 1 so that (4) points to the egress router. 1344 o Added text freshness mechanisms, and articulated configured 1345 subscription support. 1347 o Minor YANG model clarifications. 1349 o Added a few open questions which Frank thinks interesting to work. 1351 Appendix C. Open Questions 1353 (1) When there is no available Trusted Topology? 1355 Do we need functional requirements on how to handle traffic to/from 1356 Sensitive Subnets when no Trusted Topology exists between IGP edges? 1357 The network typically can make this unnecessary. For example it is 1358 possible to construct a local IPSec tunnel to make untrusted devices 1359 appear as Transparently-Transited Devices. This way Secure Subnets 1360 could be tunneled between FlexAlgo nodes where an end-to-end path 1361 doesn't currently exist. However there still is a corner case where 1362 all IGP egress points are not considered sufficiently trustworthy. 1364 (2) Extension of the Stamped Passport? 1366 Format of the reference to the 'verifier-certificate-name' based on 1367 WG desire to include more information in the Stamped Passport. Also 1368 we need to make sure that the keystore referenced names are globally 1369 unique, else we will need to include a node name in the object set. 1371 (3) Encoding of objects in CDDL. A Verifier will want to sign 1372 encoded objects rather than YANG structures. It is most efficient to 1373 encode the Attestation Results once on the Verifier, and push these 1374 down via a YANG model to the Attester. 1376 Authors' Addresses 1378 Eric Voit 1379 Cisco Systems, Inc. 1380 8135 Maple Lawn Blvd 1381 Fulton, Maryland 20759 1382 USA 1384 Email: evoit@cisco.com 1386 Chennakesava Reddy Gaddam 1387 Cisco Systems, Inc. 1388 Cessna Business Park, Kadubeesanahalli 1389 Bangalore, Karnataka 560103 1390 India 1392 Email: chgaddam@cisco.com 1394 Guy C. Fedorkow 1395 Juniper Networks 1396 10 Technology Park Drive 1397 Westford, Massachusetts 01886 1398 USA 1400 Email: gfedorkow@juniper.net 1401 Henk Birkholz 1402 Fraunhofer SIT 1403 Rheinstrasse 75 1404 Darmstadt 64295 1405 Germany 1407 Email: henk.birkholz@sit.fraunhofer.de