From: Michael Richardson <mcr+ietf@sandelman.ca>
to: "lake@ietf.org" <lake@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 05 Jun 2024 14:38:05 -0400
Message-ID: <25805.1717612685@obiwan.sandelman.ca>
Message-ID-Hash: H3Y2TR3J6NJ7JS5JU7Z7RURBFAWZY544
Precedence: list
Subject: =?utf-8?q?=5BLake=5D_evaluation_of_attestation_results_by_EDHOC_=22clients?=
	=?utf-8?q?=22?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/lake/o2oujiDacHm2m9a5y7W50oUsY7o>

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


{sorry for the length}

Yuxuan Song explained her document draft-song-lake-ra to me with the help of
Goran and Malisa.  As I said on the list before, doing remote attestation as
part of an onboarding process makes a lot of sense.
Independant of that process, there are questions.   The documents' diagram:
     https://www.ietf.org/archive/id/draft-song-lake-ra-00.html#figure-1
does map very well to the U/V/W of:
     https://www.ietf.org/archive/id/draft-ietf-lake-authz-01.html#figure-2

{I did not see before that it is proposed to carry the Evidence in message-=
3.
I thought that would be too late, and it had to go in message-1}

(Except that re-using "V" for Verifier vs JRC is a problem we should avoid.)

My contention, which I think the group agreed with, is that one probably
wants to do continuous assurance, that is, to repeat the remote attestation.

Do you want to have two protocols and two code paths? (redundant code in a
constrained device?).  I suggested that *maybe* the remote attestation shou=
ld
use it's own /.well-known Path, and that it would just occur after
onboarding, and regularly onwards.  Maybe it's weird to onboard a device on=
ly
to kick it out again immediately because it failed remote attestation, but
given continuous assurance, this could happen at any time.
Anyway, if devices are being onboarded and then failing regularly, then I
think there are other, bigger problems.  (And if the battery on the device
gets run down because of this; well... that's one fewer attacker...)

We discussed the possibility that whenever doing a subsequent remote
attestation, that it could happen as part of a PSK-based EDHOC "rekey".
I can live with that.

We also discussed the opposite situation: where a constrained device needs =
to
consider the security posture of the (edge?) compute node which is going to
collect the sensor data.   This is a far more difficult situation.

In general, the situation is that the device needs to consider the
*Attestation Results*, since there is no reasonable way a constrained device
can competently evaluate the evidence directly.  This is, unlike the above
situation, a passport model.     Somewhere a Verifier has produced the right
results.  The question in this case is how is the U-device provisioned with
the right public key with which to evaluate the results?

=2D-
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T consulti=
ng )
           Sandelman Software Works Inc, Ottawa and Worldwide

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmZgsI0WHG1jcitpZXRm
QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZdbfCACUK5eAC7P7XzCfyL2oshsraMOM
DkiDcnI+MXcIxS9WeF+tIR3bT1SNOBV8QyJLMtf8kD77Kp18y12jJin+m63R68rv
4y9bGW4Mp+uQMXGIJKW2QhjN8Vbf/XN7lUeaq2d/9vvCB76lKZkRz+vPFihmmxxZ
cZG/j8WReZ1iHBrzmZvE/KvEu5DsS5Hl2Qif+weKYk5NDog1s4DU6+8lLOA/Wq+y
ysk0Kwu8r8JNMqzS6pp764kFIK+8dKJccEwybEGSw61DXTJOEo+9nQhGEyK9m9f8
LpU2uHJe8ch6rFR2GCfi7XJ51DD7zn6BfYbLiDL1wgArnrMx3Z+HjFO6rI9d
=Ag1t
-----END PGP SIGNATURE-----
--=-=-=--