Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 1:16 PM, Ted Lemon wrote:
On Jun 13, 2019, at 4:08 PM, Michael Thomas > wrote:


It would be good to do this on openwrt, that's for sure. I've never 
tried to hack on it, but it can't be too horrible.



It’s dead easy if you have a Linux VM.   Just build a package, and 
have a place it can be downloaded from.   When you make changes, 
update the package.   You can debug using gdbserver. Let me know if 
you need help with this.



Oh, ok. This is a lot easier because it doesn't care how many real 
interfaces you have, etc. You just need to modify the backend web login, 
and insert some js into the login page which can probably been snarfed 
off the net easily enough now.


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
On Jun 13, 2019, at 4:08 PM, Michael Thomas  wrote:
> It would be good to do this on openwrt, that's for sure. I've never tried to 
> hack on it, but it can't be too horrible.
> 
> 
It’s dead easy if you have a Linux VM.   Just build a package, and have a place 
it can be downloaded from.   When you make changes, update the package.   You 
can debug using gdbserver.   Let me know if you need help with this.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 12:51 PM, Ted Lemon wrote:
On Jun 13, 2019, at 3:46 PM, Michael Thomas > wrote:


Possibly, but I think there are hardware based solutions (eg "press 
to pair") and pure software based ones. The main point is to have 
something to point vendors at. They are probably clueless that this 
is a possibility now.



Ah.  I don’t think that would be useful.  The “if we spec it, they 
will build it” approach has been an utter failure thus far.  We should 
have a clear use case and a clear solution that addresses that use 
case.  We should not specify the kitchen sink and let them pick.  If 
someone has a use case we didn’t address, then that’s demand to 
address another use case, and we can do it, but we have to be real 
about this.  Right now, the only use case that really matters is 
OpenWRT, because that is where _all_ of the running code is.   So a 
solution that works there is the place to start.



A hardware based solution is always going to be more secure than a 
software-only solution but obviously that has even less likelihood of 
being deployed. I'd be perfectly happy to write in the draft that 
hardware assisted solutions would enhance security, but they are out of 
scope, leaving exactly one recommendation for a software solution.


The thing about webauthn is that almost all of the heavy lifting is done 
browser-side. The server side code is very straightforward: store public 
keys of people who can log in, and verify them when they do. And I do 
know this from experience, albeit not with webauthn specifically.


It would be good to do this on openwrt, that's for sure. I've never 
tried to hack on it, but it can't be too horrible.


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
On Jun 13, 2019, at 3:46 PM, Michael Thomas  wrote:
> Possibly, but I think there are hardware based solutions (eg "press to pair") 
> and pure software based ones. The main point is to have something to point 
> vendors at. They are probably clueless that this is a possibility now.
> 
> 
Ah.  I don’t think that would be useful.  The “if we spec it, they will build 
it” approach has been an utter failure thus far.  We should have a clear use 
case and a clear solution that addresses that use case.  We should not specify 
the kitchen sink and let them pick.  If someone has a use case we didn’t 
address, then that’s demand to address another use case, and we can do it, but 
we have to be real about this.  Right now, the only use case that really 
matters is OpenWRT, because that is where _all_ of the running code is.   So a 
solution that works there is the place to start.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 12:43 PM, Ted Lemon wrote:
On Jun 13, 2019, at 3:40 PM, Michael Thomas > wrote:
I don't think this needs to be very involved. I would think that a 
short bcp which lays out why webauthn is a huge advance, and a set of 
different enrollment mechanisms that have some vetting would probably 
be enough.


You mean so that we can pick one?   :)



Possibly, but I think there are hardware based solutions (eg "press to 
pair") and pure software based ones. The main point is to have something 
to point vendors at. They are probably clueless that this is a 
possibility now.


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
On Jun 13, 2019, at 3:40 PM, Michael Thomas  wrote:
> I don't think this needs to be very involved. I would think that a short bcp 
> which lays out why webauthn is a huge advance, and a set of different 
> enrollment mechanisms that have some vetting would probably be enough.

You mean so that we can pick one?   :)

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 12:18 PM, Ted Lemon wrote:
TBH I don’t know anything about OBA other than that I heard it 
discussed.  If you want to write up a draft, that can’t hurt. I’m not 
promising to support it—it depends on what you come up with.   But 
it’s always good to have a place to start, and something to pick apart 
and fix up.   So by all means, if you are willing to proceed on that 
basis, I think it’s a good idea, and I will read it.



