Hi
On 06/09/13 00:44, John Bradley wrote:
At this point we don't know of any attack against the request, however
that is not guaranteed to remain the case.
If we send the secret in plain text through the browser it likely will
never get IETF acceptance.
We use HMAC a fair bit already I don't think that would be a significant
hurdle for clients.
The quoted text is trying to prevent the AS from leaking the value back
to the attacker, that would be fatal flaw if it is plaintext, and not
optimal if it is a HMAC.
AS could do something like include it in code unencrypted etc, just
trying to prevent that.
Given that Resource owner credentials grant did get IETF acceptance
without any problems (due to HTTPS being recommended I guess) and due to
the comment below that if we have a case where the device is compromised
then passing a transient sensitive value in clear does not really makes
the device client any more insecure than it already is, would it make
sense to keep the current approach in place ? I did a quick try at
implementing it few weeks ago and it was easy to do...
Sergey
On 2013-09-05, at 4:34 PM, Nat Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>> wrote:
Depending on the level of assurance that you might want to achieve, it
could have been a random string. That's how some of the existing but
widely deployed implementations are doing.
I have taken a step forward to do the hashing to give a little more
protection that even if a malware on the device captures the request,
it would not be able to use it in time. That's a kind of
man-in-the-middle and by that time happens, your device is fairly
badly compromised so there are opinion that it would not matter much
by that time that just a random string would suffice. If the WG feels
that way, I am happy to change it to a random string as well.
The current "hash" design was a middle ground between a random string
and HMAC etc.
2013/9/3 Prateek Mishra <prateek.mis...@oracle.com
<mailto:prateek.mis...@oracle.com>>
Nat - is there cryptanalysis of the proposed model available anyplace?
Extending protocols by throwing in a smidgen of hashing and a
tablespoon of encryption is often a bad idea. One of the strengths
of /RFC/ 6749 is that it avoids stuff like that.
What do you mean when you say -
[quote]
The server MUST NOT include the "tcsh" value in the form that any
entity but itself can extract it.
[\quote]
Is this even theoretically achievable without a stateful server
that maintains a table of [code x tcsh] pairs?
If not, how should the server embed tcsh in "code" and what
constructions are recommended?
- prateek
As some of you know, passing the authorization code securely to a
native app on iOS platform is next to impossible. Malicious
application may register the same custom scheme as the victim
application and hope to obtain the code, whose success rate is
rather high.
We have discussed about it during the OpenID Conenct Meeting at
IETF 87 on Sunday, and over a lengthy thread on the OpenID
AB/Connect work group list. I have captured the discussion in the
form of I-D. It is pretty short and hopefully easy to read.
IMHO, although it came up as an issue in OpenID Connect, this is
a quite useful extension to OAuth 2.0 in general.
Best,
Nat Sakimura
---------- Forwarded message ----------
From: <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>>
Date: 2013/7/30
Subject: New Version Notification for
draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>>, John Bradley
<jbrad...@pingidentity.com <mailto:jbrad...@pingidentity.com>>,
Naveen Agarwal <n...@google.com <mailto:n...@google.com>>
A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.
Filename: draft-sakimura-oauth-tcse
Revision: 00
Title: OAuth Transient Client Secret Extension for
Public Clients
Creation date: 2013-07-29
Group: Individual Submission
Number of pages: 7
URL:
http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00
Abstract:
The OAuth 2.0 public client utilizing code flow is susceptible
to the
code interception attack. This specification describe a mechanism
that acts as a control against this threat.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org/>.
The IETF Secretariat
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
