[Secret] related works and problems

[Michael Richardson <[e-mail]>]

The meeting is just beginning, but I've browsed the slides with the use
cases.   When I read the document quickly this morning, I got the impression
that what was going to be transfered was the credential *itself*

That is, I thought that this was primarily about sharing my
credentials among my devices.  Specifically, when I replace my phone and I
have credentials hidden inside a TEE, that I could transfer them to my new
phone, or my tablet.  (New phone yesterday.... fortunately my old phone isn't
dead yet, just unable to keep a charge very long even with new battery, but I
still have to 2FA into every site I use Authenticator for and setup a new 2FA)

Another use case that I care about is backup: my phone could get destroyed
and I need to restore the credentials from a backup.

Then I read the use cases, and learnt that this is really about delegation,
and then it seemed like this was about, essentially, sharing a
password/private-key, and I got very concerned.

As the session clarified, this is about delegating to another key pair
(generated by the sender), and we need to transfer access to *that* keypair
to the receiver.  We need to do it this way because we don't want an extra
round trip to ask the receiver for their public key.

I guess that some CCC credential protocol exists that supports delegation
with constraints.  I didn't know CCC was working on that.
I don't think that any of this can work without the replying party (the hotel
door, the car, the house door) supporting the delegation protocol.  As such
it really is very specific to those delegation protocols.

Almost all of the topics discussed in this have been discussed in the IOTOPS WG.
https://datatracker.ietf.org/meeting/112/materials/slides-112-iotops-iot-midlife-crisis-00
https://datatracker.ietf.org/meeting/111/materials/slides-111-iotops-involuntary-ownership-transfer-problem-statement-00
https://datatracker.ietf.org/meeting/interim-2021-iotops-01/materials/slides-interim-2021-iotops-01-sessa-iotdevice-lifecycle-thoughts-about-ownership-changes-00

In my involuntary ownership transfer concern, where I say that we need to be
able to delegate things to others, I was searching for a protocol that would
deal with the various kinds of delegation.

It seems that this proposed work is exactly inline with what I had in mind.

I think that a failure is that none of the things used by hotels or car
vendors have figured out that they have to deal with delegation.
Convince me otherwise?
It's not optional, it's required, otherwise, private keys wind up getting shared.

====

I did go though the draft, and from a technical point of view, it seems like
what is desired is an Authenticated Key Exchange, along with some mailbox
mechanism to deal with asymmetries and ubiqutious NAT.

We have multiple AKEs: IKEv2, TLS, cTLS, EDHOC, and specifically MLS.
Most of these involve at least one round trip in order to establish nonces.

I don't really know how the sender manages to identify the recipient in a
cryptographically strong manner.  This seems like the global PKI problem
again, and I'd like to be convinced otherwise.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide