Re: [Teep] [Rats] Multiple attesters and verifiers

[Laurence Lundblade <[e-mail]>]

> On Aug 12, 2019, at 10:01 AM, Smith, Ned <[e-mail]> wrote:
> 
> See inline [nms]
> 
> On 8/10/19, 11:21 AM, "RATS on behalf of Laurence Lundblade" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    I think there are elaborate deployments that involve multiple attesters and verifiers. Ned has been bringing these up. The architecture needs to cover these. That said, I prefer us to get straight on the simpler case with one of each. 
> 
>    To go on a bit further.
> 
>    You could have:
> [nms] Is this example intended to follow one of the RATS use cases or perhaps one of the TEEP interaction scenarios?

Neither. Just something I imagined. I think concrete example are really helpful.

> 
>       Attester —(IPC)— > Attester —(TCP/IP) — > Verifier —(in same process) — > Attester —(TCP/IP) — > Verifier —(HTTPS/TCP/IP)— > RP
> 
> [nms-block] To break this down even further:

Everything you say below generally makes sense to me.


> Attester1 presumably signs Evidence1 with Key1 and includes a Nonce1 from Verifier1
> 
> Attester2 presumably signs Evidence2 (which presumably contains Evidence1) with Key2 and includes a Nonce2(?) from Verifier1 - or it could have used Nonce1. 
> 
> Note: there is an interesting question related to Evidence freshness. (i) reply attack prevention and (ii) time since the state described by the Evidence was extant. This relates to Ira McDonalds comment in a different thread - "It's only the *current* state of the Attester's device or application that's actually useful." Regarding (i) given multiple attesters on the same device MUST / SHOULD Evidence be signed in response to a request or can Evidence be pre-signed in anticipation of receiving one or more requests? The TUDA draft possibly addresses this differently than using a requester supplied nonce. (ii) Evidence freshness also relates to how recently the trustworthiness state was tested / measured. For example, 5 requests using Nonce1 - Nonce5 could all be returning the same historical Evidence. 
> 
> Verifier1 and Attester3 (are in the same process - or what the architecture draft abstracts as "actor"). Verifier 1 presumably has a Policy1 of known-good / whitelist / blacklist values that informs how to produce a Result1 that consists of "verified Claims". Attester3 possibly includes new Claims that are packaged as Evidence3.  Result1 and Evidence3 are sent to Verifier2. 
> 
> Verifier2 appears to also be a Relying Party-RP1 since Result1 is being sent to it from Attester3.
> 
> Verifier2 to produce Result2 using Policy2 which is sent to RP2.
> RP2 presumably evaluates Result2 using a risk management policy (Policy3).
> 
> Possibly the use case can be summarized as follows (which is isomorphic to Laurence's original expression):
> Notation: ()Kx - signing using Kx
> 0)Verifier 1 sends Nonce1 and Nonce2 to Attester1 and Attester2 respectively. Verifier2-RP1 sends Nonce3 to Verifier1-Attester3. RP2 sends Nonce4 to Verifier2-RP1.
> 1) Attester1: (Evidence1, Nonce1)K1 —(IPC)— > Attester2
> 2) Attester2: ((Evidence1, Nonce1)K1, Evidence2, Nonce2)K2 —(TCP/IP) — > Verifier1-Attester3 (Note: Verifier1 and Attester3 are roles on the same actor)
> 3) Verifier1: Evaluates payload using Policy1 to produce (Result1, Nonce3)K3
> 4) Attester3: Creates (Evidence3, Nonce3)K3
> 5) Verifier1-Attester3: (Result1, Evidence3, Nonce3)K3 —(TCP/IP) — > Verifier2-RP1 (Note: Again two roles belonging to the same actor)
> 6) Verifier2: Evaluates payload Evidence3 using Policy2 to produce (Result2a, Nonce4)K4
> 7) RP1: Evaluates payload Result1 using Policy2 to produce (Result2b, Nonce4)K4 and/or takes some action.
> 8) Verifier2-RP1: (Result2, Nonce4)K4 —(HTTPS/TCP/IP)— > RP2
> 9) RP2: Evaluates Result2 using Policy3 and takes some action.
> [block-NMS]
> 
>    The first two attesters are on the entity / device that is the subject of the attestation. This would probably look like nested EAT tokens. 
> [nms] An important question is which key(s) are used to sign each Attester's Evidence and each Verifier's Results. Does EAT token nesting support multiple signatures and keys? Can EAT tokens distinguish between Evidence and Results?
> 
>    The first verifier is a service that might broker attestation from multiple entity / device vendors. It outputs an EAT token that has made some implied claims explicit and perhaps checked some claims against known-good-values.
> [nms] There could be a semantic difference between evaluated claims vs. attested claims. The architecture draft would argue that RP may ONLY process claims from a Verifier. If the payload contains claims from an attester there must be a Verifier co-resident with the RP. Additionally, claims from a verifier may be entirely different claims from those supplied to it by attesters. This is why the architecture distinguishes between Evidence and Results. Both could be expressed as sets of claims (IMO).
> 
>    The second verifier is the one that really relates to the relying party.
> 
>    Sometimes the connections are internal to a computing device, in which case the trust and security are provided by the local OS.
> 
>    Sometimes the connections are over IP in which case the claims are likely secured by being in a EAT.
> [nms] The architecture draft tries to distinguish these two cases as local conveyance. Local conveyance is internal to the Actor environment. Local conveyance isn't interesting to "Remote Attestation". 
> 
>    In the last link in the example, the result is secured by HTTPS and is probably internal to the RP.
> [nms] I'm not sure if you are suggesting the last conveyance instance (step 8) is local or remote. 
> 
>    LL
> 
> 
> 
> 
>    _______________________________________________
>    RATS mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/rats
> 
>