Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Eran Hammer-Lahav]

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Peter Saint-Andre
> Sent: Wednesday, June 01, 2011 11:43 AM

> Throughout the document, the various parameters (e.g., client_secret and
> client_id) are essentially undefined. There is no text about the length of
> these parameters, the allowable characters (e.g., alpha and digits only, all
> ASCII characters, full Unicode), internationalization considerations,
> preparation and comparison of strings, etc. I don't see how developers will
> build interoperable implementations without clear guidance here.

We have no consensus on string sizes.

I can add a note that all strings are UTF-8 encoded unless specified otherwise. 
Access tokens, for example, are defined by each profile.
 
> Also, the scope parameter still strike me as extremly vague. Can we at least
> define the word "scope" and provide a few examples of how the parameter
> might be used?

Please suggest text.

> No rules are provided for URI matching (e.g., in Section 4.1 the redirection
> URI received needs to be checked against the URI used to redirect the client,
> but not guidance is provided). Perhaps a reference to RFC 3986 is in order
> here. Here also internationalization concerns might need to be covered (e.g.,
> are IRIs allowed?).

Added reference to 3986. As to IRIs, as long as they are encoded as URIs, but 
last I checked, that was implicit by default.

> 4.1.2. Authorization Response
> 
> OLD:
>  If an
>  authorization code is used more than once, the authorization
>  server MAY revoke all tokens previously issued based on that
>  authorization code.
> 
> NEW:
>  If an
>  authorization code is used more than once, the authorization
>  server SHOULD revoke all tokens previously issued based on that
>  authorization code.
> 
> RATIONALE: MAY seems weak here.

This was changed to MAY because most large scale implementations will not be 
able to revoke access tokens at all (typically a self-encoded token good for 
one hour). A SHOULD would be good but impractical advice. I changed it to 
'SHOULD attempt' for now.

> OLD:
>The authorization server SHOULD issue access tokens with limited
>scope and duration to clients incapable of authenticating.
> 
> NEW:
>If the authorization server issues access tokens to clients
>that are incapable of authenticating, the scope and duration of
>such tokens SHOULD be limited.
> 
> RATIONALE: We're not actively RECOMMENDING authorization servers are to
> issue such tokens, are we?

I removed the sentence are a result of the wg discussion that followed.

> 10.3. Access Token Credentials
> 
>The client SHOULD request access token credentials with the minimal
>scope and duration necessary.
> 
> Is this enfoced by the authorization server?

Not sure how this would be possible. The server can later review what is being 
used, but not predict.

> 10.9. Authorization Codes
> 
>Authorization codes SHOULD be short lived and MUST be single use.  If
>the authorization server observes multiple attempts to exchange an
>authorization code for an access token, the authorization server
>SHOULD revoke all access tokens already granted based on the
>compromised authorization code.
> 
> Is there a good reason why the authorization server would not revoke all the
> access tokens? If not, change to MUST.

See above.

Changed it to 'SHOULD attempt' for now.

> MINOR ISSUES...
> 
> 1.4.1. Authorization Code
> 
> OLD:
>Before directing the resource owner back to the client with the
>authorization code, the authorization server authenticates the
>resource owner and obtains authorization.  Because the resource owner
>only authenticates with the authorization server, the resource
>owner's credentials are never shared with the client.
> 
> NEW:
>Before directing the resource owner back to the client with the
>authorization code, the authorization server authenticates the
>resource owner and obtains authorization.  Because the resource owner
>only authenticates with the authorization server, the resource
>owner's credentials at the resource server are never shared with the
>client.
> 
> RATIONALE: could the resource owner have credentials at the authorization
> server?

The credentials are always with the authorization server, and the resource 
server either has access to the credentials, to the server for validation, or 
relies on cookies and other non-standard credentials replacements.

> 4.1.2.1. Error Response
> 
> OLD:
>error_description
>  OPTIONAL.  A human-readable text providing additional
>  information, used to assist in the understanding and resolution
>  of the error occurred. [[ add language and encoding information
>  ]]
> 
> NEW:
>error_description
>  OPTIONAL.  Descriptive text providing additional information

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Eran Hammer-Lahav]

If this is an implicit grant, using the redirection URI registered before. If 
this is the authorization code, the server knows that the client will have to 
present a secret later to get access, so it can make that information available 
with confidence. If someone else is asking using a stole identifier, they will 
not go far without the secret, and the user data will remain safe.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-lucent.com]
Sent: Thursday, June 16, 2011 12:51 PM
To: Eran Hammer-Lahav; 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'; 'Brian 
Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

