Hi Yoav, On 07/28/2014 12:46 PM, Yoav Nir wrote: > Hi Hannes > > I tend to agree. The beauty of IP (with or without “sec”) is that I > can open a connection in one place to a server that is located in > another location half-way around the world. The garage door opener is > used from a short distance, so you don’t really need routing.
Good observation! > You > still might want to use IP, if only because IP-supporting equipment > is so ubiquitous. For the use cases we are talking about it is not ubiquitous at all. We only just see the first products offering IP-based services in that area and they are using IP for an entirely different purpose, namely to connect the garage door to some cloud-based service to allow a owner of the garage to check (via his smart phone) whether it is open (or potentially to open it from remote). > I would have liked it if we could use some zeroconf > protocol for discovering the garage door, but just because the opener > is physically close to the garage door does not mean that it is > topologically close on the Internet. It turns out that there are various ways to discover the garage door and to control it using all sorts of application layer protocols but all this adds is delay and complexity with no additional value in this case. > So the best IP-based way is to > register the garage door in DNS (garagedoor.yaronshouse.org), and > then HTTPS works at least as well as HTTP over IPsec. HTTPS works pretty well. > > All this underlines Yaron’s claim that we need a better example for a > use case for NULL auth. All we are doing here is to add new options, don't explain enough to allow others (like developers) to figure out how this stuff is supposed to work. What I am trying to do is to look at design patterns and try to help developers make their life easier. It is already difficult enough because we often leave half-baked building blocks around that do not help to build interoperable solutions. This work on IPsec for constrained devices does not help me at all to get anywhere closer to that goal. Ciao Hannes > > Yoav > > BTW: my local police station has an electrically-operated gate to the > parking lot where the patrol cars are parked. It’s opened remotely by > calling a particular phone number. The gate answers, immediately > hangs up, and opens. This is pretty bad, because a phone number is a > terribly short shared secret. The use of cellular radio technology might have impacted their design decisions. I don't know what other design decisions they had to deal with. It is hard to say whether the use of IPsec would be any better or whether they should just use CoAP over DTLS based on the profiles we have been working on in DICE. > > On Jul 28, 2014, at 12:05 PM, Hannes Tschofenig > <[email protected]> wrote: > >> Hi Yaron, >> >> if you further try to implement a prototype for a door opener then >> you might run into a number of issues, such as >> >> * how does the garage opener discover the garage door? * what radio >> technology are you going to use? * how does the garage door >> authorize the garage opener? >> >> When you then answer all these questions you might realize (as I >> did) that you neither want to use IPsec there nor even IP. >> >> Ciao Hannes >> >> PS: I agree with your statement about mutual authentication. >> >> On 07/25/2014 06:37 PM, Yaron Sheffer wrote: >>> This might sound like a nit, but we have this text in the draft, >>> as a use case for null auth: >>> >>> "User wants to get some simple action from the remote device. >>> Consider garage door opener: it must authenticate user to open >>> the door, but it is not necessary for the user to authenticate >>> the door opener. In this case one-way authentication is >>> sufficient." >>> >>> The problem is, this is an incorrect protocol. Specifically, a >>> MITM (who might be physically located by the kitchen door), could >>> redirect the protocol exchange to a door different from the one I >>> intended to open. Seeing that nothing happens, I will simply >>> press the remote again and open the garage door, too. >>> >>> This is of course a generic problem, where unauthenticated >>> protocols have unforeseen consequences. >>> >>> Thanks, Yaron >>> >>> >>> _______________________________________________ IPsec mailing >>> list [email protected] https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> _______________________________________________ IPsec mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/ipsec >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
