Hi Marius, Thank you very much for your detailed reading of the paper and your very useful comments. I've revised the paper based on your comments and put a new version online, with an acknowledgment of your contribution.
> PKAuth seems similar to OAuth 2, I think it would help if you used the same > terminology: > - application => client > - social site => authorization server > - client => end user > - reference code => authorization code PKAuth provides the functionality of both OAuth and OpenID, which use different terminologies. And OAuth 1.0 and RFC 5849 also have different terminologies, which people still seem to be using. So there are 4 different "formal" terminologies. I decided to use an "informal" one, at least at this early stage, that can be understood without having to look up definitions in a terminology section. I did not mean to use "client" for "end user". I've rechecked the paper and I see that I used "client" once, by mistake, where I should have said "application". That must have been confusing. I've fixed it. > The paper claims that users do not know how to interpret > domain names, which is probably true. Is there any evidence > that users are doing better with names as found in SSL > certificates? I don't know of any evidence, but that's because users do not usually see the information in the certificate. I said in the abstract that browsers display certificate information, but that was a mistake: the user has to do some clicking to see it. The browser does not have real estate to display certificate info without clicking, but in PKAuth the social site has plenty of real estate in the page where it asks the user whether the application is to be trusted. So this is a new way of using the information in the certificate. It would be interesting to do a study to see how much it helps. > Discovery is based on link tags in HTML pages, did you > consider using /.well-known/host-meta instead? To be honest, I was not aware of that. Now I've looked at it and I see that that it would make it possible to support multiple social sites having URLs with the same host name. But on the other hand it adds complexity, and I was trying to keep the protocol as simple as possible, so I'm not sure if it's a good idea. > At step 1, the difference between official-name and > alternative-name can only be "www.". Why not just follow > redirects? You're very right, the social site should redirect from https://alternative-name to https://official-name rather providing a PKAuth link element in https://alternative-name. I've fixed that. > Not sure I understand why the reference code must be > generated by the social site, how would session fixation > work if it was generated by the application? Suppose the protocol requires the application to send the reference code as an additional parameter in step 2. Here is the attack scenario. The attacker is a Web user who does not have an account at the application nor at the social site. The attacker takes advantage of a victim who has an account at both the application and the social site. The attacker makes a login request to the application, and chooses to use the social site for authentication. The application provides a response that redirects to the site. The attacker uses an ad-hoc user agent that does not follow up on the redirect, but reports instead the redirect URL, which contains the reference code, to the attacker. The attacker creates a link whose target is the redirect URL, places it on a Web page, and tricks the victim into clicking on the link. The social site authenticates the victim (step 4), sends the reference code, authorization token, etc., to the direct callback endpoint of the application (step 5), then sends the reference code, etc., to the redirect callback endpoint by redirecting the victim's browser (step 7). But the attacker knows the reference code and can send the same request to the redirect callback endpoint. So the victim and the attacker both send a request with the reference code to the redirect callback endpoint. In step 8, when the application receives a request at the redirect callback endpoint, it uses the reference code to locate the authorization code and other info received earlier through the direct callback endpoint, and it logs in the user and sets an authentication cookie in the user's browser. If the attacker's request arrives before the victim's request, the attacker will be logged in and an authentication cookie will be placed in the attacker's browser. If the victim's request arrives first the victim will be logged in but, if the application takes no precautions, it may later log in the attacker too. > The social site most likely has a large number of API > endpoints, providing only one pkauth-subsequent-access does > not scale. Or maybe I misunderstood the purpose of > pkauth-subsequent-access. Very true. That was silly of me. The protocol does not need a pkauth-subsequent-access endpoint. Once the application has the authorization token it can send it to any API endpoint for subsequent access. > PKAuth would work only for web applications and compared to > OAuth 2 it raises the bar for them: they need an SSL cert > and also an API endpoint. Especially web app only, is a very > strong limitation. Here I have to disagree. First, in OAuth the client is also a Web application, isn't it? What else could it be? Second, an SSL cert is a requirement for any Web application that authenticates its users, isn't it? Third, what's the problem with an API endpoint? I assume that by "API endpoint" you mean an endpoint that does not return a Web page to be displayed by a browser. Well, it's a lot easier to implement an endpoint that does not return a Web page than one that does. The PKAuth application has two such endpoints, the application authentication endpoint and the direct callback endpoint. The application authentication endpoint can be as simple as the URL of a static text file with two lines providing the URLs of the direct and redirect callback endpoints. The direct callback endpoint receives data and stores it in a database record. How long does it take to implement that? One hour? Actually, I argue that PKAuth is simpler than OAuth because it does not require an intermediate token. In OAuth two tokens are needed (the access grant and the access token) precisely because of the danger that the first token, send by redirection, may fall into the wrong hands. In the case of a registered application, the first token is exchanged for the second token only after the appplication has proved its identity. But if the application is unregistered, the exchange provides no security. In PKAuth there is only one token, which is sent to the direct callback endpoint and does not run the risk of falling into the wrong hands. I've added this argument to the paper. Again, thanks a lot! Francisco
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