> If you can't validate the client identifier, you should not show the user any 
> information about the client that you cannot vouch for.
According to the flow described in section 1.2, authorization by the resource 
owner (user) is done before the authorization server authenticates the client.
How authorization server can validate the client's identifier before 
authenticating the client?

Zachary

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, June 16, 2011 1:52 PM
To: Zeltsan, Zachary (Zachary); 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'; 
'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16
This is nice on paper but doesn't work.

The user will see the client name or logo and will not read any of the fine 
print. We know this as a fact. If you can't validate the client identifier, you 
should not show the user any information about the client that you cannot vouch 
for. Disclaimers and scary pages are useless.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-lucent.com]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Brian 
Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree with the statement. Authorization server provides information about a 
client to a user based on the client's identifier, which client has presented 
to the server. If authorization server cannot validate the client's identity 
claim, it must make the user aware.


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe a client to the user does not depend on the 
authentication but on the identification of the client and the meta data 
available to the authz server. The only difference between identified and 
authenticated clients is the trust level the authz server has regarding the 
client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the _user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Eran Hammer-Lahav]

The user should be informed and in control, but there is a limit to how much 
information you can give with confidence. My point is that it is really hard to 
provide the user with trustworthy information without client registration and 
secure client credentials or pre-registered callback.

If you have a client identifier without secret (via the authentication code) or 
registered callback, that client identifier is useless and must not be used.

EHL

From: tors...@lodderstedt.net [mailto:tors...@lodderstedt.net]
Sent: Thursday, June 16, 2011 11:24 AM
To: Eran Hammer-Lahav; Lodderstedt, Torsten; Brian Eaton
Cc: OAuth WG
Subject: AW: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I thought keeping the user informed and in control are core principles of 
oAuth? Do you suggest not informing the user is better than stating something 
like: "the client should be XXX, accept the request only if you are sure "

regards,
Torsten.

Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland


From: Eran Hammer-Lahav 
Date: Thu, 16 Jun 2011 08:32:55 -0700
To: Lodderstedt, Torsten; Torsten 
Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Easier said than done. If you don't have strong trust, giving the user hints 
will cause more harm than good.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: AW: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The ability to describe a client to the user does not depend on the 
authentication but on the identification of the client and the meta data 
available to the authz server. The only difference between identified and 
authenticated clients is the trust level the authz server has regarding the 
client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the_user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user 
authentication to anything stronger than a password.  Client certificates, one 
time passwords, risk based authentication, throw it all out t

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Zeltsan, Zachary (Zachary)]

> If you can't validate the client identifier, you should not show the user any 
> information about the client that you cannot vouch for.
According to the flow described in section 1.2, authorization by the resource 
owner (user) is done before the authorization server authenticates the client.
How authorization server can validate the client's identifier before 
authenticating the client?

Zachary

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, June 16, 2011 1:52 PM
To: Zeltsan, Zachary (Zachary); 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'; 
'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

This is nice on paper but doesn't work.

The user will see the client name or logo and will not read any of the fine 
print. We know this as a fact. If you can't validate the client identifier, you 
should not show the user any information about the client that you cannot vouch 
for. Disclaimers and scary pages are useless.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-lucent.com]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Brian 
Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree with the statement. Authorization server provides information about a 
client to a user based on the client's identifier, which client has presented 
to the server. If authorization server cannot validate the client's identity 
claim, it must make the user aware.


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe a client to the user does not depend on the 
authentication but on the identification of the client and the meta data 
available to the authz server. The only difference between identified and 
authenticated clients is the trust level the authz server has regarding the 
client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the _user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issue

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Brian Eaton]

On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav wrote:

> This is nice on paper but doesn’t work.
>

I have to agree.  It doesn't matter what the spec says on this point.  No
one is going to take advice from the spec about what the text on their
approval page ought to say.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Eran Hammer-Lahav]

This is nice on paper but doesn't work.

The user will see the client name or logo and will not read any of the fine 
print. We know this as a fact. If you can't validate the client identifier, you 
should not show the user any information about the client that you cannot vouch 
for. Disclaimers and scary pages are useless.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-lucent.com]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Brian 
Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree with the statement. Authorization server provides information about a 
client to a user based on the client's identifier, which client has presented 
to the server. If authorization server cannot validate the client's identity 
claim, it must make the user aware.


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe a client to the user does not depend on the 
authentication but on the identification of the client and the meta data 
available to the authz server. The only difference between identified and 
authenticated clients is the trust level the authz server has regarding the 
client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the _user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user 
authentication to anything stronger than a password.  Client certificates, one 
time passwords, risk based authentication, throw it all out the window.  If 
you're going to let installed apps authenticate with just a password, nothing 
else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, 
and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They 

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Zeltsan, Zachary (Zachary)]