I don't think this needs to be very involved. I would think that a short 
bcp which lays out why webauthn is a huge advance, and a set of 
different enrollment mechanisms that have some vetting would probably be 
enough.


Mike, it's been a while since i've written a draft...

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
TBH I don’t know anything about OBA other than that I heard it discussed.  If 
you want to write up a draft, that can’t hurt.   I’m not promising to support 
it—it depends on what you come up with.   But it’s always good to have a place 
to start, and something to pick apart and fix up.   So by all means, if you are 
willing to proceed on that basis, I think it’s a good idea, and I will read it.

> On Jun 13, 2019, at 3:11 PM, Michael Thomas  wrote:
> 
> 
> 
> On 6/13/19 12:02 PM, Ted Lemon wrote:
>> On Jun 13, 2019, at 2:57 PM, Michael Thomas > > wrote:
>>> The meta-question is whether there is something to be done here, and if 
>>> this wg is the right place to do it. I know there was a security part of 
>>> the charter... it sure would be nice to set an example for all of this IoT 
>>> mischief on how to do a proper web login interface.
>>> 
>>> 
>> This is a general problem, not an IoT problem.  IoT is a good motivating use 
>> case, not the complete problem.   We’ve talked about working on this problem 
>> here before. I think it’s in scope and this is a good place to do it.  Iff 
>> people are willing to participate!
>> 
>> 
> 
> Should I write up a draft? It would be really good that something 
> (convergent) evolved out Stephen, Paul and my rfc 7486, as the first thing I 
> experimented on was something for a home router based application :)
> 
> Mike, who has no idea if the webauth folks had any idea about our hoba stuff.
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 12:02 PM, Ted Lemon wrote:
On Jun 13, 2019, at 2:57 PM, Michael Thomas > wrote:


The meta-question is whether there is something to be done here, and 
if this wg is the right place to do it. I know there was a security 
part of the charter... it sure would be nice to set an example for 
all of this IoT mischief on how to do a proper web login interface.



This is a general problem, not an IoT problem.  IoT is a good 
motivating use case, not the complete problem.   We’ve talked about 
working on this problem here before. I think it’s in scope and this is 
a good place to do it.  Iff people are willing to participate!





Should I write up a draft? It would be really good that something 
(convergent) evolved out Stephen, Paul and my rfc 7486, as the first 
thing I experimented on was something for a home router based application :)


Mike, who has no idea if the webauth folks had any idea about our hoba 
stuff.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
On Jun 13, 2019, at 2:57 PM, Michael Thomas  wrote:
> The meta-question is whether there is something to be done here, and if this 
> wg is the right place to do it. I know there was a security part of the 
> charter... it sure would be nice to set an example for all of this IoT 
> mischief on how to do a proper web login interface.
> 
> 
This is a general problem, not an IoT problem.  IoT is a good motivating use 
case, not the complete problem.   We’ve talked about working on this problem 
here before. I think it’s in scope and this is a good place to do it.  Iff 
people are willing to participate!


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 11:46 AM, Ted Lemon wrote:
On Jun 13, 2019, at 2:40 PM, Michael Thomas > wrote:


Are we talking about the same thing? I'm not sure what naming has to 
do with dealing with crappy/default passwords on router web interfaces?


If your router has a name, it can get a cert.  If it doesn’t have a 
name, it can’t.   That cert then becomes a basis for establishing trust.
I'm not sure what a router cert has to do with webauthn, other than 
enabling TLS as Michael pointed out. But even self-signed cert where you 
ignore the scary warning would work too.


In the case of devices on the home network establishing trust with the 
router, you have to bootstrap that somehow.   In that case, the 
easiest thing to do is as I suggested:


 1. you have access to the router’s network
 2. nobody else has established trust yet


