Network transparancy api review.

[Fabrizio Montesi]

On Wednesday 24 June 2009 04:16:34 Aaron J. Seigo wrote:
> On Tuesday 23 June 2009, Rob Scheepmaker wrote:
> > On Tuesday 23 June 2009 19:42:55 Fabrizio Montesi wrote:
> > > On Tue, Jun 23, 2009 at 7:05 PM, Rob Scheepmaker <
> > >
> > > r.scheepmaker at student.utwente.nl> wrote:
> > > > Hello everybody,
> > > >
> > > > [cut]
> > >
> > > Hi Rob,
> > > just a quick comment about identifying remote machines. What about
> > > combining public key authentication with the bluetooth pairing method
> > > (the host writes a PIN, the client is asked for the PIN, the two PINs
> > > must match)?
> > > This way if the user is too lazy to check the public key we reduce
> > > greatly the attacker's possibilities. Using this approach we'd have to
> > > face the fact that a lazy user could write "1234" as a PIN, too: the
> > > host side UI for writing the PIN should warn the user that things like
> > > "1234" are not such a good idea.
> >
> > A quite good idea. So the first time we receive a new key we ask for a
> > password at both sides which have to match. And if the key is already
> > there then this step isn't necesarry. I'll think about how to integrate
> > this nicely with the api.
>
> this only works, of course, when there's a human pairing the two devices
> that are within reach/sight. it must also be possible for one side of the
> transaction to be a machine hidden in a wall. :)

Right!
We could make this feature optional, something like the following.
When the client makes the request, the request also says if the client 
supports the PIN feature or not. If yes, then the host can ask for a PIN.
Host side there would then be no problem: hosts not supporting the PIN thing 
would just send back the response (authorized/not authorized).

This has the great disadvantage of having two ways for doing the same thing 
(authorization with or without using the UI for handling the PIN thing), which 
could be confusing for the user. A good UI flow could ease the pain, though.