fix.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, July 06, 2011 10:20 PM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
Very helpful.
EHL
From: Brian Eaton [mailto:bea...@google.c
Very helpful.
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Thursday, June 16, 2011 8:38 AM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav
mailto:e...@hueniverse.com
One might argue these are deployment-time considerations rather than spec
issues.
From: Thomas Hardjono
To: Shane B Weeden/Australia/IBM@IBMAU
Cc: "oauth@ietf.org"
Date: 21-06-11 04:03 AM
Subject: RE: [OAUTH-WG] Client authentication requirement
> Fro
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Friday, June 17, 2011 11:31 AM
> To: Shane B Weeden; Dave Nelson
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> Shane B Wee
guessing attacks on authz
codes and refresh tokens (beside high entropy and short duration)
- it might make token theft more difficult given the secret is stored
somewhere/somehow else than the refresh tokens
regards,
Torsten.
>
>
>
>
>
>From: Dave Nelson
>To:Brian E
ps from a compromised refresh token, but the usefulness of
that idea has been debated as well.
From: Dave Nelson
To: Brian Eaton
Cc: "oauth@ietf.org"
Date: 17-06-11 09:45 PM
Subject:Re: [OAUTH-WG] Client authentication requirement
Sent by:oauth-boun...@
> If you aren't willing to accept the risk of native apps that can't keep
> secrets, don't support such apps.
We continue to say "can't keep secrets". I think what we mean is
"can't keep secrets that are embedded in the code". One could imagine
an install-time, leap-of-faith binding to a remotel
On Thu, Jun 16, 2011 at 2:14 PM, Igor Faynberg <
igor.faynb...@alcatel-lucent.com> wrote:
> **
>
>
> On 6/16/2011 4:51 PM, Brian Eaton wrote:
>
> On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> If those people have reasonable means in place to protect
I agree with the factual information, but I disagree with the conclusion.
Indeed, there were postings from people who will "bake secrets into
installed applications." But there have also been postings from people
(like Torsten and me) who said they "will use real secrets and rely on
them."
On 6/16/2011 4:51 PM, Brian Eaton wrote:
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
If those people have reasonable means in place to protect secrets
on deployment channels and in the local installation - fine. I
would be eager to
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> If those people have reasonable means in place to protect secrets on
> deployment channels and in the local installation - fine. I would be eager
> to learn more about those means because I would be wille
Am 16.06.2011 22:30, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
no I'm saying people will use real secrets and rely on them - just
as with OAuth 1.0
=)
People are going to ignore what the spec says on this. If yo
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> no I'm saying people will use real secrets and rely on them - just as with
> OAuth 1.0
>
=)
People are going to ignore what the spec says on this. If you read through
the mailing list threads on this t
no I'm saying people will use real secrets and rely on them - just as
with OAuth 1.0
Am 16.06.2011 22:20, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
No, it's not simpler nor clearer. Such a client secret is useless,
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> No, it's not simpler nor clearer. Such a client secret is useless, so the
> security implications have to be explained anyway.
>
The issue really isn't the security implications being unclear; the issue
> > Certainly not. Are we discussing to make client
> > authentication required just for syntactical purposes?
> >
> > That is what I'd like to see.
> >
> >
> > From my perspective, no harm is done by making client authentication
> > a syntactical requirement of the protocol.
>
Am 16.06.2011 22:02, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
Certainly not. Are we discussing to make client authentication
required just for syntactical purposes?
That is what I'd like to see.
From my persp
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> Certainly not. Are we discussing to make client authentication required
> just for syntactical purposes?
>
That is what I'd like to see.
>From my perspective, no harm is done by making client authentic
Certainly not. Are we discussing to make client authentication required
just for syntactical purposes?
To me, "notasecret" logically means to abandon on client authentication.
regards,
Torsten.
Am 16.06.2011 21:46, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt
mai
lto:oauth-boun...@ietf.org] On Behalf
> >> Of Eran Hammer-Lahav
> >> Sent: Wednesday, June 15, 2011 1:27 PM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] Client authentication requirement
> >>
> >> Client authentication has been one of the main problem ar
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> -1 making client authentication required at the access token endpoint
>
> Client authentication is useful in some situations to raise the security
> level. But requiring it will either keep out native apps or
mmer-Lahav
Sent: Wednesday, June 15, 2011 1:27 PM
To: OAuth WG
Subject: [OAUTH-WG] Client authentication requirement
Client authentication has been one of the main problem areas in OAuth
1.0 and 2.0 does nothing to resolve it (arguably, it makes it more
confusing).
Because of the desire to allow
What seems to be missing in the discussion and the security considerations
of the spec is a decent list of general and grant-type-specific security
implications/pros/cons for the system if meaningful client authentication
at the token endpoint is available or not available.
What about this?
On Thu, Jun 16, 2011 at 8:48 AM, Thomas Hardjono wrote:
> >>> Requiring client authentication doesn't defend against
> >>> attacks directly; it makes recovery after a successful
> >>> attack easier.
>
> I presume you mean direct attacks on the authorization server.
>
Also attacks on the clients.
org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, June 15, 2011 9:19 PM
> To: Brian Eaton
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> Your comment was that having client authentication makes it easier to
> recovery from an attack.
On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav wrote:
> Your comment was that having client authentication makes it easier to
> recovery from an attack. I don’t understand how the comments below about
> changing client secrets every 30 days are relevant. Are you suggesting to
> wait until the
Apologies for the late response.
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, June 15, 2011 1:27 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Client authentication requirement
>
> Client authentication has
Brian Eaton wrote on 16-06-2011 10:36:18 AM:
> From: Brian Eaton
> To: Shane B Weeden/Australia/IBM@IBMAU
> Cc: OAuth WG
> Date: 16-06-11 10:49 AM
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden
wro
s? Or that 30 days is a
reasonable time period for ignoring an attack?
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 6:15 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
On Wed, Jun 15, 2011 at 6:
On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav wrote:
> How does it make recovery easier? Why is revoking refresh token any harder
> than changing client secret?
>
Changing a client secret can be done without disrupting users. You can even
schedule it, do it every 30 days as part of your gen
?
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 5:33 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav
mailto:e...@hueniverse.com>> wro
On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden wrote:
> Brain - can you elaborate on that a little? Are you suggesting that clients
> that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy
> "requiring client authentication"?
>
Or use random secrets. Whatever floats your boat a
On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav wrote:
> So basically, it is authentication on top of bearer credentials to achieve
> another level of security. Are we just assuming that stealing the refresh
> token will be harder than stealing the client credentials? Seems a bit
> optimistic.
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 5:29 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav
mailto:e...@hueniverse.com>> wrote:
> I suspec
On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav wrote:
> > I suspect another choice of words would be useful there. Implicit grants
> rely
> > on the browser's authentication of the receiving web site. When https is
> > used, that authentication is fairly strong.
>
> "authentication of the re
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesday, June 15, 2011 1:53 PM
> > But I have no idea why we need client authentication for using a refresh
> token?
>
> This is covered here: http://www.ietf.org/mail-
> archive/web/oauth/current/msg06362.htm
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesday, June 15, 2011 1:53 PM
> To: Eran Hammer-Lahav
> Cc: Brian Campbell; OAuth WG
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> > We have one grant type wi
Eran: > > I would like to go back to requiring client authentication for
the access token endpoint
Brian: > Sure. Why not?
>
> 1) It makes the spec simpler.
> 2) It has no impact on the security of clients that can't keep secrets.
> 3) It has no impact on the security of clients that can keep sec
gt; ** **
>
> This is goo.
>
> ** **
>
> EHL
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Wednesday, June 15, 2011 11:47 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:*
ammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
Also seems this is related to the topic of native/mobile clients. As I
understand it, native apps using the authorization code grant/flow have been
the primary motivator for keeping client authentication opt
Also seems this is related to the topic of native/mobile clients. As I
understand it, native apps using the authorization code grant/flow have been
the primary motivator for keeping client authentication optional. Anonymous
client have come up too.
On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer
Client authentication has been one of the main problem areas in OAuth 1.0 and
2.0 does nothing to resolve it (arguably, it makes it more confusing).
Because of the desire to allow any client type in any deployment environment,
we ended up with a barely defined client authentication model. We off
42 matches
Mail list logo