This isn’t ideal, but it creates a pathway for further trust 
establishment: once you have one device that has a trusted key, then 
that device can authorize additional devices, which can authorize 
additional devices.   A device that comes onto the network after 
initial trust establishment can’t get trust without being approved.



Yes, that's what I mentioned too. So I think we're in agreement.

The meta-question is whether there is something to be done here, and if 
this wg is the right place to do it. I know there was a security part of 
the charter... it sure would be nice to set an example for all of this 
IoT mischief on how to do a proper web login interface.


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
On Jun 13, 2019, at 2:40 PM, Michael Thomas  wrote:
> Are we talking about the same thing? I'm not sure what naming has to do with 
> dealing with crappy/default passwords on router web interfaces?
> 
If your router has a name, it can get a cert.  If it doesn’t have a name, it 
can’t.   That cert then becomes a basis for establishing trust.

In the case of devices on the home network establishing trust with the router, 
you have to bootstrap that somehow.   In that case, the easiest thing to do is 
as I suggested: 

you have access to the router’s network
nobody else has established trust yet

This isn’t ideal, but it creates a pathway for further trust establishment: 
once you have one device that has a trusted key, then that device can authorize 
additional devices, which can authorize additional devices.   A device that 
comes onto the network after initial trust establishment can’t get trust 
without being approved.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 11:37 AM, Ted Lemon wrote:
On Jun 13, 2019, at 2:33 PM, Michael Thomas > wrote:


Yeah, the router clearly knows whether something is on the local net, 
but it doesn't know if it's a visitor. Requiring that you put the 
visitors on a guest net is not exactly ideal either.



That’s not relevant for front-end naming.   In this case the trust is 
being established between a customer edge router or a service on the 
customer network, and a front end name server operated by the ISP.   A 
guest device would not be able to interpose itself in this process if 
it were designed correctly.



Are we talking about the same thing? I'm not sure what naming has to do 
with dealing with crappy/default passwords on router web interfaces?


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
On Jun 13, 2019, at 2:33 PM, Michael Thomas  wrote:
> Yeah, the router clearly knows whether something is on the local net, but it 
> doesn't know if it's a visitor. Requiring that you put the visitors on a 
> guest net is not exactly ideal either.
> 
> 
That’s not relevant for front-end naming.   In this case the trust is being 
established between a customer edge router or a service on the customer 
network, and a front end name server operated by the ISP.   A guest device 
would not be able to interpose itself in this process if it were designed 
correctly.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas


On 6/13/19 8:47 AM, Ted Lemon wrote:
On Jun 13, 2019, at 11:15 AM, Michael Thomas > wrote:
All of which require authentication of some form, which the router 
itself doesn't have the credentials. But home routers do have a few 
different characteristics: proximity and local addressing. Maybe your 
work you pointed out might be applicable?


“how you are connected” plus “no conflict” is a fairy effective ad-hoc 
method for establishing trust.


E.g., for a very long time, ISPs have used the fact that you are 
connected to their network as a basis for authorizing your DHCP 
transaction.   If the ISP is doing the front-end naming, then that 
mechanism could work here as well. If someone else is doing front-end 
naming, then you probably have to have put a credit card in somewhere…




Yeah, the router clearly knows whether something is on the local net, 
but it doesn't know if it's a visitor. Requiring that you put the 
visitors on a guest net is not exactly ideal either.


I'm thinking that a lot  of my hand-wringing here is only for adding 
more devices to the router's list of devices that can log in. I'd assume 
that the router would be in "peer mode" by default when it doesn't have 
any enrolled devices. Worst case, you can always log into the router 
with the primary device and press a button to permit other devices. 
Which is to say, I may be overthinking this :)


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Ted Lemon
On Jun 13, 2019, at 11:15 AM, Michael Thomas  wrote:
> All of which require authentication of some form, which the router itself 
> doesn't have the credentials. But home routers do have a few different 
> characteristics: proximity and local addressing. Maybe your work you pointed 
> out might be applicable?

“how you are connected” plus “no conflict” is a fairy effective ad-hoc method 
for establishing trust.

