Trusted Path Routing using Remote AttestationCisco Systems, Inc.evoit@cisco.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. This specification describes two alternatives for protecting these sensitive flows as they transit a network. In both alternatives, protection is accomplished by forwarding sensitive flows across network devices currently appraised as trustworthy.There 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.With the inclusion of cryptoprocessor hardware into network devices, it is now possible for network providers to identify those network devices which have potentially exploitable or even exploited vulnerabilities. Using this knowledge, it then becomes possible to redirect sensitive flows around these potentially compromised devices.This specification describes two architectural alternatives for exchanging traffic with end-user customer identified “sensitive subnets”. Traffic going to and from these subnets will transit a path where the IP layer and above are only interpretable by those network devices recently evaluated as trustworthy. These two architectural alternatives are:Centralized Trusted Path Routing – For sensitive subnets, trusted end-to-end paths are pre-assigned through a network provider domain. Along these paths, attestation evidence of potentially transited components has been assessed. Each path is guaranteed to only include devices meeting the needs of a formally defined trustworthiness level.Distributed Trusted Path Routing – Through the exchange of attestation evidence between peering network devices, a trusted topology is established and maintained. Only devices meeting the needs of a formally defined trustworthiness level are included as members of this topology. Traffic exchanged with sensitive subnets is forwarded into this topology.Beyond the definition of these two architectural alternatives, incremental technology enhancements needed for each are also specified within this document. The specification works under the assumptions that cryptoprocessors capable of supporting or interface specifications are available on each network device, and the device supports the concepts of remote attestation laid out in .The following terms are imported from :
Attester, Composite Evidence, Evidence, Passport, Relying Party, and Verifier.The following terms at imported from : Event Stream.Newly defined terms for this document:
a device where a Verifier’s most recent appraisal of attestation evidence has successfully met the criteria for a specific Trustworthiness Level. Attested Devices cannot be appraised as unverified or compromised.
an IP address range where IP packets to or from that range must only have their IP headers and encapsulated payloads accessible/visible only by Attested Devices.
a network device within an IGP domain where any packets passed into that IGP domain are completely opaque at Layer 3 and above.
A topology which includes only Attested Devices and Transparently-Transited Devices.
a specific grade of trust earned by a device. The grade for a device is assigned by a Verifier during the appraisal process and can be returned within Attestation Results. Example levels include boot-verified, unverified and compromised. (Note: significant discussion will be needed to agree on definitions of these levels.)The 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.With this architectural alternative, a controller-based Verifier ensures communications with Sensitive Subnets traverses a Trusted Topology within the controller’s IGP domain. To do this, the Verifier continuously acquires Evidence about each potentially transited device. This access is done via the context established within . The controller then appraises all available Evidence and decides on a Trustworthiness Level for each device. Using the set of all appraisals, the controller identifies end-to-end path(s) which avoid any devices with an insufficient Trustworthiness Level. Finally, the controller provisions Sensitive Subnets to use just these end-to-end paths.Evidence passed to the Verifier which are used to establish a device’s Trustworthiness Level will include but is not limited to:An Attester’s security measurements being extended into or compliant Platform Configuration Registers (PCR).An Attester’s current PCR measurements.It is the consideration of all Evidence which allows the establishment and maintenance of a Trustworthiness Level. Note that it is outside the scope of this specification to include algorithms for determining a Trustworthiness Level.The prerequisites for this solution are:Customer designated Sensitive Subnet ranges and their demanded Trustworthiness Levels have been identified and associated with external interfaces to/from the edge of an IGP domain.A Verifier which can continuously acquire Evidence and appraise the Trustworthiness Levels of all network devices within the IGP domain.A Verifier which continuously optimizes a set of network paths/tunnels. These paths must traverse only Attested Devices or Transparently-Transited Devices while on their way to an egress interface for an IGP Domain.A Verifier which can provision and maintain the set of Sensitive Subnets associated with specific network paths/tunnels. provides a network diagram of where these four sit within a network topology.The feature functionality describing how to achieve (1), (3), and (4) are outside the scope of this specification. The reasoning is that each of these can be accomplished via existing standard-based or standards-track technologies. For example, in step (4), it is possible for a Verifier to provision each ingress device with the set of Sensitive Subnets for which traffic would be placed into a specific tunnel.The new requirements which need to be supported for this specification come from prerequisite (2). To accomplish prerequisite (2), it is necessary for each network device to stream changes in Evidence to a Verifier. This can be accomplished by the Verifier establishing an subscription to the <attestation> Event Stream described in below within this document.With this new <attestation> Event Stream, a Verifier can consume and continuously determine the Trustworthiness Level of various network devices within the IGP domain. Maintaining this information allows the Controller to calculate an appropriate network path (3).With this architectural alternative, Composite Evidence is assembled into a passport by the Attester network device. Upon receiving this passport as part of link layer authentication credentials, a peer Relying Party decides if this Attester is trustworthy enough to be an Attested Device. It also appraises its Trustworthiness Level. If found trustworthy, the relevant link is included into any Trusted Topologies capable of supporting that Trustworthiness Level.When enough links have been included, a Trusted Topology will now exist for a specified Trustworthiness Level. And traffic exchanged with Sensitive Subnets can be forwarded into that Trusted Topology from all edges of an IGP domain.Critical to the establishment and maintenance of a Trusted Topology is the passport. Within the passport, Composite Evidence is continuously exchanged between peering network devices over a link layer protocol. This provides a protocol independent process for passport generation and evaluation. later in the document binds the passport to specific link layer protocols, YANG models, and authentication methods.The composite nature of the passport exposes multiple dimensions of an attesting router’s security posture to a network peer. Specifically, using capabilities defined as part of either the TCG or specifications, the following can be established about the Attester:its hardware-based identity,the Trustworthiness level according to its most recent Verifier appraisal,the amount of time which has passed since the Attester has been at a Trustworthiness Level, andif the PCRs haven’t changed, the Attester’s current Trustworthiness LevelWith this information, the Relying Party peer can make nuanced decisions. For example, when the Attester’s legitimate hardware identity credentials can be verified, it might choose to accept link layer connections and forward generic Internet traffic. Additionally, if the Attester’s Trustworthiness Level is acceptable, and it hasn’t been too long since the Trustworthiness Level was examined by a Verifier, the Relying Party can include that link in a Trusted Topology.As the process described above repeats across the set of links within the IGP domain, Trusted Topologies can be extended and maintained. Traffic to and from Sensitive Subnets is then identified at the edges of the IGP domain and passed into this Trusted Topology.The prerequisites for this solution to work are:Customer designated Sensitive Subnets and their requested Trustworthiness Levels have been identified and associated with external interfaces to/from the edge of an IGP domain.A Trusted Topology such as one established by exists in an IGP domain for the forwarding of Sensitive Subnet traffic. This Topology will carry traffic of a Trustworthiness Level.Verifiers A and B are able to verify or signatures of an Attester.Verifier A can establish the Trustworthiness Level of an Attester and return a signed result to that Attester.An Attester can assemble a passport of Composite Evidence for Verifier B.Verifier B trusts the Attestation Results and can verify signatures made by Verifier A.Within an IGP domain, a Relying Party is able to use affinity to include/exclude links as part of the Trusted Topology based on this appraisal.Traffic to a Sensitive Subnet can be passed into the Trusted Topology.In above, Evidence from a TPM1.2 or TPM2.0 is generated and signed by that TPM. This Evidence is appraised by Verifier A, and the Attester is given a Trustworthiness Level which is signed and returned as Attestation Results to the Attester. Later, when a request comes in from a Relying Party, the Attester assembles and returns three independently signed elements of Evidence. These three comprise the Composite Evidence which when taken together allow Verifier B to appraise the current Trustworthiness Level of the Attester.More details on the mechanisms used in the construction and verification of the passport match to the numbered steps of :An Attester sends a signed TPM Quote which includes PCR measurements to Verifier A at time(x).Verifier A appraises (1), then sends the following items back to that Attester as Attestation Results: the appraised Trustworthiness Level of an Attester,the signature from the TPM Quote of (1),a Verifier signature across (2.1) and (2.2).A nonce known to the Relying Party is received by the Attester at time(y).The Attester generates and sends a passport. The encapsulated Composite Evidence includes: (1)(2)New signed, verifiably fresh PCR measurements at time(y), which incorporates the nonce from (3).On receipt of (4), the Relying Party makes its determination of how the Composite Evidence will impact adjacencies within a Trusted Topology. The decision process is: Verify that (4.3) includes the nonce from (3).Verify the TPM signature within (4.2) matches the signature of (4.1).Validate the signatures of (4.1), (4.2), (4.3).Failure of (5.1), (5.2), or (5.3) means the link should be assigned a <compromised> Trustworthiness Level, and additionally jump to step (5.8).If selected PCR values of (1) match (4.3), then Relying Party can accept (2.1) as the link’s Trustworthiness Level.When the PCR values are different, and not much time has passed between time(x) and time(y), the Relying Party can either accept any previous Trustworthiness Level, or attempt to acquire a new passport. In many cases, it should only be a few seconds before a new Attestation Results should be delivered to an Attester via (2).When the PCR values are different, but there is a large time gap between time(x) and time(y), the link should be assigned an <unverified> Trustworthiness Level.Based on the link’s Trustworthiness Level, add or remove it from the appropriate Trusted Topology.The <attestation> Event Stream is an complaint Event Stream which is defined within this section and within the YANG Module of . The Event Stream contains YANG notifications which carry Evidence which assists a Verifier in appraising the Trustworthiness Level of an Attester. Data Nodes allow the configuration of this Event Stream’s contents on a particular Attester.This <attestation> Event Stream may only be exposed on Attesters capable of signing cryptoprocessor PCRs using a private key unavailable elsewhere within the Attester. There is not a requirement that the underlying cryptoprocessor of the Attester has undergone TCG certification.To establish the subscription in a way which results in provably fresh Evidence, randomness must be provided to the Attester. One way this can be done for an dynamic subscriptions is via the augmentation of the <establish-subscription> RPC:As part of the response to the <establish-subscription>, a YANG notification defined in this document is retuned. This notification MUST incorporate the randomness provided by the <nonce-value>. By including this YANG notification in the response, critical measurements are delivered in a way which provides protection against replay attacks. Additionally, the Verifier has immediate access to current measurements.It is also possible to subscribe to the <attestation> Event Stream via an configured subscription. In this case the Verifier needs some proof of Evidence freshness. Where a TPM2 exists, this may be accomplished via the creation and exposure of a Sync-Token as described in . For any type of TPM, centrally created nonces could by signed, and broacast to both the Attester and Verifier.This notification is generated every time a PCR is extended within a cryptoprocessor. The notification contains a list of the one or more strings which have extended a PCR.All notifications since boot MUST be retained, and replayable.This notification contains an instance of a TPM1.2 style signed cryptoprocessor measurement. It is supplemented by Attester information which is not signed. This notification is generated and emitted from an Attester every time at least one PCR identified within the <pcr-list> has changed from the previous <tpm12-attestation> notification:The vast majority of the YANG objects above are defined within . As a result, these objects are not redefined in this draft. The objects which are new include:pcr-index-changed* – this is a list of a PCRs which have new values since the last <tpm12-attestation> notification.pcr-index-attested* – this is a list of all the PCRs contained in the <tpms-attest-result>.Only the most recent <tpm12-attestation> is replayable. All others are discarded from the Event Stream history.Note that this notification alone does not fully handle replay attack protection for Centralized Trusted Path Routing. As a result, a Verifier MUST periodically receive a nonce based TPM1.2 style quote response. This can be done in several ways including via the <tpm12-challenge-response-attestation> RPC specified in . This periodic query allows a synching on the freshness of the results. Such a periodic synching is not required for the Distributed Trusted Path Routing architecture as the nonce based quote at time(y) proves the freshness of every passport.This notification contains an instance of TPM2 style signed cryptoprocessor measurements. It is supplemented by Attester information which is not signed. This notification is generated at two points in time:every time at least one PCR has changed from a previous tpm20-attestation.after a locally configurable minimum heartbeat period since a previous tpm20-attestation was sent. This heartbeat is identifiable as the <pcr-index-changed> will be missing from the notification. As a result, there is no need to match it to one or more <tpm-extend> notifications.Only the most recent <tpm20-attestation> is replayable. All others are discarded from the Event Stream history.Note that does not yet include the full set of objects. As soon as is updated with the necessary information, a new version of this draft will include a tree diagram which identifies those objects within this notification.It is possible for a receive just those PCR changes of interest from an Attester. To accomplish this, a RFC8639 <establish-subscription> RPC is made against the <attestation> Event Stream. To limit the set of notifications, a <stream-filter> as per RFC8639, Section 2.2 can be set to select the following:each <tpm-extend> containing a <pcr-index-changed> of a desired PCReach <tpm12-attestation> containing a <pcr-index-changed> of a desired PCReach <tpm20-attestation> containing a <pcr-index-changed> of a desired PCRTo verify the value of a PCR, a Verifier must either know that the value is a known good value or be able to reconstruct the hash value by viewing all the PCR-Extends since the Attester rebooted. Wherever a hash reconstruction might be needed, the <attestation> Event Stream MUST support the RFC8639 <replay> feature. Through the <replay> feature, it is possible for a Verifier to retrieve and sequentially hash all of the PCR extending events since an Attester booted. And thus, the Verifier has access to all the evidence needed to verify a PCR’s current value. is tree diagram which exposes the configurable elements of the <attestation> Event Stream. This allows an Attester to select what information should be available on the stream. A fetch operation also allows an external device such as a Verifier to understand the current configuration of stream.The majority of the YANG objects below are defined via reference from .There is one object which is new with this model however. <tpm2-heartbeat> defines the maximum amount of time which should pass before a subscriber to the event stream should get a <tpm20-attestation> notification from devices which contain a TPM2.If there is no configuration of any <tpm-name> information within this model, all subscriptions should be rejected with an reason of <stream-unavailable>.This YANG module imports modules from and . It is also work-in-progress.This section provides details of how Composite Evidence described in interacts with link layer protocols like or , YANG subscriptions , and methods. Additional linkages to the YANG module defined in are described. above expands upon the previously described . The numbering in both figures is the same.Step (1)Verifier A subscribes to an Attester’s <attestation> Event Stream on via . Within the <establish-subscription> RPC, a nonce is delivered as per . This nonce then is included into TPM quotes requests driven for the Attester’s cryptoprocessor. The result of the TPM quote is appended to the <establish-subscription> response. Following this delivery of a provably current TPM state, all the historical evidence needed to validate specific PCRs within this quote are delivered on the <attestation> Event Stream via the <replay> feature. Any changes to PCRs results in new notifications as described in . These are continuously streamed to Verifier A.Step (2)Whenever a PCR changes, Verifier A evaluates the totality of the Evidence received. This Evidence may include information not provided on the <attestation> Event Stream. Verifier A then decides the Trustworthiness Level of the Attester. Subsequently it sends back a signed Attestation Result which includes the Trustworthiness Level and the signature sent as part of (1) from the Attester. It is this signature which allows the Trustworthiness Level to be later provably associated with a recent TPM Quote.The delivery of Attestation Results back to the Attester can be done via a YANG operational datastore write of the following objects:Step (3)At time(y) a Relying Party makes a Link Layer connection request to an Attester via a protocol such as or . This connection request must include credentials. Specifics of the EAP credentials are TBD. If there is no central distribution of time via a nonce must be included to ensure freshness of a response.This step can repeat periodically independently of any subsequent iteration (1) and (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 (4)Upon receipt of (3), a passport is generated as per , and sent to the Relying Party.Step (5)Upon receipt of (4), the Relying Party verifies the Composite Evidence as per . Most often, the relevant PCR values at time(x) will be the same as the PCR values at time(y). In this case, the Relying Party can simply accept the Trustworthiness Level assigned by the Verifier A. When the PCR values are different, and not much time has passed between time(x) and time(y), the Relying Party can either accept the previous Trustworthiness Level, or attempt another EAP request in a few seconds as new Attestation Results are delivered by Step (2). When there is a large time gap between time(x) and time(y) and the PCR values are different, the Attester should be given an <unverified> Trustworthiness Level.Based on the link’s Trustworthiness Level, the Relying Party may adjust the link affinity of the corresponding topology.Successful attacks on an IGP domain Verifier has the potential of affecting traffic on the Trusted Topology.For Distributed 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 passport to become a denial of service vector.Subscription to YANG NotificationsThis document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.TPM 1.2 Main SpecificationTPM 2.0 Library SpecificationRemote Attestation Procedures ArchitectureIn network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence. The evidence is typically a set of claims about its software and hardware platform. This document describes an architecture for such remote attestation procedures (RATS).A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMsKey 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.Extensible 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]Advertising Segment Routing Policies in BGPThis document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing (SR) Policy. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute SR Policy candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined for signaling information about these candidate paths.Time-Based Uni-Directional AttestationThis documents defines the method and bindings used to conduct Time- based Uni-Directional Attestation (TUDA) between two RATS (Remote ATtestation procedureS) Principals over the Internet. TUDA does not require a challenge-response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence. Conversely, TUDA enables the creation of Secure Audit Logs that can constitute Evidence about current and past operational states of an Attester. As a prerequisite for TUDA, every RATS Principal requires access to a trusted and synchronized time-source. Per default, in TUDA this is a Time Stamp Authority (TSA) issuing signed Time Stamp Tokens (TST).IGP Flexible AlgorithmIGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to enforce traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document proposes 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 VerificationJuniper Networks802.1AE: MAC Security (MACsec)802.1AE: MAC Security (MACsec)KGVShwetha Bhandari, Henk Birkholz, Chennakesava Reddy Gaddam, Sujal Sheth, Peter Psenak, Nancy Cam Winget, Siva Sivabalan, Ned Smith, Guy Fedorkow, Liang Xia.[THIS SECTION TO BE REMOVED BY THE RFC EDITOR.]v00-v01Move all FlexAlgo terminology to . This allows to be more generic.Edited Figure 1 so that (4) points to the egress router.Added text freshness mechanisms, and articulated configured subscription support.Minor YANG model clarifications.Added a few open questions which Frank thinks interesting to work.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.Deep discussions on the Trustworthiness Levels which need standardization. Perhaps these could be mapped to the “Figure 2: Attested Objects” from .Should the “extended-with” object support a choice of structured data, or should it be binary only.Should we have multiple attestation streams identified? E.g.: pcr-trust-evidence, bios-log-trust-evidence, and ima-log-trust-evidence? Should each stream have its own draft?Should we include define how to acquires attestation-certificates. Perhaps through something like draft-ietf-netconf-keystore?