Subject: [OAUTH-WG] unregistered applications

From: Francisco Corella <[email-masked]>
Date: Wed, 22 Dec 2010 09:57:48 -0800 (PST)

Hi all,

OAuth provides only weak security when used with
unregistered applications.  OTOH compulsory registration is
a bad idea: imagine a situation where a social site becomes
dominant, social login via that site becomes the de facto
authentication standard on the Web, every application has to
register with the site, and the site can kill any
application by revoking its registration.  I've written a
paper that proposes a solution.  Thanks in advance for any
comments.

-- Francisco

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 23 Dec 2010 12:32:07 -0800

Hi Francisco,

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

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?

Discovery is based on link tags in HTML pages, did you consider using
/.well-known/host-meta instead?

At step 1, the difference between official-name and alternative-name can
only be "www.". Why not just follow redirects?

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?

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.

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.

Marius

On Wed, Dec 22, 2010 at 9:57 AM, Francisco Corella <[email-masked]>wrote:

> paper <http://www.pomcor.com/whitepapers/PKAuth.pdf> that proposes a
> solution.  Thanks in advance for any
> comments.
>
> -- Francisco
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Francisco Corella <[email-masked]>
Date: Thu, 23 Dec 2010 21:38:11 -0800 (PST)

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

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

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 29 Dec 2010 14:06:02 -0800

> acknowledgment of your contribution.

I'm glad you found the comments useful, not sure I really deserve to
be mentioned.

> 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.

> to keep the protocol as simple as possible, so I'm not sure

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.

> the application takes no precautions, it may later log in

Got it, thanks.

> it?  What else could it be?

A native app, a JavaScript widget, a device.

https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/

> 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