I agree with the statement. Authorization server provides information about a 
client to a user based on the client's identifier, which client has presented 
to the server. If authorization server cannot validate the client's identity 
claim, it must make the user aware.


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The ability to describe a client to the user does not depend on the 
authentication but on the identification of the client and the meta data 
available to the authz server. The only difference between identified and 
authenticated clients is the trust level the authz server has regarding the 
client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the _user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user 
authentication to anything stronger than a password.  Client certificates, one 
time passwords, risk based authentication, throw it all out the window.  If 
you're going to let installed apps authenticate with just a password, nothing 
else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, 
and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are important, 
and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credentials 
to native apps.  That's not practical.  Native apps end up needing permanent or 
near-permanent credentials.  Expirations need to be measured in months.  And 
the credentials are going to be issued to stock IMAP and XMPP clients that 
don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they 
are restricted to authorization se

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Eran Hammer-Lahav]

Easier said than done. If you don't have strong trust, giving the user hints 
will cause more harm than good.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: AW: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The ability to describe a client to the user does not depend on the 
authentication but on the identification of the client and the meta data 
available to the authz server. The only difference between identified and 
authenticated clients is the trust level the authz server has regarding the 
client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the _user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user 
authentication to anything stronger than a password.  Client certificates, one 
time passwords, risk based authentication, throw it all out the window.  If 
you're going to let installed apps authenticate with just a password, nothing 
else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, 
and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are important, 
and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credentials 
to native apps.  That's not practical.  Native apps end up needing permanent or 
near-permanent credentials.  Expirations need to be measured in months.  And 
the credentials are going to be issued to stock IMAP and XMPP clients that 
don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they 
are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create 
flows that bridge from those managed credentials to temporary access 
credentials.

Cheers,
Brian

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Lodderstedt, Torsten]

The ability to describe a client to the user does not depend on the 
authentication but on the identification of the client and the meta data 
available to the authz server. The only difference between identified and 
authenticated clients is the trust level the authz server has regarding the 
client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the _user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user 
authentication to anything stronger than a password.  Client certificates, one 
time passwords, risk based authentication, throw it all out the window.  If 
you're going to let installed apps authenticate with just a password, nothing 
else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, 
and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are important, 
and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credentials 
to native apps.  That's not practical.  Native apps end up needing permanent or 
near-permanent credentials.  Expirations need to be measured in months.  And 
the credentials are going to be issued to stock IMAP and XMPP clients that 
don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they 
are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create 
flows that bridge from those managed credentials to temporary access 
credentials.

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Eran Hammer-Lahav]

I agree to the extent that the user can be trusted to know how they got to the 
authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in 
the information it can offer the user to make the decision. It is extremely 
hard to come up with language that will tell the user to only approve the 
application, claiming to be X, if they got here from X directly. There might be 
ways to improve security a bit using Origin header etc. but overall, if the 
client is not authenticated, the authorization server can't really describe it 
to the user.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at 
all. If we would follow this line, every e-Mail client out there would be 
considered insecure because the client itself is never authenticated. Not even 
Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see a 
degration in security if it is not applicable. As long as the _user_ authorizes 
the client's access (and the duration of the token) and is able to revoke the 
tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user 
authentication to anything stronger than a password.  Client certificates, one 
time passwords, risk based authentication, throw it all out the window.  If 
you're going to let installed apps authenticate with just a password, nothing 
else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, 
and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are important, 
and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credentials 
to native apps.  That's not practical.  Native apps end up needing permanent or 
near-permanent credentials.  Expirations need to be measured in months.  And 
the credentials are going to be issued to stock IMAP and XMPP clients that 
don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they 
are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create 
flows that bridge from those managed credentials to temporary access 
credentials.

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Torsten Lodderstedt]

Got it. End-user authentication via USIM is indeed secure (and convenient).

regards,
Torsten.



Igor Faynberg  schrieb:

As far the authentication goes, what I had in mind was that the network 
provider could authenticate the end-user. Alternatively, an application 
(not necessarily the USIM) on the smart card could hold the secret and 
perform all cryptographic operations (what Thomas calls crypto-store). 
In either case, only the provider and the card would share the secret.

Igor

