From dd9b0f3827d751bd5a3aaea6b7ec11f87c7d1e78 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sat, 20 Jul 2024 21:26:33 +0200 Subject: [PATCH 1/7] Addressing Hannes comment on Nonces --- draft-ietf-rats-reference-interaction-models.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 21ecb32..0d6b5e6 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -252,9 +252,9 @@ Handle ('handle'): : *mandatory* -: A statement that is intended to uniquely distinguish received Evidence and/or determine the freshness of Evidence. +: A statement provided to the Attester from the outside to be included in Evidence (or other RATS Conceptual Messages) to determine recentness, freshness, or to protect against replay attacks. -: A Verifier can also use a Handle as an indicator for authenticity or attestation provenance, as only Attesters and Verifiers that are intended to exchange Evidence should have knowledge of the corresponding Handles. Examples include Nonces or signed timestamps. +: Handle is an umbrella term for existing data types that accomplish one or more of (a) determining recentness, (b) determining freshness, or (c) provide replay protection. Examples include: Nonces that are used to protect from replay attacks or Epoch Markers that identify distinct period (Epoch) of freshness {{-epoch-markers}}. Handles can also be used as an indicator for authenticity or attestation Evidence provenance, as only a select number of RATS Roles (e.g., an Attester and a Verifier in a challenge-response interaction) are intended to have knowledge of a current Handle. Claims ('claims'): From 4ea1bdff0c004f23648902eca5808780ed07ec54 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sat, 20 Jul 2024 21:34:06 +0200 Subject: [PATCH 2/7] fixed epoch marker ref --- draft-ietf-rats-reference-interaction-models.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 0d6b5e6..1bf3c73 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -52,6 +52,7 @@ normative: BCP205: RFC7942 RFC8610: CDDL RFC9334: RATS + I-D.birkholz-rats-epoch-markers: epoch-markers informative: I-D.ietf-rats-tpm-based-network-device-attest: RIV From c78033f53b5393118762fa71e892562ae08f6c1f Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sat, 20 Jul 2024 21:37:23 +0200 Subject: [PATCH 3/7] Clarifying the optional use of Claim Selection --- draft-ietf-rats-reference-interaction-models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 1bf3c73..9cc1096 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -283,7 +283,7 @@ Claim Selection ('claimSelection'): : A (sub-)set of Claims which can be created by an Attester. -: Claim Selections act as filters to specify the exact set of Claims to be included in Evidence. In a remote attestation process, a Verifier sends a Claim Selection, among other elements, to an Attester. An Attester MAY decide whether or not to provide all requested Claims from a Claim Selection to the Verifier. +: Claim Selections act as optional filters to specify the exact set of Claims to be included in Evidence. For example, a Verifier could send a Claim Selection, among other elements, to an Attester. An Attester MAY decide whether or not to provide all requested Claims from a Claim Selection to the Verifier. If there is no way to convey a Claim Selection in a remote attestation protocol, a default Claim Selection (e.g., "all") MUST be defined be the Attester and SHOULD be known to the Verifier. Collected Claims ('collectedClaims'): From 00df567145ff1a545d169d1048bc81e68f28dc6c Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sat, 20 Jul 2024 22:01:16 +0200 Subject: [PATCH 4/7] Transitioning from Authentication Secret ID to Attestation Key ID --- ...-ietf-rats-reference-interaction-models.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 9cc1096..7fb0e3f 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -240,14 +240,14 @@ This section defines the information elements that are vital to all kinds intera Varying from solution to solution, generic information elements can be either included in the scope of protocol messages (instantiating Conceptual Messages) or can be included in additional protocol parameters or payload. Ultimately, the following information elements are required by any kind of scalable remote attestation procedure using one or more of the interaction models provided. -Authentication Secret IDs ('authSecIDs'): +Attestation Key IDs ('authSecIDs'): -: *mandatory* +: *optional* -: A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence. +: A statement representing an identifier list that MUST be associated with corresponding Attestation Keys (authentication secrets) used to protect Claims in Evidence produced by Attesting Environments of an Attester. -: Each distinguishable Attesting Environment has access to a protected capability that provides an Authentication Secret associated with that Attesting Environment. -Consequently, an Authentication Secret ID can also identify an Attesting Environment. +: Each distinguishable Attesting Environment has access to a protected capability that includes an Attestation Key (Authentication Secret). +Consequently, an Attestation Key ID can also identify an Attesting Environment. Handle ('handle'): @@ -331,12 +331,12 @@ The way these handles are processed is the most prominent difference between the generateClaims(attestingEnvironment) | | => claims, eventLogs | | | - |<--- requestAttestation(handle, authSecIDs, claimSelection) | + |<--- requestAttestation(handle, attKeyIDs, claimSelection) | | | collectClaims(claims, claimSelection) | | => collectedClaims | | | - generateEvidence(handle, authSecIDs, collectedClaims) | + generateEvidence(handle, attKeyIDs, collectedClaims) | | => evidence | | | | evidence, eventLogs -------------------------------------->| @@ -398,13 +398,13 @@ then gives back an Attestation Result to the Attester, which simply caches it. I | => claims, eventLogs | | | | | |<--------------------- requestAttestation(handle, | - | authSecIDs, claimSelection) | + | attKeyIDs, claimSelection) | | | | collectClaims(claims, claimSelection) | | | => collectedClaims | | | | | generateEvidence(handle, | | - authSecIDs, collectedClaims) | | + attKeyIDs, collectedClaims) | | | => evidence | | | | | | {evidence, eventLogs} -------------->| | @@ -444,7 +444,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p =================[Evidence Generation and Conveyance]=================== | | | |<--------------------- requestAttestation(handle, | - | authSecIDs, claimSelection) | + | attKeyIDs, claimSelection) | | | | generateClaims(attestingEnvironment) | | | => {claims, eventLogs} | | @@ -454,7 +454,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | => collectedClaims | | | | | generateEvidence(handle, | | - authSecIDs, collectedClaims) | | + attKeyIDs, collectedClaims) | | | => evidence | | | | | | {evidence, eventLogs} ----------->| | @@ -501,7 +501,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p collectClaims(claims, claimSelection) | | => collectedClaims | | | - generateEvidence(handle, authSecIDs, collectedClaims) | + generateEvidence(handle, attKeyIDs, collectedClaims) | | => evidence | | | | {evidence, eventLogs} ------------------------------------>| @@ -524,7 +524,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | collectClaims(claimsDelta, claimSelection) | | | | => collectedClaimsDelta | | | | | | -| generateEvidence(handle, authSecIDs, collectedClaimsDelta) | | +| generateEvidence(handle, attKeyIDs, collectedClaimsDelta) | | | | => evidence | | | | | | | | {evidence, eventLogsDelta} ------------------------------->| | @@ -580,7 +580,7 @@ In the following Subsections, streaming remote attestation without a broker (obs | generateHandle() | handle<= | | | - |<------------ subscribe(handle, authSecIDs, claimSelection) | + |<------------ subscribe(handle, attKeyIDs, claimSelection) | | {handle} ------------------------------------------------->| | | =================[Evidence Generation and Conveyance]=================== @@ -591,7 +591,7 @@ In the following Subsections, streaming remote attestation without a broker (obs collectClaims(claims, claimSelection) | | => collectedClaims | | | - generateEvidence(handle, authSecIDs, collectedClaims) | + generateEvidence(handle, attKeyIDs, collectedClaims) | | => evidence | | | ==========================[Evidence Appraisal]========================== @@ -614,7 +614,7 @@ In the following Subsections, streaming remote attestation without a broker (obs | collectClaims(claimsDelta, claimSelection) | | | | => collectedClaimsDelta | | | | | | -| generateEvidence(handle, authSecIDs, collectedClaimsDelta) | | +| generateEvidence(handle, attKeyIDs, collectedClaimsDelta) | | | | => evidence | | | | | | | =====================[Delta Evidence Appraisal]===================== | @@ -742,7 +742,7 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top | collectClaims(claims, claimSelection) | | | | | => collectedClaims | | | | | | | | -| generateEvidence(handle, authSecIDs, | | | +| generateEvidence(handle, attKeyIDs, | | | | | collectedClaims) | | | | | => evidence | | | | | | | | From 2e56d7dc9d242164a33429e2ced85dadabe69468 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sat, 20 Jul 2024 22:15:29 +0200 Subject: [PATCH 5/7] polished wording on Attestation Key Knowledge --- draft-ietf-rats-reference-interaction-models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 7fb0e3f..a4765ce 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -246,7 +246,7 @@ Attestation Key IDs ('authSecIDs'): : A statement representing an identifier list that MUST be associated with corresponding Attestation Keys (authentication secrets) used to protect Claims in Evidence produced by Attesting Environments of an Attester. -: Each distinguishable Attesting Environment has access to a protected capability that includes an Attestation Key (Authentication Secret). +: While a verifier does not necessarily has knowledge about an Attesting Environment's Attestation Key (ID), each distinguishable Attesting Environment has access to a protected capability that includes an Attestation Key (Authentication Secret). Consequently, an Attestation Key ID can also identify an Attesting Environment. Handle ('handle'): From bf1ddff771f7805949e30926e407c99b58b183e9 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sat, 20 Jul 2024 22:32:20 +0200 Subject: [PATCH 6/7] Update draft-ietf-rats-reference-interaction-models.md Co-authored-by: Henk Birkholz Co-authored-by: Hannes Tschofenig Co-authored-by: Hannes Tschofenig --- draft-ietf-rats-reference-interaction-models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index a4765ce..4a36077 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -246,7 +246,7 @@ Attestation Key IDs ('authSecIDs'): : A statement representing an identifier list that MUST be associated with corresponding Attestation Keys (authentication secrets) used to protect Claims in Evidence produced by Attesting Environments of an Attester. -: While a verifier does not necessarily has knowledge about an Attesting Environment's Attestation Key (ID), each distinguishable Attesting Environment has access to a protected capability that includes an Attestation Key (Authentication Secret). +: While a verifier does not necessarily have knowledge about an Attesting Environment's Attestation Key (ID), each distinguishable Attesting Environment has access to a protected capability that includes an Attestation Key (Authentication Secret). Consequently, an Attestation Key ID can also identify an Attesting Environment. Handle ('handle'): From 0f7b79bde28a4d25573b518cd4a95d09dc2ffc18 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sat, 20 Jul 2024 22:47:26 +0200 Subject: [PATCH 7/7] Update draft-ietf-rats-reference-interaction-models.md --- draft-ietf-rats-reference-interaction-models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 4a36077..50164ef 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -255,7 +255,7 @@ Handle ('handle'): : A statement provided to the Attester from the outside to be included in Evidence (or other RATS Conceptual Messages) to determine recentness, freshness, or to protect against replay attacks. -: Handle is an umbrella term for existing data types that accomplish one or more of (a) determining recentness, (b) determining freshness, or (c) provide replay protection. Examples include: Nonces that are used to protect from replay attacks or Epoch Markers that identify distinct period (Epoch) of freshness {{-epoch-markers}}. Handles can also be used as an indicator for authenticity or attestation Evidence provenance, as only a select number of RATS Roles (e.g., an Attester and a Verifier in a challenge-response interaction) are intended to have knowledge of a current Handle. +: Handle is an umbrella term for existing data types that accomplish one or more of (a) determining recentness, (b) determining freshness, or (c) provide replay protection. Examples include: Nonces that are used to protect from replay attacks or Epoch Markers that identify distinct periods (Epoch) of freshness {{-epoch-markers}}. Handles can also be used as an indicator for authenticity or attestation Evidence provenance, as only a select number of RATS Roles (e.g., an Attester and a Verifier in a challenge-response interaction) are intended to have knowledge of a current Handle. Claims ('claims'):