E.g., for a very long time, ISPs have used the fact that you are connected to 
their network as a basis for authorizing your DHCP transaction.   If the ISP is 
doing the front-end naming, then that mechanism could work here as well.   If 
someone else is doing front-end naming, then you probably have to have put a 
credit card in somewhere…

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Thomas



On 6/13/19 7:18 AM, Michael Richardson wrote:

Michael Thomas  wrote:
 > Thanks, it's probably pretty dated by now, especially all of the crypto
 > hackery :). The thing that I'm not sure about is whether the out-of-band
 > method for adding clients would work in a home router situation. My 
solution
 > required the server (ie, the router) to send email to somebody. It

Or SMS. Or a push notify, which would definitely work.



All of which require authentication of some form, which the router 
itself doesn't have the credentials. But home routers do have a few 
different characteristics: proximity and local addressing. Maybe your 
work you pointed out might be applicable?


Of course, it could always have a bluetooth-esque "pairing" button to 
enroll devices that are allowed to log in, but that would require hardware.


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-13 Thread Michael Richardson
Michael Thomas  wrote:
> Thanks, it's probably pretty dated by now, especially all of the crypto
> hackery :). The thing that I'm not sure about is whether the out-of-band
> method for adding clients would work in a home router situation. My 
solution
> required the server (ie, the router) to send email to somebody. It

Or SMS. Or a push notify, which would definitely work.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-12 Thread Michael Thomas



On 6/12/19 3:18 PM, Michael Richardson wrote:

Michael Thomas  wrote:
 >> Secondary admins are encouraged to guard against loss/destruction of 
mobile
 >> phone, and it is also possible to enroll a second time, provided the
 >> manufacturer agrees (this is both a feature and a bug)
 >>
 >> The code is at https://github.com/CIRALabs/
 >>

 > I'm not sure we're talking about the same thing? I'm just talking about 
the
 > normal web interface that home routers have to hand configure them. 
There's
 > no need for certs at all.

Yes, that's what I'm talking about.
Yes, there is a need for strong security.

The bad guys are inside already, they send trojans, and if the router has
passwords ("admin"/"admin"), then the bad guys just change the security
policy.

They don't do this now, because they don't need to, our home routers are
basically swiss cheese in the outbound direction, but I'm sure they will
learn.  Particularly, it will be easy if we have a standard (or
defacto-standard) API.  At this point, the luci interface is probably easily
automated.

Modern browsers practically don't let you even type passwords in over HTTP
now, so you really really really need a certificate for the inside of the
router, and it needs to be valid.
Oh, sorry, I wasn't thinking about TLS. Obviously you need server certs 
for that. I was thinking about the client side authentication which is 
what webauthn is for, and it doesn't require certs of any kind, iirc.


 > I wrote a blog post which considered the enrollment problem of a
 > webauthn-like protocol (way before webauthn was even started). I'm not 
sure
 > if it works for the special case of a home router though.

 > 
http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

 > Enrollment, of course, is out of scope for webauthn, per se.

I'll read it.

Thanks, it's probably pretty dated by now, especially all of the crypto 
hackery :). The thing that I'm not sure about is whether the out-of-band 
method for adding clients would work in a home router situation. My 
solution required the server (ie, the router) to send email to somebody. 
It could be sms too, but it's not very clear that email from a naked 
router ip address would be very effective since, like, nobody accepts 
email from home net ranges. I guess in theory you could configure an 
mail account for the router, but that seems sort of like a non-starter. 
But there may be other ways to finesse this.


Mike


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-12 Thread Michael Richardson

Michael Thomas  wrote:
>> Secondary admins are encouraged to guard against loss/destruction of 
mobile
>> phone, and it is also possible to enroll a second time, provided the
>> manufacturer agrees (this is both a feature and a bug)
>>
>> The code is at https://github.com/CIRALabs/
>>

> I'm not sure we're talking about the same thing? I'm just talking about 
the
> normal web interface that home routers have to hand configure them. 
There's
> no need for certs at all.

Yes, that's what I'm talking about.
Yes, there is a need for strong security.