Torsten Lodderstedt wrote:
> in my opinion, the problem with client authentication is more the 
> secure distribution of the secret than the storage. How should a USIM 
> help here?
>
> regards,
> Torsten.
>
>
>
> Thomas Hardjono  schrieb:
>
> Thanks Igor,
>
> If you bring smartcards into the picture, then it's a different
> ballgame :)
>
> If mobile phones are assumed to have smartcards (which is increasingly
> true today via USIMs), then OAUTH can assume that native apps (running
> on the phones) may have access to crypto-store. In this case the text
> in Section 9 of draft-16 would needs changes/clarifications.
>
> /thomas/
>
>
> __
>
> > -Original Message-
> > From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
> > Sent: Thursday, June 02, 2011 3:31 PM
> > To: Thomas Hardjono
> > Cc: Torsten Lodderstedt; OAuth WG
> > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
> > 
> > Actually, for the devices that use smart cards (mobile devices, in
> > particular), this assumption is quite appropriate.>
>
> > Igor
> > 
> > Thomas Hardjono wrote:
> > >> 
> > > ...
> > >
> > > However, there is indeed the assumption in Kerberos/RFC4120 (and
> in
> > the original Needham-Schroeder protocol) that the "client" can keep
> > secrets.
> > >
> > > /thomas/
> > >
> > >
> > >
> > >
>_

>
> > >
> > >
> 
>

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

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Peter Saint-Andre]

On 6/2/11 8:38 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre  > wrote:
> 
> I'm not thinking about your use case, but things like enterprise
> deployments in high-security environments where every person and every
> software application has a certificate or is otherwise provisioned for
> authentication with the authorization server.
> 
> 
> I actually care quite a bit about that use case. =)

I'm happy to hear it. There are so many interesting use cases in the
world, aren't there? ;-)

> However, I'm not saying we should change or add any text to the spec,
> because the SHOULD allows such deployments to not issue tokens to
> clients that are incapable of authenticating. So I don't particularly
> see a reason to keep discussing the matter.
> 
> 
> OK, I understand the confusion now.
> 
> I'm going to continue to push for the security considerations to be
> broken up more cleanly by use case, in part to avoid confusion like this.

Probably a good idea.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Brian Eaton]

On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre wrote:

> I'm not thinking about your use case, but things like enterprise
> deployments in high-security environments where every person and every
> software application has a certificate or is otherwise provisioned for
> authentication with the authorization server.
>

I actually care quite a bit about that use case. =)


> However, I'm not saying we should change or add any text to the spec,
> because the SHOULD allows such deployments to not issue tokens to
> clients that are incapable of authenticating. So I don't particularly
> see a reason to keep discussing the matter.


OK, I understand the confusion now.

I'm going to continue to push for the security considerations to be broken
up more cleanly by use case, in part to avoid confusion like this.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Peter Saint-Andre]

On 6/2/11 6:48 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre  > wrote:
> 
> I think the SHOULD we had originally is probably fine -- with the
> understanding that "SHOULD" means "you really ought to do this unless
> you have a good reason not to". I think one such really good reason
> might be a authorization server that doesn't allow unauthenticated
> clients (i.e., clients that are not pre-registered or don't have
> certificates or whatever).
> 
> 
> Really?  What are you thinking of as "limited duration" credentials for
> a desktop application?

I'm not thinking about your use case, but things like enterprise
deployments in high-security environments where every person and every
software application has a certificate or is otherwise provisioned for
authentication with the authorization server.

However, I'm not saying we should change or add any text to the spec,
because the SHOULD allows such deployments to not issue tokens to
clients that are incapable of authenticating. So I don't particularly
see a reason to keep discussing the matter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Brian Eaton]

On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre wrote:

> I think the SHOULD we had originally is probably fine -- with the
> understanding that "SHOULD" means "you really ought to do this unless
> you have a good reason not to". I think one such really good reason
> might be a authorization server that doesn't allow unauthenticated
> clients (i.e., clients that are not pre-registered or don't have
> certificates or whatever).


Really?  What are you thinking of as "limited duration" credentials for a
desktop application?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Peter Saint-Andre]

On 6/2/11 4:11 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre  > wrote:
> 
> I think I might have misunderstood that text -- I took it to be talking
> about the client's authentication with the authorization server, not the
> client's authentication with the resource server.
> 
> 
> No, you understand perfectly.  We're talking about giving extremely
> powerful and near-permanent credentials to clients we can't
> authenticate.  We're pretty sure this is a good idea. =)
> 
> We authenticate the user and get their consent.  If they say yes, the
> client gets something that is almost, but not quite, equivalent to an
> alternate password for the user.

Sure, that's the classic OAuth pattern.

I think the SHOULD we had originally is probably fine -- with the
understanding that "SHOULD" means "you really ought to do this unless
you have a good reason not to". I think one such really good reason
might be a authorization server that doesn't allow unauthenticated
clients (i.e., clients that are not pre-registered or don't have
certificates or whatever).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Brian Eaton]

On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre wrote:

> I think I might have misunderstood that text -- I took it to be talking
> about the client's authentication with the authorization server, not the
> client's authentication with the resource server.


