Re: [Secret] Follow up on Michael's Comments

[Michael Richardson <[e-mail]>]

Please know that I'm not hostile to this work occuring.
I just don't want to confuse people about the goals.
(Although I really don't like the choice of BOF name)

I'm please to learn that there are protocols like SCP03, and that they handle
delegation.  This is sorely missing in what people see today iin IoT.

I'd love to have an overview talk at IOTOPS about SCP03 and the CCC
automotive credential protocol.

Matthew Byington <[e-mail]> wrote:
    > An example of an asymmetric credential would be digital car key
    > credentials adhering to the CCC standard, or asymmetric credentials
    > used in Home or MFH (multi-family home) that adhere to the ISO18013
    > open standard.

Could you please cite the specific CCC document involved?
ISO18013 is not publically available.

    > In _no_ circumstance shall a private key, nor a symmetric secret key,
    > ever, ever be transferred to anyone else.

...
    > In these cases, to your point, the third party would absolutely have to
    > issue the credential for the intended recipient.

So, how are we involved at all?

    > The transfer protocol that we endeavor to standardize would simply facilitate that.

What would we be transfering, in a symmetric key case, where HID has to issue
the credential?

    > I don’t want to get into the solutioning here too much (let’s save that
    > for the WG) but you can almost think about it like:

    > 1) Sender (with existing provisioned credential from remote credential
    > authority) asks the RCA for a “bearer token”

While one can implement Bearer Tokens as indexes into database (instead of a
key that decrypts something like a Kerberos Ticket), by their nature, they
have all the privacy implications of symmetric keys.

    > 2) RCA issues bearer token (could be a signed piece of data, could be a
    > UUID, etc) and on their backend, ties that to the access rights/levels
    > specific to a subset of what the sender has, based on the sender’s
    > existing rights and the sender’s desired rights for the recipient

    > 3) The RCA returns this BT to the sender.
    > 4) The sender sends this BT to the receiver thru the transfer protocol we’d define in the WG
    > 5) The recipient calls the credential authority and “redeems” this for
    > a valid provisioned credential with key material completely separate
    > from the sender’s.

This sure sounds a lot like OAUTH2 to me :-)
Perhaps it would all work better if we explicitely used the terminology from
OAUTH2.

    > The security of (5) is well-established today with protocols like JCOP
    > platform running on a  device, SCP03 (secure channel protocol
    > encryption) etc etc that exist on most mobile devices today. That is
    > completely out of the scope of the transfer work flow.

Okay, then I think that we need some high-level explanation of these
protocols.  I'd like to see the charter reference them with "such as..."

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