On Thu, Dec 23, 2010 at 9:38 PM, Francisco Corella <[email protected]> wrote: > 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.
I'm glad you found the comments useful, not sure I really deserve to be mentioned. > > 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. Yeah, really confusing as is. I just thought it would help if you used one of the existing terminologies. > 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. I don't think it adds much complexity. And for implementors it is a big help, much simpler to implement /.well-known/host-meta. Imagine asking a large website to add a few HTML tags to every single request to / as opposed to adding a special file. > > 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. Got it, thanks. > > 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? A native app, a JavaScript widget, a device. https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/ > 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. I think you still have two tokens, the reference code (similar to the authorization code in OAuth 2) and an authorization token (access / refresh token in OAuth 2). Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