No, you understand perfectly.  We're talking about giving extremely powerful
and near-permanent credentials to clients we can't authenticate.  We're
pretty sure this is a good idea. =)

We authenticate the user and get their consent.  If they say yes, the client
gets something that is almost, but not quite, equivalent to an alternate
password for the user.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Peter Saint-Andre]

On 6/1/11 1:06 PM, Brian Eaton wrote:
> Hey Peter - 
> 
> I haven't read all of your comments yet, but I wanted to clarify one
> point about client impersonation and installed apps.  The cuirrent text
> is unrealistic, but your request would push it the wrong way.  CC'ing
> Torsten as well.
> 
> -
> OLD:
>   The authorization server SHOULD issue access tokens with limited
>   scope and duration to clients incapable of authenticating.
> 
> NEW:
>   If the authorization server issues access tokens to clients
>   that are incapable of authenticating, the scope and duration of
>   such tokens SHOULD be limited.
> 
> RATIONALE: We're not actively RECOMMENDING authorization servers are to
> issue such tokens, are we?
> -
> 
> We are most definitely recommending that clients that have no way of
> authenticating are issued long-lived credentials to access user data.

I think I might have misunderstood that text -- I took it to be talking
about the client's authentication with the authorization server, not the
client's authentication with the resource server.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Dave Nelson]

On Thu, Jun 2, 2011 at 4:24 PM, Thomas Hardjono  wrote:

> Oh ok, now I get what "authenticating the client" means here. My bad.
> Perhaps the term "authenticating" is not accurate. Maybe "integrity
> verification" of client code is a better phrase.

It *may* include integrity verification of the client binary, but in
the use cases I'm envisioning it's more a verification of the identity
of the application publisher, and that the publisher has a business
relationship with the OAuth authorization provider, such as a
developer registration.  In some case that matters.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Igor Faynberg]

As far the authentication goes, what I had in mind was that the network 
provider could authenticate  the end-user. Alternatively, an application 
(not necessarily the USIM) on the smart card could hold the secret and 
perform all cryptographic operations (what Thomas calls crypto-store). 
In either case, only the provider and the card would share the secret.


Igor

Torsten Lodderstedt wrote:
in my opinion, the problem with client authentication is more the 
secure distribution of the secret than the storage. How should a USIM 
help here?


regards,
Torsten.



Thomas Hardjono  schrieb:

Thanks Igor,

If you bring smartcards into the picture, then it's a different
ballgame :)

If mobile phones are assumed to have smartcards (which is increasingly
true today via USIMs), then OAUTH can assume that native apps (running
on the phones) may have access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.

/thomas/


__

> -Original Message-
> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
> Sent: Thursday, June 02, 2011 3:31 PM
> To: Thomas Hardjono
> Cc: Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
> 
> Actually, for the devices that use smart cards (mobile devices, in

> particular), this assumption is quite appropriate.>

> Igor
> 
> Thomas Hardjono wrote:

> >> 
> > ...
> >
> > However, there is indeed the assumption in Kerberos/RFC4120 (and
in
> the original Needham-Schroeder protocol) that the "client" can keep
> secrets.
> >
> > /thomas/
> >
> >
> >
> >


> >
> >



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

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Igor Faynberg]

Absolutely!  In fact, client_id,  should be presumed to be TOTALLY 
different from the USIM (or ISIM) ID.  The correlation of IDs is the 
network's job. (Hui-Lan and I, along with two other researchers, 
described how this can be done in a Bell Labs Technical Journal paper: 
http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/pdf.)


Igor

Phillip Hunt wrote:
The notion of client instance ids (eg as suggested) by USIMs suggested may be a slightly different identify then envisioned by client_id. 

I have mentioned the same issue before of identifying software separately from deployment instances which such a strong credential would map to. 

They likely has to be addressed post 2.0. 


Phil

On 2011-06-02, at 13:13, Thomas Hardjono  wrote:

  

Thanks Igor,

If you bring smartcards into the picture, then it's a different
ballgame :)

If mobile phones are assumed to have smartcards (which is increasingly
true today via USIMs), then OAUTH can assume that native apps (running
on the phones) may have access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.

/thomas/


__



-Original Message-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 3:31 PM
To: Thomas Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Actually, for the devices that use smart cards (mobile devices, in
particular), this assumption is quite appropriate.

Igor

Thomas Hardjono wrote:
  


  

...

However, there is indeed the assumption in Kerberos/RFC4120 (and


in


the original Needham-Schroeder protocol) that the "client" can keep
secrets.
  

/thomas/



___




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


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

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Torsten Lodderstedt]

