Subject: [Anima] freshness in the background check interaction model

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Jul 2021 20:41:36 -0400

In the background check interaction we assume that the Attester
has connectivity to the Relying Party, and that Relying Party will
communicate with a Verifier itself, passing Evidence along the way.

{This is not an architectural issue.  This is an issue of how to
implement RATS in a particular flow}

This could occur as part of Network Endpoint Assessment, including both
802.1X processes or onboarding such as with BRSKI (RFC8995).
(I am unclear in the TEEP case (which uses both interaction models), how this
works)

In the BRSKI case the mapping is as follows:

1) Pledge    => Attester.
2) Registrar => Relying Party.
3) MASA      => Verifier

This works well, because the MASA is associated with the manufacturer and so
it can get all the Endorsements or Reference Values by private channel.

The Pledge reaches out to the Registrar, and provides it with a Voucher-Request.
We could trivially include Evidence (or pretty much any form) in the
Voucher-Request.

The Voucher could include a reply which can be evaluated by the Registrar
(Relying Party) to provide a signal to the Registrar (they RP) as to whether
or not the Pledge (Attester)'s evidence is satisfactory.

There are some options other than embedded the answer for the (2)->(3) protocol including:
  a) use another end-point on the (3) that would return the response.
  b) use multipart/mixed reply for the reply from (3)->(2)
     [this wins for constrained case, because (1) never needs to see this]

but, the purpose of this email is to ask about how we get freshness.

Ideally, a nonce would be created by the Verifier (MASA) and transmitted to the
Attester (Pledge) via the RP (Registrar).  A challenge is that the Registrar
doesn't know which MASA to use until after it has received some communication
from the Pledge.  That comes with the Pledge's IDevID, which it uses both
to sign the Voucher-Request, and which it uses as TLS Client Certificate.

Since the TLS setup occurs before the Voucher-Request, in theory the
Registrar could retrieve a nonce from the Verifier, but in the BRSKI protocol
flow, we did not add a step to return the Nonce to the Pledge.

In the middle of writing this, a gather.town discussion occured...

A suggestion was to use a TLS Exporter to get a nonce that both the Registrar
and the Pledge knew.  The Pledge can then build it's Evidence and include
that in the (raw) Voucher-Request.   The Registrar then has to communicate this to
the MASA (Verifier)..... how do this is a question... probably in the
parboiled Voucher-request.

In the middle of this, Goran Selander brought out his slides on
draft-selander-ace-ake-authz, and most of this can be wrapped up into EDHOC.
If we can get our packets small enough, we can do AKE, Enrollment, and
Remote Attestation in three flights (two round trips).

Is it acceptable for a nonce to be created via TLS Exporter?
Is it acceptable for the nonce to be known to the RP?
Is it okay that the Verifier didn't get to insert entropy into the nonce?

All of this coming to a draft near you.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 29 Jul 2021 08:30:37 +0000

[assuming a threat model where RP and Attester do not collude, but
either could be malicious.]

On 29/07/2021, 02:42, Michael Richardson <[email-masked]> wrote:
> [...]

yes, it seems infeasible to anyone (including a mitm) to manipulate the
exporter output (and therefore the nonce) in any meaningful way.

> Is it acceptable for the nonce to be known to the RP?

yes, as long as the nonce is non-predictable -- and the construction
that you described has that property -- it is immaterial that the RP
"knows" the nonce (the nonce is a public parameter in the protocol).

> Is it okay that the Verifier didn't get to insert entropy into the

yes, if we rule out colluding RP & Attester, the freshness guarantee is
preserved even if the Verifier did not contribute to the computation of
the nonce.

my two cents, t

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 29 Jul 2021 17:28:09 +0000

To answer the question about TEEP, the example in
https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-16.5
is indeed the default (i.e., when using nonces instead of timestamps or epoch ids)
case that TEEP uses for freshness.

TEEP can also negotiate use of timestamps (in which case
https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-16.4 applies)
or epoch ids, if both sides support them.

Dave

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, July 28, 2021 5:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Rats] freshness in the background check interaction model

In the background check interaction we assume that the Attester has connectivity to the Relying Party, and that Relying Party will communicate with a Verifier itself, passing Evidence along the way.

{This is not an architectural issue.  This is an issue of how to implement RATS in a particular flow}

This could occur as part of Network Endpoint Assessment, including both 802.1X processes or onboarding such as with BRSKI (RFC8995).
(I am unclear in the TEEP case (which uses both interaction models), how this
works)

1) Pledge    => Attester.

This works well, because the MASA is associated with the manufacturer and so it can get all the Endorsements or Reference Values by private channel.

The Pledge reaches out to the Registrar, and provides it with a Voucher-Request.
We could trivially include Evidence (or pretty much any form) in the Voucher-Request.

The Voucher could include a reply which can be evaluated by the Registrar (Relying Party) to provide a signal to the Registrar (they RP) as to whether or not the Pledge (Attester)'s evidence is satisfactory.

Ideally, a nonce would be created by the Verifier (MASA) and transmitted to the Attester (Pledge) via the RP (Registrar).  A challenge is that the Registrar doesn't know which MASA to use until after it has received some communication from the Pledge.  That comes with the Pledge's IDevID, which it uses both to sign the Voucher-Request, and which it uses as TLS Client Certificate.

Since the TLS setup occurs before the Voucher-Request, in theory the Registrar could retrieve a nonce from the Verifier, but in the BRSKI protocol flow, we did not add a step to return the Nonce to the Pledge.

A suggestion was to use a TLS Exporter to get a nonce that both the Registrar and the Pledge knew.  The Pledge can then build it's Evidence and include
that in the (raw) Voucher-Request.   The Registrar then has to communicate this to
the MASA (Verifier)..... how do this is a question... probably in the parboiled Voucher-request.

In the middle of this, Goran Selander brought out his slides on draft-selander-ace-ake-authz, and most of this can be wrapped up into EDHOC.
If we can get our packets small enough, we can do AKE, Enrollment, and Remote Attestation in three flights (two round trips).

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C4dbc5796d82a44c6466308d95229af30%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637631161721316112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=mK8Jyrn0N7pehFvHxgJBDAL0p3%2FxjWcBi13Vbrv%2Fy2Q%3D&amp;reserved=0        |   ruby on rails    [