SQRL and STUN for CPS provided by Device Auth


JamesonNetworks

New member
Feb 20, 2021
2
0
I'm just thinking out loud on the forums here, but I was wondering if anyone every thought about the inclusion of a 3rd party service that could provide the security of CPS using a STUN server to traverse NAT in order to serve the SQRL client's secure redirect hosted page on the device itself and provide the assurances that would be needed to make device CPS happen?
 

PHolder

Well-known member
May 19, 2018
1,225
205
inclusion of a 3rd party service
SQRL was explicitly designed to avoid third party involvements and to make the end user explicitly in control of their own identity while giving the server no secrets to have to secure or worry about losing.

Also, unless I really don't understand your question, I think you really don't understand SQRL. If you can connect to the server using HTTPS (TCP/IP) to view the page with the SQRL login, you should be able also authenticate with SQRL. There is NO need for UDP, and thus no need for STUN.
 

JamesonNetworks

New member
Feb 20, 2021
2
0
My question is more related to providing a CPS instance to a user authenticating on a machine which they do not normally use (as in coffee shop or the like), not specifically about SQRL login in general.

After thinking about it a bit longer, however, I came up with all kinds of scenarios in my head where once you go off of the localhost of the originating machine you only get opened up for MORE opportunities for bad things to happen, not less (which was laid out in the SQRL docs, but in my delusions of grandeur on Friday I thought maybe I'd cracked it).

For context, I'm taking a look at the django-sqrl module and thinking through some niceties like requiring CPS to associate a SQRL identity, view billing information, or generate API tokens (something similar to requiring a user to reenter their password, but in this case making the user get back to a computer where CPS can be provided)
 

ramriot

Well-known member
May 24, 2018
131
15
My question is more related to providing a CPS instance to a user authenticating on a machine which they do not normally use (as in coffee shop or the like), not specifically about SQRL login in general.

After thinking about it a bit longer, however, I came up with all kinds of scenarios in my head where once you go off of the localhost of the originating machine you only get opened up for MORE opportunities for bad things to happen, not less (which was laid out in the SQRL docs, but in my delusions of grandeur on Friday I thought maybe I'd cracked it).

For context, I'm taking a look at the django-sqrl module and thinking through some niceties like requiring CPS to associate a SQRL identity, view billing information, or generate API tokens (something similar to requiring a user to reenter their password, but in this case making the user get back to a computer where CPS can be provided)
As you suggest there are a number of bad situations that can occur after you authenticate having assured CPS if the machine is compromised, an out of scope situation for sure.

My thoughts on this matter are that CPS is there so thwart dynamic phishing (homograph domain etc) where an attacker does not control network association, because the redirect cannot be introspected by such an attacker.

If we consider a complete network compromise as in scope ( bad router plus certs ) then many scenarios become possible on either channel. IMO In these situations the protocol should probably not allow authentication in the first place if it cannot assure e2ee. To perform that there needs to be linkage between the internal & external state of each channel say by TLS channel binding.

To achieve that on the client network channel ( >V1.0 ) would be a matter of including a TLS channel context parameter in each client query that a so enabled server could check against to assure there is no MITM there. For the browser side it would require a browser plugin that could do the same by adding said context as a parameter to the SQRL protocol link.