in my opinion, the problem with client authentication is more the secure 
distribution of the secret than the storage. How should a USIM help here?

regards,
Torsten.



Thomas Hardjono  schrieb:

Thanks Igor,

If you bring smartcards into the picture, then it's a different
ballgame :)

If mobile phones are assumed to have smartcards (which is increasingly
true today via USIMs), then OAUTH can assume that native apps (running
on the phones) may have access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.

/thomas/


__

> -Original Message-
> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
> Sent: Thursday, June 02, 2011 3:31 PM
> To: Thomas Hardjono
> Cc: Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
> 
> Actually, for the devices that use smart cards (mobile devices, in
> particular), this assumption is quite appropriate.
> 
> Igor
> 
> Thomas Hardjono wrote:
> >> 
> > ...
> >
> > However, there is indeed the assumption in Kerberos/RFC4120 (and
in
> the original Needham-Schroeder protocol) that the "client" can keep
> secrets.
> >
> > /thomas/
> >
> >
> >
> >_

> >
> >

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

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Thomas Hardjono]

> __
> 
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Thursday, June 02, 2011 3:45 PM
> To: Thomas Hardjono
> Cc: Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
> 
> On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono 
> wrote:
> Well, not to belabor this point :)  but in Kerberos it is the proof of
> possession of the client secret key which _is_ the authentication
> mechanism. There is also PKINIT (RFC4556) which can be used to "pre-
> authenticate" the user via Diffie-Hellman (anonymous) or a full X509
> certificate.
> 
> The kerberos notion of "client" is not the same thing as the OAuth
> notion of "client".  The "client" in kerberos maps to the OAuth
> "user".  The "client" in OAuth is the application the user is using.
> 
> Kerberos does not, for example, try to authenticate the kinit
> binary.  It just tries to authenticate the person using the kinit
> binary.

Oh ok, now I get what "authenticating the client" means here. My bad. Perhaps 
the term "authenticating" is not accurate. Maybe "integrity verification" of 
client code is a better phrase.

And yes, integrity-verification of the kinit binary in MIT Kerberos is not 
performed prior to execution (in Linux-based systems). 

Actually, generally speaking integrity-verification of binaries (either in 
store/disk or during run-time) is not the job of a client code like kinit. The 
OS should be doing this.

Thanks.

/thomas/




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

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Phillip Hunt]

The notion of client instance ids (eg as suggested) by USIMs suggested may be a 
slightly different identify then envisioned by client_id. 

I have mentioned the same issue before of identifying software separately from 
deployment instances which such a strong credential would map to. 

They likely has to be addressed post 2.0. 

Phil

On 2011-06-02, at 13:13, Thomas Hardjono  wrote:

> Thanks Igor,
> 
> If you bring smartcards into the picture, then it's a different
> ballgame :)
> 
> If mobile phones are assumed to have smartcards (which is increasingly
> true today via USIMs), then OAUTH can assume that native apps (running
> on the phones) may have access to crypto-store. In this case the text
> in Section 9 of draft-16 would needs changes/clarifications.
> 
> /thomas/
> 
> 
> __
> 
>> -Original Message-
>> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
>> Sent: Thursday, June 02, 2011 3:31 PM
>> To: Thomas Hardjono
>> Cc: Torsten Lodderstedt; OAuth WG
>> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
>> 
>> Actually, for the devices that use smart cards (mobile devices, in
>> particular), this assumption is quite appropriate.
>> 
>> Igor
>> 
>> Thomas Hardjono wrote:
>>>> 
>>> ...
>>> 
>>> However, there is indeed the assumption in Kerberos/RFC4120 (and
> in
>> the original Needham-Schroeder protocol) that the "client" can keep
>> secrets.
>>> 
>>> /thomas/
>>> 
>>> 
>>> 
>>> ___
>>> 
>>> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Thomas Hardjono]

Thanks Igor,

If you bring smartcards into the picture, then it's a different
ballgame :)

If mobile phones are assumed to have smartcards (which is increasingly
true today via USIMs), then OAUTH can assume that native apps (running
on the phones) may have access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.

/thomas/


__

> -Original Message-
> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
> Sent: Thursday, June 02, 2011 3:31 PM
> To: Thomas Hardjono
> Cc: Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
> 
> Actually, for the devices that use smart cards (mobile devices, in
> particular), this assumption is quite appropriate.
> 
> Igor
> 
> Thomas Hardjono wrote:
> >> 
> > ...
> >
> > However, there is indeed the assumption in Kerberos/RFC4120 (and
in
> the original Needham-Schroeder protocol) that the "client" can keep
> secrets.
> >
> > /thomas/
> >
> >
> >
> > ___
> >
> >


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Brian Eaton]

