As promised, here is a draft that attempts to wangle BRSKI to allow for proof of possession tests. This is very early work and intended for discussion at this point during OPSAWG and at the side meeting we have scheduled for Tuesday night. If people like what they see, we can discuss in more detail in Prague.
This draft includes three specific test types, one of which may come out
Real Soon:
1. The registrar has obtained proof of possession and provides that
proof to the MASA. This solves a wireless case.
2. The registrar has obtained proof of possession and, rather than
providing proof to the MASA, provides proof to the pledge (two-party
instead of three).
3. The registrar tells the MASA, “Trust Me! Really!” in its best Joe
Isuzu voice*. (This may be redundant, which is why it may come out.)
Discussion points:
* The basis of all of this work is really that Max, Michael, and Kent
did a bang up job by coming up with the voucher concept, and so
let's all agree PLEASE that no matter how we slice it, a voucher
request needs to be generated, and a voucher response needs to be
delivered. The means for proof, and even the identity returned, can
be stretched.
* Should we stretch further, and include different keying material
objects? I'm CCing EAP folk because that is a big fat question for
them.
Eliot
* See https://www.youtube.com/watch?v=mR361ASrMew
--- Begin Message ---A new version of I-D, draft-lear-brski-pop-00.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-brski-pop Revision: 00 Title: Proof of Possession to Devices for Onboarding Document date: 2018-10-20 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-lear-brski-pop-00.txt Status: https://datatracker.ietf.org/doc/draft-lear-brski-pop/ Htmlized: https://tools.ietf.org/html/draft-lear-brski-pop-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-lear-brski-pop Abstract: This memo specifies a RESTful interface for local deployments to demonstrate proof of possession to a device or to a manufacturer authorized signing authority (MASA). This covers the case where a MASA would not otherwise have knowledge of where a device is deployed, or when a MASA may not be required. Such knowledge is important to onboard certain classes of devices, such as those on IEEE 802.11 networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
--- End Message ---
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
