On 09/10/2016 09:24, Michael Richardson wrote: > > Christian Huitema <[email protected]> wrote: > >> This might be fine for larger devices with displays, but it's a fail > >> everywhere else. Even in ANIMA, one could have a $300K BFR being > >> deployed, > >> but it doesn't have a display or a person to read the display. > >> But, does this device need privacy? > >> But, the same system ideally bootstraps home routers, which at $39.95, > >> still > >> don't have a display or a competent human to read the display. > > > You need some signal -- you cannot build trust out of zero knowledge and > > zero signal. > > I agree; recall how many times semi-technicals have suggested that having > source IP > addresses was a privacy mistake, and we should remove them....
However, encrypting the source address as part of the payload would work. This topic was in fact explored a few years ago: J. Crowcroft. SNA: Sourceless Network Architecture. In Perspectives Workshop: End-to-End Protocols for the Future Internet, Schloss Dagstuhl, 2008. www.cl.cam.ac.uk/~jac22/out/sna.pdf Brian > > > This is not a new problem -- I am copying Daniel, who studied all that > in > > great detail for his PhD. Over time, we have seen two solutions emerge > for > > device pairing. > > Looking forward to a link to read it! > > > As for the question whether devices need privacy, clearly it depends. > My gut > > feeling is that mobile devices do. Portable devices, most certainly do. > > I think you are right, but there is a finer distinction to be made: > 1) devices with no local identities that may need to be bootstrap'ed. > > 2) devices with local identities which are trying to join/use a new network. > (the first time you visit CoffeeShop at corner of Fifth and Broadway) > > 3) devices with local identities which are re-joining a network they have > been on before; but may not wish to leave a trace to a) the network > operator, b) other observers. > > > What might work is a combination of public key and PSK. Use the known > public > > key of the server to encode the PSK ID, and then add a proof that the > client > > sending the message owns the PSK. Third parties cannot deduce the > client ID > > or the server ID from the initial message, only the server can decrypt > its > > own public key and identify the client, and everything after that > initial > > message will be encrypted. You do have to include a nonce in the initial > > message to prevent replay attacks, but it could work. > > In the bootstrap or CoffeeShop situation, is the Server part of the network? > In that case, how can the client know the public key of the network? > > How is this not vulnerable to an active MITM using a different "known public > key"? > This doesn't happen today with Wifi because a human either picks "CoffeeShop" > ESSID, or can validate the cert chain to say "CoffeeShop Inc", but a device > can't do this. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