On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono  wrote:

> Well, not to belabor this point :)  but in Kerberos it is the proof of
> possession of the client secret key which _is_ the authentication mechanism.
> There is also PKINIT (RFC4556) which can be used to "pre-authenticate" the
> user via Diffie-Hellman (anonymous) or a full X509 certificate.
>

The kerberos notion of "client" is not the same thing as the OAuth notion of
"client".  The "client" in kerberos maps to the OAuth "user".  The "client"
in OAuth is the application the user is using.

Kerberos does not, for example, try to authenticate the kinit binary.  It
just tries to authenticate the person using the kinit binary.

Kerberos does have a notion of forwardable service tickets that authenticate
both the user and the service they are using; that's a much closer match to
what OAuth2 does.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Igor Faynberg]

Actually, for the devices that use smart cards (mobile devices, in 
particular), this assumption is quite appropriate. 


Igor

Thomas Hardjono wrote:



...

However, there is indeed the assumption in Kerberos/RFC4120 (and in the original 
Needham-Schroeder protocol) that the "client" can keep secrets.

/thomas/



___

  

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

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Thomas Hardjono]

> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Thursday, June 02, 2011 5:10 AM
> To: Brian Eaton
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
> 
> I fully agree with Brian and would like to add some thoughts:
> 
> Not authenticating the client does not directly create a security
> problem at all. If we would follow this line, every e-Mail client out
> there would be considered insecure because the client itself is never
> authenticated. Not even Kerbereos has a concept of client
> authentication.

Well, not to belabor this point :)  but in Kerberos it is the proof of 
possession of the client secret key which _is_ the authentication mechanism. 
There is also PKINIT (RFC4556) which can be used to "pre-authenticate" the user 
via Diffie-Hellman (anonymous) or a full X509 certificate.

However, there is indeed the assumption in Kerberos/RFC4120 (and in the 
original Needham-Schroeder protocol) that the "client" can keep secrets.

/thomas/



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

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Zeltsan, Zachary (Zachary)]

I agree with Brian.
One of the use cases that relies on the issuing tokens to an unauthenticated 
client is Mobile App 
(http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01#section-3.4). A 
use case's requirement is that "authorization shall be valid for a prolonged 
duration". Such long-term  authorization relies on the use of the refresh 
tokens.

Zachary


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian 
Eaton
Sent: Wednesday, June 01, 2011 3:06 PM
To: Peter Saint-Andre
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point 
about client impersonation and installed apps.  The cuirrent text is 
unrealistic, but your request would push it the wrong way.  CC'ing Torsten as 
well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user 
authentication to anything stronger than a password.  Client certificates, one 
time passwords, risk based authentication, throw it all out the window.  If 
you're going to let installed apps authenticate with just a password, nothing 
else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, 
and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are important, 
and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credentials 
to native apps.  That's not practical.  Native apps end up needing permanent or 
near-permanent credentials.  Expirations need to be measured in months.  And 
the credentials are going to be issued to stock IMAP and XMPP clients that 
don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they 
are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create 
flows that bridge from those managed credentials to temporary access 
credentials.

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Torsten Lodderstedt]

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security 
problem at all. If we would follow this line, every e-Mail client out 
there would be considered insecure because the client itself is never 
authenticated. Not even Kerbereos has a concept of client authentication.


In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see 
a degration in security if it is not applicable. As long as the _user_ 
authorizes the client's access (and the duration of the token) and is 
able to revoke the tokens at any time, the situation is much better than 
with classical approaches.


regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:

Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one 
point about client impersonation and installed apps.  The cuirrent 
text is unrealistic, but your request would push it the wrong way. 
 CC'ing Torsten as well.


-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of 
authenticating are issued long-lived credentials to access user data.


Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot 
upgrade user authentication to anything stronger than a password. 
 Client certificates, one time passwords, risk based authentication, 
throw it all out the window.  If you're going to let installed apps 
authenticate with just a password, nothing else you do to improve 
authentication is going to help.


This is a blocking issue for rolling out stronger forms of user 
authentication, and it's one of the main reasons I care about OAuth2.


Think IMAP and XMPP clients running on Windows desktops.  They are 
important, and we need a way to migrate them off of saving passwords.


So the current text basically says that you should issue temporary 
credentials to native apps.  That's not practical.  Native apps end up 
needing permanent or near-permanent credentials.  Expirations need to 
be measured in months.  And the credentials are going to be issued to 
stock IMAP and XMPP clients that don't have any way of authenticating 
themselves.


The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP 
servers, they are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can 
create flows that bridge from those managed credentials to temporary 
access credentials.


Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

