Trusted Path RoutingFraunhofer SITRheinstrasse 75Darmstadt64295Germanyhenk.birkholz@sit.fraunhofer.deCisco Systems, Inc.8135 Maple Lawn BlvdFultonMaryland20759USAevoit@cisco.comHuawei Technologiesliuchunchi@huawei.comTelefonicadiego.r.lopez@telefonica.comChina Mobilechenmeiling@chinamobile.com
Security
RATS Working GroupInternet-DraftThere are end-users who believe encryption technologies like IPSec alone
are insufficient to protect the confidentiality of their highly sensitive
traffic flows. These end-users want their flows to traverse devices which
have been freshly appraised and verified for trustworthiness. This specification
describes Trusted Path Routing. Trusted Path Routing protects sensitive
flows as they transit a network by forwarding traffic to/from sensitive subnets
across network devices recently appraised as trustworthy.IntroductionThere are end-users who believe encryption technologies like IPSec alone
are insufficient to protect the confidentiality of their highly sensitive
traffic flows. These customers want their highly sensitive flows to be
transported over only network devices recently verified as trustworthy.By using a router's embedded TPM based cryptoprocessors in conjunction with
the Remote Attestation context established by , a
network provider can identify potentially compromised devices as well
as potentially exploitable (or even exploited) vulnerabilities. Using this
knowledge, it is then possible to redirect sensitive flows around these devices
while other remediations are potentially considered by Network Operations.Trusted Path Routing allows the establishing Trusted Topologies which only
include trust-verified network devices. Membership in a Trusted Topology
is established and maintained via an exchange of Stamped Passports at the
link layer between peering network devices. As links to Attesting Devices
are appraised as meeting at least a minimum set of formally defined Trustworthiness
Claims, the links are then included as members of this Trusted Topology.
Routing protocols are then used to propagate topology state throughout a
network.IP Packets to and from end-user designated Sensitive Subnets are then forwarded
into this Trusted Topology at each network boundary. This is done by an
end user identifying sensitive IP subnets where flows with applications using
these IP subnets need enhanced privacy guarantees. Trusted Path Routing passes
flows to/from these Sensitive Subnets over a Trusted Topology able to meet
these guarantees. The Trusted Topology itself consists of the interconnection
of network devices where each potentially transited device has been verified
as achieving a specific set of Trustworthiness Claims during its most recent
trustworthiness appraisal. Interesting sets of Trustworthiness Claims might
be marketed to end-users in the following ways:
all transited devices have booted with known hardware and firmware
all transited devices are from a specific set of vendors and are running
known software containing the latest patches
no guarantees provided
TerminologyTermsThe following terms are imported from :
Attester, Evidence, Passport, Relying Party, and Verifier.The following terms are impored from :
Trustworthiness Claim, Trustworthiness Vector, AR-augmented EvidenceNewly defined terms for this document:
Attested Device ---
a network connected Attester where a Verifier's most recent appraisal of
Evidence has returned a Trustworthiness Vector.
Stamped Passport ---
AR-augmented Evidence which can take two forms. First if the Attester uses
a TPM2, the the Verifier Proof-of-Freshness includes the <clock>, <reset-counter>,
<restart-counter> and <safe> objects from a recent TPM2 quote made by that
Attester, and the Relying Party Proof-of-Freshness is returned along with
the timeticks as objects embedded within the most recent TPM quote signed
by the same TPM2. Second, if the Attester uses a TPM1.2: the Verifier Proof-of-Freshness
includes a global timestamp from that Verifier, and the Relying Party Proof-of-Freshness
is embedded within a more recent TPM quote signed by the same TPM Attesting
Environment.
Sensitive Subnet ---
an IP address range where IP packets to or from that range desire confidentially
guarantees beyond those of non-identified subnets. In practice, flows to
or from a Sensitive Subnet must only have their IP headers and encapsulated
payloads accessible/visible only by Attested Devices supporting one or more
Trustworthiness Vectors.
Transparently-Transited Device ---
a network device within an network domain where any packets originally passed
into that network domain are completely opaque on that network device at
Layer 3 and above.
Trusted Topology ---
a topology which includes only Attested Devices and Transparently-Transited
Devices.
Requirements NotationThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.Implementation PrerequisitesThe specification is a valid instance of .
This specification works under the following protocol and preconfiguration
prerequisite assumptions:
All Attested Devices support the TPM remote attestation profile as laid out
in , and include either or .
One or more Verifier A's as defined in 'Interaction Model'
continuously appraise each of the Attested Devices in
a network domain, and these Verifiers return the Attestation Results back
to each originating Attested Device.
The Attested Devices are connected via link layer protocols such as
or .
Each Attester can pass a Stamped Passport to a Relying Party / Verifier B
as defined in 'Interaction Model' within
over that link layer protocol.
A Trusted Topology such as exists in an IGP
domain for the forwarding of Sensitive Subnet traffic.
This Topology will carry traffic across a set of Attested Devices which currently
meet at a defined set of Trustworthiness Vectors.
A Relying Party is able to use mechanisms such as
's affinity to include/exclude links as part
of the Trusted Topology based on the appraisal of a Stamped Passport.
Customer designated Sensitive Subnets and their requested Trustworthiness
Vectors have been identified and associated with external interfaces to/from
Attested Devices at the edge of a network. Traffic to a Sensitive Subnet
can be passed into the Trusted Topology by the Attested Device.
Relying Party/Verifier B trusts information signed by Verifier A. Verifier
B has also been pre-provisioned with certificates or public keys necessary
to confirm that Stamped Passports came from Verifier A.
End-to-end SolutionNetwork Topology AssemblyTo be included in a Trusted Topology, Stamped Passports are shared between
Attested Devices (such as routers) as part of link layer authentication.
Upon receiving and appraising the Stamped Passport during the link layer
authentication phase, the Relying Party Attested Device decides if this link
should be added as an active adjacency for a particular Trusted Topology.
In below, this might be done by applying an Appraisal Policy for Attestation
Results. The policy within each device might specify the evalutation of a
'hardware' claim as defined in , Section 2.3.4. With the appraisal, an Attesting Device be most recently
appraised with the 'hardware' Trustworthiness Claim in the 'affirming' range.
If Attested Device has been appraised outside that range, it would not become
part of the Trustworthy Topology.When enough links have been successfully added, the Trusted Topology will
support edge-to-edge forwarding as routing protocols flood the adjacency
information across the network domain.Trusted Path Topology Assembly-----------------====================As the process described above repeats over time across the set of links
within a network domain, Trusted Topologies can be extended and maintained.
Traffic to and from Sensitive Subnets is then identified at the edges of
the network domain and passed into this Trusted Topology. Traffic exchanged
with Sensitive Subnets can then be forwarded across that Trusted Topology
from all edges of the network domain. After the initial Trusted Topology
establishment, new and existing devices will continue to provide incremental
Stamped Passports. As each link is added/removed from the Trusted Topology,
the topology will adjust itself accordingly.Ultimately from an operator and users point of view, the delivered network
will be more secure and therefore the service provided more valuable. As
network operators attach great importance to the innate security of links,
also delivering security for transited network and networking devices will
also prove valuable.Attestation Information FlowsCritical to the establishment and maintenance of a Trusted Topology is the
Stamped Passport. A Stamped Passport is comprised of Evidence from both
an Attester and a Verifier. A Stamped Passport is a valid type of AR-augmented
evidence as described in .Stamped Passports are exchanged between adjacent network devices over a link
layer protocols like 802.1x or MACSEC. As both sides of a link may need
might need to appraise the other, independent Stamped Passports will often
be transmitted from either side of the link. Additionally, as link layer
protocols will continuously re-authenticate the link, this allows for fresh
Stamped Passports to be constantly appraised by either side of the connection.Each Stamped Passport will include the most recent Verifier provided Attestation
Results, as well as the most recent TPM Quote for that Attester. Upon receiving
this information as part of link layer authentication, the Relying Party
Router appraises the results and decides if this link should be added to
a Trusted Topology. describes this flow of information using the time definitions described in , and the information flows defined in Section 7 of . This figure is also a valid embodiment of the "Interaction Model" described
within . (Note that the Relying Party must also be an Attested Device in order
to attract Sensitive Subnet traffic which may flow from the Attester.)Trusted Path Timing| |
| time(RG) |
|<------Attestation Results-(2) |
~ ~ ~
time(VG')? | |
~ ~ ~
|<------nonce---------------------------------(3)time(NS')
| | |
time(EG')(4)------Stamped Passport---------------------->|
| | time(RG',RA')(5)
(6)
~
time(RX')
]]>To summarize above, Evidence about a specific Attester is generated.
Some subset of this
evidence will be in the form of PCR quotes which are signed by a TPM that
exists as the Attester's Attesting Environment. This Evidence will be delibered
to and appraised by Verifier A. Verifier A will then appraise the Attester
and give it a Trustworthiness Vector. This Trustworthiness Vector is then
signed by Verifier A and be returned as Attestation Results to the Attester.
Later, when a request comes in from a Relying Party, the Attester assembles
and returns a Stamped Passport. The Stamped Passport contains all the information
necessary for Verifier B to appraise the most recent Trustworthiness Vector
of the Attester. Based on the Verifier B appraisal, the link will be included
or not in a Trusted Topology maintained on the Relying Party.More details on the mechanisms used in the construction, verification, and
transmitting of the Stamped Passport are listed below. These numbers match
to both the numbered steps of and numbered steps
described in Section 3 of :Step 1Evidence about and Attester is generated. A portion of this Evidence will
include a PCR quote signed by a TPM private LDevID key that exists within
the Attester's TPM based Attesting Environment. The Attester sends a signed
TPM Quote which includes PCR measurements to Verifier A at time(EG).There are two alternatives for Verifier A to acquire this signed Evidence:
Subscription to the <attestation> stream defined in .
Note: this method is recommended as it will minimize the interval between
when a PCR change is made in a TPM, and when the PCR change appraisal is
incorporated within a subsequent Stamped Passport.
Periodic polling of RPC <tpm20-challenge-response-attestation> or the RPC
<tpm12-challenge-response-attestation> which are defined in .
Step 2Verifier A appraises the Evidence from Step 1. A portion of this appraisal
process will follow the appraisal process flow described below. This appraisal
process MUST be able to set at least the following set of Trustworthiness
Claims from : 'hardware', 'instance-identity',
and 'executables'. The establishment
of a Trustworthiness Vector uses the following logic on the Verifier:Verifier A Appraisal Flow "0") - push onto vector
Appraisal 4: Appraise executable loaded and filesystem integrity
if (executables NOT "0") - push onto vector
if (executables NOT affirming or warning), go to End
Appraisal 5: Appraise all remaining Trustworthiness Claims
Independently and set as appropriate.
End
]]>After the appraisal and generation of the Trustworthiness Vector, the following
are assembled as the set of Attestation Results from this particular appraisal
cycle:(2.1) the Public Attestation Key which was used to validate the TPM Quote
of Step 1. This is encoded by <public-key>, <public-key-format>,
and <public-key-algorithm-type>.(2.2) the appraised Trustworthiness Vector of the Attester as calculated
in (2.3) the PCR state information from the TPM Quote of (1) plus the time information
associated with the TPM Quote of (1). Specifically if the Attester has a
TPM2, then the values of the TPM PCRs are included (i.e., <TPM2B_DIGEST>,
<tpm20-hash-algo>, and <pcr-index>), as are the timing counters from the
TPM (i.e., <clock>, <reset-counter>, <restart-counter>, and <safe>).
Likewise if the Attester has a TPM1.2, the TPM PCR values of the <pcr-index>
and <pcr-value> are included. Timing information comes from the Verifier
itself via the <timestamp> object.(2.4) a Verifier A signature across (2.1) though (2.3). This signature is
encoded by <verifier-signature>, <verifier-key-algorithm-type>, and
<verifier-signature-key-name>.Immediately subsequent to each Verifier appraisal cycle of an Attester, these
Attestation Results MUST be pushed to the Attesting Router. This is done
via a daatstore write to the following YANG model on the Attester. A YANG
tree showing the relevant YANG objects is below. The YANG model describing
each of these objects is described later in the document. Note however that
although the YANG model shows the specific objects which are needed, the
specific set of objects needs to be encoded in CDDL. This makes the payload
going over TLS more efficient. Look for this encoding in a new version of
the draft which is pending.Attestation Results Tree
module: ietf-trustworthiness-claims
+--rw attestation-results!
+--rw (tpm-specification-version)?
+--:(tpm20-attestation-results-cddl) {taa:tpm20}?
| +--rw tpm20-attestation-results-cddl
| +--rw trustworthiness-vector
| | +--rw hardware? hardware
| | +--rw instance-identity? instance-identity
| | +--rw executables? executables
| | +--rw configuration? configuration
| +--rw tpm20-pcr-selection* [tpm20-hash-algo]
| | +--rw tpm20-hash-algo identityref
| | +--rw pcr-index* tpm:pcr
| +--rw TPM2B_DIGEST binary
| +--rw clock uint64
| +--rw reset-counter uint32
| +--rw restart-counter uint32
| +--rw safe boolean
| +--rw attester-certificate-name
| | tpm:certificate-name-ref
| +--rw appraisal-timestamp
| | yang:date-and-time
| +--rw verifier-algorithm-type identityref
| +--rw verifier-signature binary
| +--rw verifier-certificate-keystore-ref
| tpm:certificate-name-ref
+--:(tpm12-attestation-results-cddl) {taa:tpm12}?
+--rw tpm12-attestation-results-cddl
+--rw trustworthiness-vector
| +--rw hardware? hardware
| +--rw instance-identity? instance-identity
| +--rw executables? executables
| +--rw configuration? configuration
+--rw pcr-index* pcr
+--rw tpm12-pcr-value* binary
+--rw tpm12-hash-algo identityref
+--rw TPM12-quote-timestamp
| yang:date-and-time
+--rw attester-certificate-name
| tpm:certificate-name-ref
+--rw appraisal-timestamp
| yang:date-and-time
+--rw verifier-algorithm-type identityref
+--rw verifier-signature binary
+--rw verifier-certificate-keystore-ref
tpm:certificate-name-ref
Step 3At time(NS') some form of time-based freshness (such as a nonce or Epoch
Handle ) will be generated in a way which makes it available to the Relying Party.
Soon after time(NS'), a Relying Party will make a Link Layer authentication
request to an Attester via a either or . This connection request MUST expect the return of credentials from the Attester.Step 4Upon receipt of the Link Layer request from Step 3, a Stamped Passport is
generated and sent to the Relying Party. The Stamped Passport MUST include
the following:(4.1) The Attestation Results from Step 2(4.2) New signed, verifiably fresh PCR measurements based on a TPM quote
at time(EG') which incorporates the freshness information known by the Relying
Party from Step 3. If it is a nonce, the freshness information will have
been delivered as part of the link layer connection request in Steps 3.Stamped Passports contain following objects, defined in this document via
YANG. A subsequent draft will convert the objects below into CDDL format
so that the objects can efficiently be passed over EAP.If an Attester includes a TPM2, these YANG objects are:YANG Tree for a TPM2 Stamped Passport
+---n tpm20-stamped-passport
+--ro attestation-results
| +--ro trustworthiness-vector
| | +--ro hardware? hardware
| | +--ro instance-identity? instance-identity
| | +--ro executables? executables
| | +--ro configuration? configuration
| +--ro tpm20-pcr-selection* [tpm20-hash-algo]
| | +--ro tpm20-hash-algo identityref
| | +--ro pcr-index* tpm:pcr
| +--ro TPM2B_DIGEST binary
| +--ro clock uint64
| +--ro reset-counter uint32
| +--ro restart-counter uint32
| +--ro safe boolean
| +--ro attester-certificate-name
| | tpm:certificate-name-ref
| +--ro appraisal-timestamp
| | yang:date-and-time
| +--ro verifier-algorithm-type identityref
| +--ro verifier-signature binary
| +--ro verifier-certificate-keystore-ref
| tpm:certificate-name-ref
+--ro tpm20-quote
+--ro TPMS_QUOTE_INFO binary
+--ro quote-signature binary
Note that where a TPM2.0 is used, the PCR numbers and hash algorithms quoted
in Step 1 MUST match the PCR numbers and hash algorithms quoted in this step.And if the Attester is a TPM1.2, the YANG object are:YANG Tree for a TPM1.2 Stamped Passport
+---n tpm12-stamped-passport
+--ro attestation-results
| +--ro trustworthiness-vector
| | +--ro hardware? hardware
| | +--ro instance-identity? instance-identity
| | +--ro executables? executables
| | +--ro configuration? configuration
| +--ro pcr-index* pcr
| +--ro tpm12-pcr-value* binary
| +--ro tpm12-hash-algo identityref
| +--ro TPM12-quote-timestamp
| | yang:date-and-time
| +--ro attester-certificate-name
| | tpm:certificate-name-ref
| +--ro appraisal-timestamp
| | yang:date-and-time
| +--ro verifier-algorithm-type identityref
| +--ro verifier-signature binary
| +--ro verifier-certificate-keystore-ref
| tpm:certificate-name-ref
+--ro tpm12-quote
+--ro TPM_QUOTE2? binary
With either of these passport formats, if the TPM quote is verifiably fresh,
then the state of the Attester can be appraised by a network peer.Note that with or , Step 3 plus Step 4 will repeat periodically independently of any subsequent
iteration Steps 1 and Step 2. This allows for periodic reauthentication of
the link layer in a way not bound to the updating of Verifier A's Attestation
Results.Step 5Upon receipt of the Stamped Passport generated in Step 4, the Relying Party
appraises this Stamped Passport as per its Appraisal Policy for Attestation
Results. The result of this application will determine how the Stamped Passport
will impact adjacencies within a Trusted Topology. The decision process
is as follows:(5.1) Verify that (4.2) includes the freshness context from Step 3.(5.2) Use a local certificate to validate the signature (4.1).(5.3) Verify that the hash from (4.2) matches (4.1)(5.4) Use the identity of (2.1) to validate the signature of (4.2).(5.5) Failure of any steps (5.1) through (5.4) means the link does not meet
minimum validation criteria, therefore appraise the link as having a null
Verifier B Trustworthiness Vector. Jump to Step 6.(5.6) Compare the time(EG) TPM state to the time(EG') TPM state
If TPM2.0
If the <TPM2B_DIGEST>, <reset-counter>, <restart-counter> and <safe>
are equal between the Attestation Results and the TPM Quote at time(EG')
then Relying Party can accept (2.1) as the link's Trustworthiness Vector.
Jump to Step 6.
If the <reset-counter>, <restart-counter> and <safe> are equal between
the Attestation Results and the TPM Quote at time(EG'), and the <clock>
object from time(EG') has not incremented by an unacceptable number of seconds
since the Attestation Result, then Relying Party can accept (2.1) as the
link's Trustworthiness Vector. Jump to Step 6.)
Assign the link a null Trustworthiness Vector.
If TPM1.2
If the <pcr-index>'s and <tpm12-pcr-value>'s are equal between the Attestation
Results and the TPM Quote at time(EG'), then Relying Party can accept (2.1)
as the link's Trustworthiness Vector. Jump to step (6).
If the time hasn't incremented an unacceptable number of seconds from the
Attestation Results <timestamp> and the system clock of the Relying Party,
then Relying Party can accept (2.1) as the link's Trustworthiness Vector.
Jump to step 6.)
Assign the link a null Trustworthiness Vector.
(5.7) Assemble the Verifier B Trustworthiness Vector
Copy Verifier A Trustworthiness Vector to Verifier B Trustworthiness Vector
Prune any Trustworthiness Claims the Relying Party doesn't accept from this
Verifier.
Step 6After the Trustworthiness Vector has been validated or reset, based on the
link's Trustworthiness Vector, the Relying Party adjusts the link affinity
of the corresponding ISIS topology. ISIS will then replicate the link state across the IGP domain.
Traffic will then avoid links which do not have a qualifying Trustworthiness
Vector.YANG ModuleThis YANG module imports modules from , and .
<CODE BEGINS> ietf-trustworthiness-claims@2024-07-07.yang
module ietf-trustworthiness-claims {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-trustworthiness-claims";
prefix tc;
import ietf-yang-types {
prefix yang;
}
import ietf-tcg-algs {
prefix taa;
reference
"draft-ietf-rats-yang-tpm-charra";
}
import ietf-tpm-remote-attestation {
prefix tpm;
reference
"draft-ietf-rats-yang-tpm-charra";
}
organization "IETF";
contact
"WG Web: <http://tools.ietf.org/wg/rats/>
WG List: <mailto:rats@ietf.org>
Editor: Eric Voit
<mailto:evoit@cisco.com>";
description
"This module contains conceptual YANG specifications for
subscribing to attestation streams being generated from TPM chips.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
Documents (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices.";
revision 2021-11-03 {
description
"Initial version.";
reference
"draft-voit-rats-trustworthy-path-routing";
}
/*
* TYPEDEF
*/
typedef trustworthiness-claim {
type int8;
description
"A Verifier asserted value designed to enable a common
understanding of a Verifier trustworthiness appraisal. The
value assignments for this 8 bit signed integer will follow
these guidelines:
Affirming: The Verifier affirms the Attester support for this
aspect of trustworthiness
- Values 2 to 31: A standards enumerated reason for affirming.
- Values -2 to -32: A non-standard reason for affirming.
Warning: The Verifier warns about this aspect of trustworthiness.
- Values 32 to 63: A standards enumerated reason for the
warning.
- Values -33 to -64: A non-standard reason for the warning.
Contraindicated: The Verifier asserts the Attester is explicitly
untrustworthy in regard to this aspect.
- Values 64 to 127: A standards enumerated reason for the
contraindication.
- Values -65 to -128: A non-standard reason for the
contraindication.
None: The Verifier makes no assertions about this Trustworthiness
Claim. The following values are reserved with the following
meanings across all instances of trustworthiness-claim.
- Value 0: Note: this should always be always treated
equivalently by the Relying Party as no claim being made.
I.e., the RP's Appraisal Policy for Attestation Results
SHOULD NOT make any distinction between a Trustworthiness
Claim with enumeration '0', and no Trustworthiness Claim
being provided.
- Value 1: The Evidence received contains unexpected elements
which the Verifier is unable to parse. An example might be
that the wrong type of Evidence has been delivered.
- Value -1: An unexpected error occurred during the Verifier's
appraisal processing. Note: while no claim is being made, the
Relying Party MAY make a distinction between a
Trustworthiness Claim with enumeration '-1', and no
Trustworthiness Claim being provided.";
}
typedef hardware {
type trustworthiness-claim;
description
"A Verifier has appraised any Attester hardware and firmware
which are able to expose fingerprints of their identity and
running code.
The following are specific reserved values of hardware and
the meanings of these reserved values:
0: No assertion
1: The Verifer cannot parse unexpected Evidence
-1:Verifier malfunction
2: An Attester has passed its hardware and/or firmware
verifications needed to demonstrate that these are
genuine/supported.
32:An Attester contains only genuine/supported hardware and/or
firmware, but there are known security vulnerabilities.
96:Attester hardware and/or firmware is recognized, but its
trustworthiness is contraindicated.
97:A Verifier does not recognize an Attester's hardware or
firmware, but it should be recognized.";
}
typedef instance-identity {
type trustworthiness-claim;
description
"A Verifier has appraised an Attesting Environment's unique
identity based upon private key signed Evidence which can be
correlated to a unique instantiated instance of the Attester.
(Note: this Trustworthiness Claim should only be generated if
the Verifier actually expects to recognize the unique identity
of the Attester.)
The following are specific reserved values of instance-identity
and the meanings of these reserved values:
0: No assertion
1: The Verifer cannot parse unexpected Evidence
-1:Verifier malfunction
2: The Attesting Environment is recognized, and the associated
instance of the Attester is not known to be compromised.
96:The Attesting Environment is recognized, and but its unique
private key indicates a device which is not trustworthy.
97:The Attesting Environment is not recognized; however the
Verifier believes it should be.";
}
typedef executables {
type trustworthiness-claim;
description
"A Verifier has appraised and evaluated relevant runtime files,
scripts, and/or other objects which have been loaded into the
Target environment's memory.
The following are specific reserved values of executables and
the meanings of these reserved values:
0: No assertion
1: The Verifer cannot parse unexpected Evidence
-1:Verifier malfunction
2: Only a recognized genuine set of approved executables,
scripts, files, and/or objects have been loaded during
and after the boot process.
3: Only a recognized genuine set of approved executables have
been loaded during the boot process.
32:Only a recognized genuine set of executables, scripts, files,
and/or objects have been loaded. However the Verifier cannot
vouch for a subset of these due to known bugs or other known
vulnerabilities.
33:Runtime memory includes executables, scripts, files, and/or
objects which are not recognized.
96:Runtime memory includes executables, scripts, files, and/or
object which are contraindicated.
99:Cryptographic validation of the Evidence has failed.";
}
typedef configuration {
type trustworthiness-claim;
description
"A Verifier has appraised an Attester's configuration, and is
able to make conclusions regarding the exposure of known
vulnerabilities.
The following are specific reserved values of configuration and
the meanings of these reserved values:
0: No assertion
1: The Verifer cannot parse unexpected Evidence
-1:Verifier malfunction
2: The configuration is a known and approved config
3: The configuration includes or exposes no known vulnerabilities
32:The configuration includes or exposes known vulnerabilities
64:The configuration is unsupportable as it exposes unacceptable
security vulnerabilities.";
}
/*
* GROUPINGS
*/
grouping trustworthiness-vector {
description
"Allows the inclusion of a Trustworthiness Vector into
other constructs.";
container trustworthiness-vector {
description
"One or more Trustworthiness Claims assigned which expose the
Verifiers evaluation of the Evidence associated with the
AIK which signed as associated TPM Quote.";
leaf hardware {
type hardware;
description
"An 8 bit signed integter encoded per the typedef.";
}
leaf instance-identity {
type instance-identity;
description
"An 8 bit signed integter encoded per the typedef.";
}
leaf executables {
type executables;
description
"An 8 bit signed integter encoded per the typedef.";
}
leaf configuration {
type configuration;
description
"An 8 bit signed integter encoded per the typedef.";
}
}
}
grouping verifier-evidence {
description
"Evidence generated by the Verifier.";
leaf appraisal-timestamp {
type yang:date-and-time;
mandatory true;
description
"The timestamp of the Verifier's appraisal. This can be used
by a Relying Party to determine the freshness of the
attestation results.";
}
leaf verifier-algorithm-type {
type identityref {
base taa:asymmetric;
}
mandatory true;
description
"Platform asymmetric algorithm used in the Verifier signature
process.";
}
leaf verifier-signature {
type binary;
mandatory true;
description
"Signature of the Verifier across all the current objects in
the attestation-results container except for 'verifier-
signature' and 'verifier-certificate-keystore-ref'.
This assumes CDDL encoding of the objects in the current
order of this YANG model.";
}
leaf verifier-certificate-keystore-ref {
type tpm:certificate-name-ref;
mandatory true;
description
"A reference to a specific certificate to an asymmetric key
in the Keystore for the Verifier which can be used to validate
the 'verifier-signature'. Note that the
'name' reference must be globally unique so that it can be
read by the Relying Party in a way which identifies a
specific Verifier.";
}
}
grouping tpm20-cddl-attestation-results {
description
"Elements combined into a CDDL representation for TPM2.0.";
uses trustworthiness-vector;
list tpm20-pcr-selection {
key "tpm20-hash-algo";
description
"Specifies the list of PCRs and Hash Algorithms used by the
Verifier.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7";
uses tpm:tpm20-hash-algo;
leaf-list pcr-index {
type tpm:pcr;
description
"The numbers of the PCRs associated with the TPM2B_DIGEST.";
}
}
leaf TPM2B_DIGEST {
mandatory true;
type binary;
description
"A hash of the latest PCR values (and the hash algorithm used)
which have been returned from a Verifier for the selected PCRs
identified within TPML_PCR_SELECTION.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1";
}
leaf clock {
mandatory true;
type uint64;
description
"Clock is a monotonically increasing counter that advances
whenever power is applied to a TPM2. The value of Clock is
incremented each millisecond.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.2";
}
leaf reset-counter {
mandatory true;
type uint32;
description
"This counter increments on each TPM Reset. The most common
TPM Reset would be due to a hardware power cycle.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.3";
}
leaf restart-counter {
mandatory true;
type uint32;
description
"This counter shall increment by one for each TPM Restart or
TPM Resume. The restartCount shall be reset to zero on a TPM
Reset.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.4";
}
leaf safe {
mandatory true;
type boolean;
description
"This parameter is set to YES when the value reported in Clock
is guaranteed to be unique for the current Owner. It is set to
NO when the value of Clock may have been reported in a previous
attestation or access.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.5";
}
leaf attester-certificate-name {
mandatory true;
description
"The Attester is associated with these results.";
type tpm:certificate-name-ref;
}
uses verifier-evidence;
}
grouping tpm12-cddl-attestation-results {
description
"Elements combined into a CDDL representation for TPM1.2.";
uses trustworthiness-vector;
uses tpm:tpm12-pcr-selection;
leaf-list tpm12-pcr-value {
type binary;
description
"The list of TPM_PCRVALUEs from each PCR selected in sequence
of tpm12-pcr-selection.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
Section 10.9.7";
}
uses tpm:tpm12-hash-algo {
refine "tpm12-hash-algo" {
mandatory true;
}
}
leaf TPM12-quote-timestamp {
type yang:date-and-time;
mandatory true;
description
"The timestamp for when the indicator of freshness (such as a
nonce) was generated. This is the indicator of freshness
which was used in the generation of the TPM1.2 quote. This
timestamp can be used by a Relying Party to determine the
freshness of the attestation results.";
}
leaf attester-certificate-name {
mandatory true;
description
"The Attester is associated with these results.";
type tpm:certificate-name-ref;
}
uses verifier-evidence;
}
/*
* NOTIFICATIONS
*/
notification tpm20-stamped-passport {
description
"The augmentation of the most recent Attestation Results
delivered from a Verifier with a TPM2.0 Quote.";
container attestation-results {
description
"The latest Verifier delivered Attestation Results.";
uses tpm20-cddl-attestation-results;
}
container tpm20-quote {
description
"The TPM2.0 quote delivered in response to a connectivity
request.";
leaf TPMS_QUOTE_INFO {
type binary;
mandatory true;
description
"A hash of the latest PCR values (and the hash algorithm
used) which have been returned from a Verifier for the
selected PCRs and Hash Algorithms.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1";
}
leaf quote-signature {
type binary;
mandatory true;
description
"Quote signature returned by TPM Quote. The signature was
generated using the key associated with the
certificate 'name'.";
reference
"https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 11.2.1";
}
}
}
notification tpm12-stamped-passport {
description
"The augmentation of the most recent Attestation Results
delivered from a Verifier with a TPM1.2 Quote.";
container attestation-results {
description
"The latest Verifier delivered Attestation Results.";
uses tpm12-cddl-attestation-results;
}
container tpm12-quote {
description
"The TPM1.2 quote delivered in response to a connectivity
request.";
leaf TPM_QUOTE2 {
type binary;
description
"Result of a TPM1.2 Quote2 operation. This includes PCRs,
signatures, locality, the provided nonce and other data which
can be further parsed to appraise the Attester.";
reference
"TPM1.2 commands rev116 July 2007, Section 16.5";
}
}
}
/*
* DATA NODES
*/
container attestation-results {
presence
"Indicates that Verifier has appraised the security posture of
the Attester, and returned the results within this container.";
description
"Retains the most recent Attestation Results for this Attester.
It must only be written by a Verfier which is to be trusted by a
Relying Party.";
choice tpm-specification-version {
description
"Identifies the cryptoprocessor API set which drove the
Attestation Results.";
case tpm20-attestation-results-cddl {
if-feature "taa:tpm20";
description
"Attestation Results which are returned from the
evaluation of Evidence which includes a TPM2 quote.";
container tpm20-attestation-results-cddl {
description
"Attestation Results which are returned from the
evaluation of Evidence which includes a TPM2 quote.";
uses tpm20-cddl-attestation-results;
}
}
case tpm12-attestation-results-cddl {
if-feature "taa:tpm12";
description
"Attestation Results which are returned from the
evaluation of Evidence which includes a TPM1.2 quote.";
container tpm12-attestation-results-cddl {
description
"Attestation Results which are returned from the
evaluation of Evidence which includes a TPM1.2 quote.";
uses tpm12-cddl-attestation-results;
}
}
}
}
}
<CODE ENDS>
Security ConsiderationsVerifiers are limited to the Evidence available for appraisal from a Router.
Although the state of the art is improving, some exploits may not be visible
via Evidence.Only security measurements which are placed into PCRs are capable of being
exposed via TPM Quote at time(EG').Successful attacks on an Verifier have the potential of affecting traffic
on the Trusted Topology.For Trusted Path Routing, links which are part of the FlexAlgo are visible
across the entire IGP domain. Therefore a compromised device will know when
it is being bypassed.Access control for the objects in should be tightly
controlled so that it becomes difficult for the Stamped
Passport to become a denial of service vector.ReferencesNormative ReferencesCommon YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]Attestation Results for Secure InteractionsCisco SystemsFraunhofer SITMITLinaroIntel This document defines reusable Attestation Result information
elements. When these elements are offered to Relying Parties as
Evidence, different aspects of Attester trustworthiness can be
evaluated. Additionally, where the Relying Party is interfacing with
a heterogeneous mix of Attesting Environment and Verifier types,
consistent policies can be applied to subsequent information exchange
between each Attester and the Relying Party.
YANG Data Types and Groupings for CryptographyWatsen Networks This document presents a YANG 1.1 (RFC 7950) module defining
identities, typedefs, and groupings useful to cryptographic
applications.
Remote ATtestation procedureS (RATS) ArchitectureIn network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMsFraunhofer SITFraunhofer SITThoughtSpotCisco SystemsCisco SystemsHuawei TechnologiesHewlett Packard EnterpriseJuniper Networks This document defines YANG Remote Procedure Calls (RPCs) and a few
configuration nodes required to retrieve attestation evidence about
integrity measurements from a device, following the operational
context defined in TPM-based Network Device Remote Integrity
Verification. Complementary measurement logs are also provided by
the YANG RPCs, originating from one or more roots of trust for
measurement (RTMs). The module defined requires at least one TPM 1.2
or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), or
equivalent hardware implementations that include the protected
capabilities as provided by TPMs as well as a corresponding software
stack, included in the device components of the composite device the
YANG server is running on.
TPM 1.2 Main SpecificationTPM 2.0 Library SpecificationKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesExtensible Authentication Protocol (EAP)This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]Reference Interaction Models for Remote Attestation ProceduresAttestation Event Stream SubscriptionIGP Flexible AlgorithmCisco Systems, Inc.Juniper Networks, Inc.Cisco Systems, Inc.Cisco Systems, IncEdward JonesIGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.
Network Device Remote Integrity Verification802.1AE: MAC Security (MACsec)802.1AE: MAC Security (MACsec)AcknowledgementsPeter Psenak, Shwetha Bhandari, Adwaith Gautham, Annu Singh, Sujal Sheth,
Nancy Cam Winget, and Ned Smith.Open Questions(1) When there is no available Trusted Topology?Do we need functional requirements on how to handle traffic to/from Sensitive
Subnets when no Trusted Topology exists between IGP edges? The network typically
can make this unnecessary. For example it is possible to construct a local
IPSec tunnel to make untrusted devices appear as Transparently-Transited
Devices. This way Secure Subnets could be tunneled between FlexAlgo nodes
where an end-to-end path doesn't currently exist. However there still is
a corner case where all IGP egress points are not considered sufficiently
trustworthy.(2) Extension of the Stamped Passport?Format of the reference to the 'verifier-certificate-name' based on WG desire
to include more information in the Stamped Passport. Also we need to make
sure that the keystore referenced names are globally unique, else we will
need to include a node name in the object set.(3) Encoding of objects in CDDL. A Verifier will want to sign encoded objects
rather than YANG structures. It is most efficient to encode the Attestation
Results once on the Verifier, and push these down via a YANG model to the
Attester.Contributorschgaddam@cisco.comgfedorkow@juniper.net