Did item #2 below get resolved? I haven't seen any more traffic about it and
it seems pretty significant.
Thanks,
-bill
From: "Manger, James H"
To: "oauth@ietf.org"
Sent: Thursday, July 28, 2011 8:51 PM
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt
is in the right way in
the spec.
From: Niv Steingarten
To: William J. Mills
Cc: Eran Hammer-Lahav ; "oauth@ietf.org"
Sent: Thursday, August 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
I suppose
I proposed text that I think is more complete in a previous message...
From: Niv Steingarten
To: Eran Hammer-Lahav
Cc: "oauth@ietf.org"
Sent: Thursday, August 18, 2011 4:33 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
This is, in my opinion, another style of CSRF. I the attacker present your
browser (user agent) with a link, and your browser presents a credential
automatically to the token endpoint, which automatically issues a token to be
given back to me? That's a classic CSRF, how to fix it is interestin
+1 for Jame's feedback here. We need to solve this.
From: "Manger, James H"
To: Barry Leiba ; "oauth@ietf.org"
Sent: Thursday, August 18, 2011 4:15 AM
Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
>> * For bearer tokens: clarification whether th
I like it, but I think using "phishing attacks" is too limited. I suggest
changing "phishing attacks" to "by an attacker"
From: Eran Hammer-Lahav
To: OAuth WG
Sent: Tuesday, August 16, 2011 2:44 PM
Subject: [OAUTH-WG] Open redirector feedback (Yaron Goland)
server includes the value of the "state" parameter
when redirecting the user-agent back to the client which MUST then ensure the
received value matches the stored value.
From: William J. Mills
To: Barry Leiba ; Anthony Nadalin
Cc: "OAuth WG (oauth@ietf.org
I'm a -1 on both of these until I re-read the attack description and really
parse this again. Perhaps I'm being confused by the usage of "client" here.
My initial reaction is that any time we are relying on the client to protect
itself from CSRF it is a mistake.
I do think that CSRF protectio
"add" doesn't really say it to me either. "ah", short for "additional hash" is
somewhat more mnemonic for me, but then I think "ext" isn't horrible because
it's a frequent abbreviation for extension.
-bill
______________
The defense is the same though, correct?
From: Phil Hunt
To: Eran Hammer-Lahav
Cc: "OAuth WG (oauth@ietf.org)"
Sent: Saturday, August 13, 2011 4:41 PM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
There are two CSRF variations scenarios that I see.
I can at
All CSRF attacks are a against the client (confused deputy) yes. The defense
is always in the server side. I agree that it's really worth covering. There
are already good discussions of CSRF out there which I think we shoudl lean on
rather than re-writing our own, i.e. http://www.rfc-editor.o
I'll take a swag and your comment on #5. Based on the current abstract of the
OAuth 2.0 spec
The OAuth 2.0 authorization protocol enables a third-party application to
obtain limited access to an HTTP service, either on behalf of a resource owner
by orchestrating an approval interaction between
It's implementation specific. You can choose to make them anonymous or you can
issue signed plaintext tokens that conceal nothing. The spec doesn't care.
It's a security consideration of the end implementation, just like the need for
tamper protection. The spec needs only to define them as o
I maintain my opinion that anonymity be discussed in the security
considerations section. For the purposes of the spec tokens are opaque strings
not intended to be parsed by the client.
From: Anthony Nadalin
To: Eran Hammer-Lahav ; Dick Hardt
Cc: "OAuth WG (
All I'm saying is that anonymity is not unique to refresh tokens, it's true for
refresh and access tokens.
From: Anthony Nadalin
To: Eran Hammer-Lahav ; Dick Hardt
Cc: "OAuth WG (oauth@ietf.org)"
Sent: Thursday, August 11, 2011 12:41 PM
Subject: Re: [OAUTH-WG
Does it want to be in the main definition or the security considerations
section?
From: Anthony Nadalin
To: Dick Hardt
Cc: "OAuth WG (oauth@ietf.org)"
Sent: Thursday, August 11, 2011 11:15 AM
Subject: Re: [OAUTH-WG] Refresh Tokens
Many reasons, but none a
Refresh tokens have a different main goal, in my opinion. They are useful to
allow a log lived durable replacement for username/password. This means the
user's primary credential is not stored in the client. Refresh tokens can be
revoked by the user without requiring password change. They ar
ea of someone publishing an I-D with a full syntax and
>>canonicalization requirements for say, singing an entire request, headers and
>>all. I feel that would be much better accomplished by defining a new HTTP
>>authentication scheme.
>>
>>Philosophically, I thin
In thinking about this I'm coming around to the viewpoint that a single
additional predefined spot is sufficient. If the app developer wants to
include addtional data there (iun the specified format) that's fine. If what
they want to do is include a signature of other payload that's fine too.
lliam J. Mills ; OAuth WG
Cc: Ben Adida ; "'Adam Barth (a...@adambarth.com)'"
Sent: Monday, August 1, 2011 8:59 AM
Subject: RE: [OAUTH-WG] MAC Tokens body hash
Would you still like to see both such app-specific payload hash AND the ext
parameter? I’m thinking of taking y
Instead of "body" hash why not make it a payload hash or additional hash. The
app can include a hash of data there as defined by the app, and you've reserved
a spot for that.
From: Eran Hammer-Lahav
To: OAuth WG
Cc: Ben Adida ; "'Adam Barth (a...@adambarth.c
Key rotation I understand. Forcing expiry on every reissue seems extreme
though.
From: Brian Eaton
To: William J. Mills
Cc: Torsten Lodderstedt ; Eran Hammer-Lahav
; OAuth WG
Sent: Tuesday, July 12, 2011 9:32 AM
Subject: Re: [OAUTH-WG] Refresh token
Why would you re-issue a refresh token every usage? What's the use case where
this makes sense?
The way I always think about the design is that refresh tokens are indended to
be multi-use.
From: Torsten Lodderstedt
To: William J. Mills ; Eran Hammer-
I agree that this is something you could do, but it doesn't seem like a good
design pattern.
From: Torsten Lodderstedt
To: Eran Hammer-Lahav ; OAuth WG
Sent: Sunday, July 10, 2011 1:21 AM
Subject: Re: [OAUTH-WG] Refresh token security considerations
replaceme
FYI and feedback welcome.
- Forwarded Message -
From: William J. Mills
To: "kit...@ietf.org"
Cc: Hannes Tschofenig ; "hannes.tschofe...@gmx.net"
; Tim Showalter
Sent: Thursday, July 7, 2011 11:52 AM
Subject: New draft of https://tools.ietf.org/htmdraft-mills-ki
Access tokens realistically may be longer as they may have encrypted scopes and
such.
From: Eran Hammer-Lahav
To: Brian Campbell ; Oleg Gryb
Cc: OAuth WG
Sent: Wednesday, July 6, 2011 8:53 PM
Subject: Re: [OAUTH-WG] Example tokens
Does that apply to access t
FYI there is a form of discovery for OAuth defined in
http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-02 which uses LINK
headers.
From: Eran Hammer-Lahav
To: Hannes Tschofenig ; Mark Nottingham
Cc: "i...@ietf.org IETF" ; oauth WG
Sent: Sunday, July
You text does not mention what will be a common use case, where the native app
uses the password grant to fetch a refresh and access token. Whether or not an
app can keep a secret, it's better to have it store the token than the
username/password pair.
From:
ignore the "multiple" token type, it would also allow for
re-use of token storage libraries for the inner token bits. And
you could go crazy and pass a multiple token full of multiple
tokens, too. It's turtles all the way down!
>
> -- Justin
>
>On 6/16/
Probably defining a token type of "multiple_tokens" would be my preference, and
if you get that back then you have to parse an array of {type, token}*. What
that array looks like could be JSON in the payload, or something else. That
leaves the single token use case alone.
__
Makes sense to me.
From: John Bradley
To: Eran Hammer-Lahav
Cc: paul Tarjan ; "oauth@ietf.org"
Sent: Wednesday, June 15, 2011 11:04 AM
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
I agree access_token is better.
John B.
On 201
I like your draft in general, but
10.1.3. Access Tokens
Access tokens are shorter-lived versions of refresh tokens.
Doesn't work for me. Access tokens are credentials used to access protected
resources. Refresh
tokens are credentials used to obtain access tokens.
-bill
__
It is possible to implement decent security with MAC, it is also possible to
screw it up. It is far more difficult (impossible?) to implement decent
security with cookies over HTTP.
From: Tim
To: Nico Williams
Cc: OAuth WG ; HTTP Working Group ;
"apps-disc.
MAC adds security if the initial secret exchange is secure, and it provides a
definition for signing payload as part of the request.
From: Nico Williams
To: Paul E. Jones
Cc: apps-disc...@ietf.org; Ben Adida ; Adam Barth
; http-st...@ietf.org; HTTP Working Gr
+1
From: Torsten Lodderstedt
To: Skylar Woodward ; Dave Nelson
Cc: "oauth@ietf.org"
Sent: Friday, June 3, 2011 1:58 AM
Subject: Re: [OAUTH-WG] Text for Native Applications
+1
Skylar Woodward schrieb:
This may be true for a "secret" of sorts in some appl
I wish I could talk about it. You'll have to find someone who's not bound by
stuff like employment contracts and trades secrets stuff to tell you the story.
From: Skylar Woodward
To: Dave Nelson
Cc: "oauth@ietf.org"
Sent: Wednesday, June 1, 2011 1:07 PM
Subj
In theory this is true..
> I firmly believe that secrets can be sufficiently obfuscated
> in code delivered in binary format without the benefit of a
> symbol table, so as to be sufficiently resistant todiscovery
> via disassembly by attackers you'd expect to encounter in a
> typical comme
> - native apps always use the authorization code grant
I don't like this if it means I can't use passwrd grant for stuff like IMAP
clients.
From: Brian Eaton
To: Torsten Lodderstedt
Cc: "oauth@ietf.org"
Sent: Wednesday, June 1, 2011 1:18 AM
Subject: Re: [O
> The biggest difference between a refresh token and a non-expiring access
> token is that
> the refresh token
needs to be verified by the authorization server only whereas the
> access token needs to be verified by the resource servers.
I just want to call out that use of short lifed access t
http://tools.ietf.org/html/rfc6265#section-8.2 has good text on CSRF
definition, which I think is clearer. Perhaps that can be used to touch up
your first paragraph?
From: Mark Mcgloin
To: oauth@ietf.org
Sent: Tuesday, May 31, 2011 1:58 PM
Subject: [OAUTH-WG]
Except int he "bearer" authentication scheme, in which it is not named.
From: David Recordon
To: Mike Jones ; Doug Tangren
; "oauth@ietf.org"
Cc: paul Tarjan
Sent: Saturday, May 28, 2011 9:30 AM
Subject: Re: [OAUTH-WG] consistency of token param name in beare
Yes, in fact one could get annoyingly confusing with tokens here and have...
Authorization: bearer
token="asfd2353fasdfa235q54rdasf",plaintext="JSON_GOES_HERE",oauth_signature="mysig"
and the token would be
token="asfd2353fasdfa235q54rdasf",plaintext="JSON_GOES_HERE",oauth_signature="my
- Concern that 3 and 3.1 do not clearly show a way for a native client to
provide client_id (to identify the client only) without doign authentication.
Proposed new text, insert in bold:
"In addition, the authorization server MAY allow unauthenticated access
token requests when the cli
That WRAP allowed extension and that someone extended with a second assertion
does not imply that a second assertion is provided for in WRAP. It means that
WRAP allowed extension. AQre we trying to bring that extension into the main
spec as a needed use case?
___
Authenticating a piece of software isn't how I view the utility of the client
id and secret. It is extremely useful for site to site authentication where a
trust relationship CAN be maintained. We really don't want to lose that
functionality.
From: "Manger,
r, James H"
To: Eran Hammer-Lahav ; William J. Mills
; OAuth WG
Sent: Thursday, April 7, 2011 11:47 PM
Subject: RE: [OAUTH-WG] OAuth2 scheme
A WWW-Auth header is a server’s security statement about how to gain access.
A Link header is a server’s statement of a relationship to another URI
In the SASL mechanism draft spec where we went with that is to use LINK
headers. See http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-01 if
you want to take a look. WWW-Authenticate headers return the supported
authentication schemes and LINK headers tell you there are OAuth endpoints
In working on the SASL mechanism spec for OAuth we have to deal with Channel
Binding. Sparing you the gory details there I believe that the right thing to
do is to add the channel binding information into the tunneled HTTP/OAuth
authentication. For those OAuth profiles like MAC and SAML that
I agree with Justin.
From: "Richer, Justin P."
To: Eran Hammer-Lahav ; OAuth WG
Sent: Friday, April 1, 2011 5:18 AM
Subject: Re: [OAUTH-WG] Reques to drop section 3
-1 once again
I want to keep the client password mechanism in core as it reflects the way
that
Authentication scheme names in HTTP are case insensitive.
From: "Zeltsan, Zachary (Zachary)"
To: 'Eran Hammer-Lahav'
Cc: OAuth WG
Sent: Friday, March 25, 2011 11:33 AM
Subject: Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13
The spelling of the name “Be
My vote is D, or C -- if you really have a use case for extensible errors in
Bearer.
As for consistency, the WG should attempt to keep error codes sensible and
consistently applied.
From: Mike Jones
To: "oauth@ietf.org"
Sent: Friday, March 11, 2011 3:04 PM
S
We disagree on whether bearer credentials carried in GET parameters can be
considered a best practice.
From: "Richer, Justin P."
To: William J. Mills ; Phil Hunt
Cc: Lukas Rosenstock ; OAuth WG
Sent: Thursday, March 10, 2011 11:41 AM
Subject: RE:
>> different
>> ways, each with their own unique problems that nobody's thought of. At
>> least this way, we can enable it and have a real discussion about the
>> security
>> considerations. There are valid and valuable places where putting credentials
>> in
If people are doign a one-poff internal solution they can do whatever they
want, that doesn't mean it shoudl be part of a security related standard.
From: "Richer, Justin P."
To: Phil Hunt
Cc: William J. Mills ; Lukas Rosenstock
; OAuth WG
Yeah, but there are serious security problems with credentials in the URL, is
it really worth it in light of those problems?
From: "Richer, Justin P."
To: Lukas Rosenstock ; William J. Mills
Cc: Brian Eaton ; OAuth WG
Sent: Thursday, March 10, 20
though not to the
same level).
-bill
From: Brian Eaton
To: "Richer, Justin P."
Cc: Eran Hammer-Lahav ; William J. Mills
; OAuth WG
Sent: Tuesday, March 8, 2011 6:25 PM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
This has been proven true
Then a single extra reservation is preferable to N, yes?
From: Eran Hammer-Lahav
To: William J. Mills ; Justin Richer
Cc: OAuth WG
Sent: Tuesday, March 8, 2011 10:02 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I hope this will be the last time we define a query parameter for
Richer
To: William J. Mills
Cc: Brian Eaton ; OAuth WG
Sent: Tuesday, March 8, 2011 8:41 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I don't understand this comment. If you're using query/form parameters,
there are no schemes involved in the process.
-- Justin
On Tue, 2011-0
That's because I'm focused on my use case, which is using the Authorization
header. In query args/form parameters we definitely need better
differentiation.
From: Justin Richer
To: William J. Mills
Cc: Brian Eaton ; OAuth WG
Sent: Tuesday, March
A major difference is now there is a scheme name that is differentiating. You
no longer have to parse the entire variable set to figure out what is going
on. Now the scheme name determines things. Now that we have schemes I don't
see re-using parameter names as a problem.
_
60 matches
Mail list logo