[Brian Eaton]

Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point
about client impersonation and installed apps.  The cuirrent text is
unrealistic, but your request would push it the wrong way.  CC'ing Torsten
as well.

-
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
-

We are most definitely recommending that clients that have no way of
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user
authentication to anything stronger than a password.  Client certificates,
one time passwords, risk based authentication, throw it all out the window.
 If you're going to let installed apps authenticate with just a password,
nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user
authentication, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are
important, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary
credentials to native apps.  That's not practical.  Native apps end up
needing permanent or near-permanent credentials.  Expirations need to be
measured in months.  And the credentials are going to be issued to stock
IMAP and XMPP clients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers,
they are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create
flows that bridge from those managed credentials to temporary access
credentials.

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] review of draft-ietf-oauth-v2-16

[Peter Saint-Andre]

Last week I completed a review of draft-ietf-oauth-v2-16. Here are some
comments.

MAJOR ISSUES...

Throughout the document, the various parameters (e.g., client_secret and
client_id) are essentially undefined. There is no text about the length
of these parameters, the allowable characters (e.g., alpha and digits
only, all ASCII characters, full Unicode), internationalization
considerations, preparation and comparison of strings, etc. I don't see
how developers will build interoperable implementations without clear
guidance here.

Also, the scope parameter still strike me as extremly vague. Can we at
least define the word "scope" and provide a few examples of how the
parameter might be used?

No rules are provided for URI matching (e.g., in Section 4.1 the
redirection URI received needs to be checked against the URI used to
redirect the client, but not guidance is provided). Perhaps a reference
to RFC 3986 is in order here. Here also internationalization concerns
might need to be covered (e.g., are IRIs allowed?).

4.1.2. Authorization Response

OLD:
 If an
 authorization code is used more than once, the authorization
 server MAY revoke all tokens previously issued based on that
 authorization code.

NEW:
 If an
 authorization code is used more than once, the authorization
 server SHOULD revoke all tokens previously issued based on that
 authorization code.

RATIONALE: MAY seems weak here.

10.2. Client Impersonation

   The authorization server SHOULD require the client to pre-register
   its redirection URI and validate the value of the "redirect_uri"
   against the pre-registered value.

How does this validation occur?

OLD:
   The authorization server SHOULD issue access tokens with limited
   scope and duration to clients incapable of authenticating.

NEW:
   If the authorization server issues access tokens to clients
   that are incapable of authenticating, the scope and duration of
   such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?

10.3. Access Token Credentials

   The client SHOULD request access token credentials with the minimal
   scope and duration necessary.

Is this enfoced by the authorization server?

10.6. Endpoints Authenticity

   In order to prevent man-in-the-middle and phishing attacks, the
   authorization server MUST implement and require TLS with server-side
   authentication in all exchanges.  The client MUST verify the
   authorization server's TLS certificate, as well as the respective
   certificate chain.

We need a reference to RFC 2818 here since it defines server
verification procedures for HTTP. (Same for Section 10.8.)

10.9. Authorization Codes

   Authorization codes SHOULD be short lived and MUST be single use.  If
   the authorization server observes multiple attempts to exchange an
   authorization code for an access token, the authorization server
   SHOULD revoke all access tokens already granted based on the
   compromised authorization code.

Is there a good reason why the authorization server would not revoke all
the access tokens? If not, change to MUST.

MINOR ISSUES...

1.4.1. Authorization Code

OLD:
   Before directing the resource owner back to the client with the
   authorization code, the authorization server authenticates the
   resource owner and obtains authorization.  Because the resource owner
   only authenticates with the authorization server, the resource
   owner's credentials are never shared with the client.

NEW:
   Before directing the resource owner back to the client with the
   authorization code, the authorization server authenticates the
   resource owner and obtains authorization.  Because the resource owner
   only authenticates with the authorization server, the resource
   owner's credentials at the resource server are never shared with the
   client.

RATIONALE: could the resource owner have credentials at the
authorization server?

1.4.2. Implicit

OLD:
   Implicit grants improve the responsiveness and efficiency of some
   clients (such as a client implemented as an in-browser application)
   since it reduces the number of round trips required to obtain an
   access token.

NEW:
   Implicit grants improve the responsiveness and efficiency of some
   clients (such as a client implemented as an in-browser application)
   since they reduce the number of round trips required to obtain an
   access token.  However, service providers need to weigh this
   convenience against the security properties of implicit grants
   (e.g., the fact that client authentication is not possible).

RATIONALE: I think it would be good to mention that there's a balance
here between convenience and security.

1.7 Notational Conventions

I think it would be good to add an informational reference to RFC 4949
here, and to check our usage of certain terms against the definitions in
that spec. Proposed text:

   Ce