The bad guys are inside already, they send trojans, and if the router has
passwords ("admin"/"admin"), then the bad guys just change the security
policy.

They don't do this now, because they don't need to, our home routers are
basically swiss cheese in the outbound direction, but I'm sure they will
learn.  Particularly, it will be easy if we have a standard (or
defacto-standard) API.  At this point, the luci interface is probably easily
automated.

Modern browsers practically don't let you even type passwords in over HTTP
now, so you really really really need a certificate for the inside of the
router, and it needs to be valid.

> I wrote a blog post which considered the enrollment problem of a
> webauthn-like protocol (way before webauthn was even started). I'm not 
sure
> if it works for the special case of a home router though.

> 
http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

> Enrollment, of course, is out of scope for webauthn, per se.

I'll read it.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers

2019-06-12 Thread Michael Thomas



On 6/12/19 12:13 PM, Michael Richardson wrote:

MIchael Thomas  wrote:
 >>> There are no passwords.

 >> Yes please.

 > Speaking of which, should we be encouraging router vendors to implement
 > webauthn? Considering that probably half of home routers have the default
 > password, that seems like it would be a Good Thing.

We have done an enrollment system which based upon BRSKI.
It is described in draft-richardson-ietf-anima-smarkaklink.
We have running code with a desktop acting as the client, with
the mobile app being built now.  I am making a screencast today, actually.
There are similarities to some profiles of EAP-NOOB, but we do
rely on the manufacturer as the root of trust.

I guess we could/should have considered enhancing webauthn instead; I have to
think a bit about whether it would have work as well.  I will need to see.

At the end of the day, we wind up with a mobile phone with a certificate
enrolled into a private CA on the router.  The router itself has a
LetsEncrypt certificate acting as it's IDevID, although this could
be a private CA instead.  There are issues in both directions.

Secondary admins are encouraged to guard against loss/destruction of mobile
phone, and it is also possible to enroll a second time, provided the
manufacturer agrees (this is both a feature and a bug)

The code is at https://github.com/CIRALabs/



I'm not sure we're talking about the same thing? I'm just talking about 
the normal web interface that home routers have to hand configure them. 
There's no need for certs at all.


I wrote a blog post which considered the enrollment problem of a 
webauthn-like protocol (way before webauthn was even started). I'm not 
sure if it works for the special case of a home router though.


http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

Enrollment, of course, is out of scope for webauthn, per se.

Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers (was: securing zone transfer)

2019-06-12 Thread Michael Richardson

MIchael Thomas  wrote:
>>> There are no passwords.

>> Yes please.

> Speaking of which, should we be encouraging router vendors to implement
> webauthn? Considering that probably half of home routers have the default
> password, that seems like it would be a Good Thing.

We have done an enrollment system which based upon BRSKI.
It is described in draft-richardson-ietf-anima-smarkaklink.
We have running code with a desktop acting as the client, with
the mobile app being built now.  I am making a screencast today, actually.
There are similarities to some profiles of EAP-NOOB, but we do
rely on the manufacturer as the root of trust.

I guess we could/should have considered enhancing webauthn instead; I have to
think a bit about whether it would have work as well.  I will need to see.

At the end of the day, we wind up with a mobile phone with a certificate
enrolled into a private CA on the router.  The router itself has a
LetsEncrypt certificate acting as it's IDevID, although this could
be a private CA instead.  There are issues in both directions.

Secondary admins are encouraged to guard against loss/destruction of mobile
phone, and it is also possible to enroll a second time, provided the
manufacturer agrees (this is both a feature and a bug)

The code is at https://github.com/CIRALabs/


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] webauthn for routers (was: securing zone transfer)

2019-06-12 Thread MIchael Thomas


On 6/12/19 7:42 AM, Ted Lemon wrote:
On Jun 12, 2019, at 10:22 AM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

There are no passwords.


Yes please.


Speaking of which, should we be encouraging router vendors to implement 
webauthn? Considering that probably half of home routers have the 
default password, that seems like it would be a Good Thing.


I do wonder what the implications are for enrollment.

Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet